Editorial prototype — sample content, not published
Technology Brief

What belongs at the centre of a multi-site architecture?

Centralisation should be a deliberate operating decision, not an architectural reflex. This brief provides a framework for choosing what is local, shared and centrally visible.

Start with dependency on connectivity.

If a function must continue during a wide-area network interruption, placing it entirely at the centre may create an unacceptable operational dependency. That does not mean the function can never share data centrally; it means local continuity deserves explicit design.

This question is especially important for clinical operations, logistics, branch services and other environments where local work cannot simply stop.

Centralise where shared context creates value.

Identity, institutional configuration, consolidated reporting, lifecycle policy, shared specialist services or common reference data may benefit from a central service because consistency matters across locations.

The benefit should be specific. “Single source of truth” is useful only when the organisation has also defined which information belongs in that source and which local system remains authoritative for operational detail.

Distinguish shared service from central visibility.

An institution may want central oversight without forcing every transaction through a central application. Local systems can publish status, events or aggregates to a central visibility layer while continuing their own operations.

This pattern can reduce dependency while still giving leaders a coherent institutional view.

Design synchronisation and conflict rules.

Hybrid architectures create questions about timing and ownership. What happens when a local site changes a record while disconnected? Which side wins when connectivity returns? Which data is replicated, and how stale can it be?

Those decisions should be part of the architecture specification rather than left to implementation defaults.

The centre is a role, not a place.

In modern infrastructure the “centre” may be a cloud environment, a data centre or a set of shared services. Its architectural meaning is more important than its physical location.

Define the role first: shared identity, archive, coordination, reporting, policy, data service or something else. Then select the infrastructure appropriate to that role.

Working principle

Five tests for centralisation

Continuity, shared value, authority, synchronisation and governance should all be explicit before a function is moved to a central layer.

Architecture view

Local / shared / visible

Local operation
Local data
Shared services
Integration
Central visibility
Governance

The architecture can preserve local operation while sharing selected services and creating institution-wide visibility.

Related prototype content

Continue the subject.

Research & report
Editorial prototype

Connected clinical networks.

See the same decision model applied to multi-site healthcare.

Read sample →
Solution

Multi-site Operations

Approved solution route for the organisational problem.

Explore solution →

Use the framework. Then test it against the operating environment.

V3C editorial content should help readers ask better questions before they choose technology.