A Boundary Is Not Merely a Line
A boundary is often imagined as a dividing line.
One organisation ends and another begins. One system hands information to another. One department becomes responsible where another ceases to be.
In practice, boundaries are more significant than lines.
A boundary is where something must change form without losing what matters.
A strategic ambition becomes a portfolio decision. A regulatory requirement becomes an operational procedure. A customer commitment becomes a service obligation. An architectural principle becomes a design constraint.
Whenever something crosses a boundary, a relationship is required. Without that relationship the entities on either side remain separate, regardless of how carefully they have been described.
This is why coherence is fundamentally relational.
The existence of entities does not create coherence. The relationships that connect them determine whether coherent action is possible.
The Form Facet directs attention to precisely this issue. Instead of asking only what exists, it asks what brings things together and allows them to work across boundaries.
Dependencies Bring Entities Together
The first mechanism is dependency.
Entities become related when one depends upon another for something it cannot provide itself.
A delivery team depends on a platform team. A business process depends on information arriving at the right time. A product depends on suppliers. A regulatory report depends on data collected elsewhere in the organisation.
Dependencies matter because they create consequences.
A change in one place can affect outcomes somewhere else. A delay, failure, or improvement may propagate across organisational, operational, or technical boundaries. Dependencies reveal where apparently separate parts of the enterprise are not truly independent.
Architecturally, dependencies often expose the hidden structure of the enterprise.
Teams may believe they are autonomous while relying on decisions made elsewhere. A business capability may appear self-contained while depending on shared infrastructure. A strategic objective may seem straightforward until the chain of dependencies required to achieve it becomes visible.
Dependencies make consequence visible. They show where one part of the enterprise becomes significant to another.
Practices Bring Entities Together
The second mechanism is practice.
Enterprises are not held together only by structures, assets, and systems. They are held together by what people repeatedly do.
Planning sessions, governance meetings, service delivery routines, budgeting cycles, incident management activities, and regulatory reporting all create relationships between otherwise separate entities.
A governance forum brings together policies, people, decisions, risks, and priorities. A service process brings together customers, systems, staff, information, and obligations. A planning cycle brings together strategy, funding, delivery teams, and expected outcomes.
Practices matter because they create recurring patterns of participation.
Many architectural descriptions focus on formal structures. Yet actual coherence often emerges through repeated practice. A process that nobody follows contributes little to coherence. A modest routine that people depend on every day may be far more significant.
This is one reason architecture cannot be reduced to documentation.
Architectural significance frequently emerges through recurring practice rather than through representation alone.
Obligations and Authority Bring Entities Together
The third mechanism is obligations and authority.
Many enterprise relationships exist because someone is required, permitted, accountable, or authorised to act.
A contract binds a supplier and a customer. A regulation binds an organisation to an external authority. A policy binds local decisions to organisational expectations. Delegated authority binds decisions to governance structures.
These relationships differ from dependencies and practices.
A dependency may exist whether or not anyone formally recognises it. An obligation exists because some commitment, authority, or expectation has been established.
This mechanism becomes especially important in larger enterprises and ecosystems.
A regulator influences product design without participating in daily operations. A board influences investment decisions without executing projects. A contractual commitment influences service delivery long after the agreement was signed.
These relationships shape what can and cannot happen. They influence behaviour, constrain choices, and create accountability.
When obligations and authority are unclear, coherence becomes difficult. Different groups operate according to different assumptions about responsibility, decision rights, and expectations.
Accountability often travels further than organisational charts suggest. Authority can connect entities that rarely interact directly but remain consequential to one another.
Meanings and Concepts Bring Entities Together
The fourth mechanism is meaning.
Some of the most important enterprise relationships exist because people share concepts and distinctions.
The concept of a customer may bring together sales, service, finance, compliance, and analytics. The concept of risk may connect governance, operations, technology, and audit. The concept of a product may link design, manufacturing, support, and reporting.
Meaning creates relationships because it allows entities to participate in a common conceptual world.
This does not require identical interpretation. Different practices may understand the same concept differently. What matters is that the concept provides enough continuity for coordination and action.
Classifications, terminology, distinctions, and shared language all contribute to this mechanism. They allow entities to be recognised, compared, discussed, and acted upon across boundaries.
Without sufficient conceptual continuity, coordination becomes fragile. Different groups may use the same words while referring to different realities.
For this reason, meanings and concepts are not merely linguistic concerns. They provide much of the continuity that allows enterprise action to extend across boundaries.
Several Relations at Once
The four mechanisms have been described separately, but they rarely act in isolation. The same entities are usually held together by more than one relation at once.
A regulatory report is a familiar example. It depends on data collected elsewhere, it is produced through established reporting routines, it exists because an external authority requires it, and it relies on shared definitions of what is being reported. A dependency, a practice, an obligation, and a concept all bear on the same artefact. Remove any one of them and the report may still exist, yet the togetherness that makes it usable begins to weaken.
This is why coherence is rarely the work of a single relation. It emerges as several relations hold the same entities together in a way that supports action across a boundary.
Not Every Relation Creates Coherence
If coherence lives in relations, it does not follow that every relation creates coherence.
Relationships can support coherent action, but they can also undermine it.
A dependency can overload a team. A practice can become bureaucratic. An authority structure can create confusion. A concept can obscure more than it clarifies.
Relations may stabilise or destabilise. They may clarify or obscure. They may strengthen coordination or make it harder.
The important point is that coherence depends on the quality of relationships, not merely their existence.
This distinction matters because enterprises often assume that identifying a relationship solves a problem. In reality, a poorly designed or poorly understood relationship can become a source of incoherence.
AI provides a useful illustration. An AI system may connect documents, repositories, models, tickets, policies, and reports. Yet connecting artefacts does not automatically create the relationships required for coherent action. The relational substrate that supports dependency, practice, authority, and meaning must still exist if people are to rely on the results.
The architectural challenge is therefore not simply to discover relationships. It is to understand whether those relationships support coherent action across boundaries.
Anchoring: Which Relations Matter?
Not every relationship is architecturally significant.
Enterprises contain countless relationships, many of which are temporary, local, or inconsequential. Architecture cannot concern itself equally with all of them.
This is where Anchoring becomes important.
A relation becomes architecturally significant when agents depend upon it in practice.
A dependency matters architecturally when people rely on it to achieve outcomes. A concept matters architecturally when decisions depend on it. An obligation matters architecturally when it shapes behaviour. A practice matters architecturally when it influences how work is actually performed.
Anchoring provides a practical test.
Rather than asking whether a relationship exists, we ask whether agents depend upon that relationship in order to work, coordinate, decide, comply, adapt, or deliver value.
This keeps architecture connected to reality. It prevents attention from drifting toward relationships that appear elegant in diagrams but remain irrelevant in practice.
The most important architectural relations are not necessarily the most visible. They are the relations that people depend upon every day, whether they notice them or not.
Looking Ahead
Enterprises are full of entities, but coherence does not reside inside the entities themselves.
The more fundamental architectural question is what brings those entities together across boundaries and allows them to participate in coherent action.
Dependencies, practices, obligations, authority, meanings, and concepts are all part of that answer. Anchoring helps identify which of those relations matter in practice.
That shift in attention leads naturally to the next question.
If coherence depends on relations, then what role does integration actually play?
/Anders W. Tell
Reimagine Architecture
through Reimagining Architectural Understanding
using Interweaving
Related articles in the Coherence Series
Related articles in the Coherence Series
