This is one of the most common false solutions to the coherence problem: the assumption that once things are integrated, coherence will follow. It rarely does. Integration connects parts of enterprise reality. It does not, by itself, make those parts hold together meaningfully enough for reliable action.
Integration is broader than IT
Integration is often discussed as if it were mainly a matter of systems, interfaces, data flows, APIs, platforms, and tools. Those things matter, but they are only one part of enterprise integration.
Enterprises also integrate work, roles, routines, promises, materials, documents, machines, products, services, money, decisions, responsibilities, suppliers, customers, regulators, obligations, and exceptions.
A production line integrates human work, machine behaviour, material flow, quality control, maintenance routines, safety rules, product specifications, supplier dependencies, and delivery commitments. Serving a customer end to end integrates marketing promises, sales conversations, contracts, onboarding, billing, support, service recovery, legal terms, and operational capacity. A regulatory process integrates evidence, interpretation, accountability, reporting duties, controls, policies, audits, and decisions.
A merger or acquisition integrates enterprises at several levels at once: ownership, reporting structures, brands, product portfolios, contracts, systems, policies, locations, leadership roles, and financial controls. But the acquired organisation may still understand customers differently, make decisions through different informal authorities, carry different service promises, interpret risk differently, use the same terms in different ways, and rely on practices that are invisible to the acquiring organisation.
The transaction may be complete. The integration programme may be active. The systems roadmap may be clear. And still, the combined enterprise may not yet be coherent.
Some integration is technical. Much of it is not. The enterprise is held together through operational, social, material, informational, legal, commercial, temporal, and technical connections. The coherence problem appears when these connections exist, but do not hold together well enough in practice.
The integrated enterprise can still fail
Integration can make an enterprise faster, more visible, and more efficient. It can reduce duplicate work, move information, support automation, connect specialised practices, make handovers possible, and allow people, systems, machines, and organisations to coordinate across boundaries.
So the argument is not against integration. The argument is against confusing integration with coherence.
A promise can move from sales into delivery without preserving what was actually promised. A product variant can be configured correctly in one practice and misunderstood in another. A supplier can be notified without anyone understanding the downstream consequence of delay. A service case can be visible to several teams while no one owns the customer outcome. A regulatory obligation can be documented while everyday work continues in a way that undermines it.
The parts are connected.
The action does not cohere.
Integration can also scale what it connects, including incoherence. A local improvement that optimises one practice can make other practices harder to interpret, govern, or coordinate, so that the more integrated an incoherent enterprise becomes, the faster incoherence can propagate.
Meanings diverge
The first failure is meaning.
“Customer” may mean a legal party, a delivery recipient, a billing account, a user, a household, a risk exposure, a contract holder, a prospect, or a relationship managed by an account team.
“Order” may mean a commercial commitment, a production instruction, a logistics trigger, a billing basis, a planning demand, or a customer expectation.
“Done” may mean accepted by the customer, shipped from the warehouse, installed on site, technically completed, invoiced, paid, documented, or legally closed.
Each meaning may be legitimate inside its own practice. The problem begins when integration treats these meanings as if they were the same.
A shared record can move across the enterprise while changing meaning at every boundary.
The connection works.
The interpretation does not.
When different practices act on different meanings under the same label, the organisation does not merely have a communication problem. It has a coherence problem.
Responsibilities do not cross the boundary
The second failure is responsibility.
Enterprise integration often moves work across boundaries faster than responsibility can follow. A customer request moves from sales to operations. An exception moves from production to planning. A claim moves from service to legal. A supplier delay moves into delivery planning. A policy requirement moves into a control activity.
But when the consequence appears, the enterprise may still not know who owns it.
Who owns the customer promise after it has crossed several practices? Who decides which interpretation of the order is valid? Who has authority to resolve an exception that is operational, commercial, legal, and technical at the same time? Who is accountable when every local action was correct, but the enterprise outcome was wrong?
Integration can clarify the path of movement. It does not automatically clarify ownership of consequence.
This is why many integrated processes still fail in practice. The work moves. The responsibility does not.
People then compensate through informal networks, escalation paths, personal judgement, local spreadsheets, side conversations, and experienced coordinators who know how the organisation actually works. That compensation may be necessary, but it is not the same as coherence.
Timing, grounding, and manifestation still matter
The third failure is timing. Connected parts may not move in rhythms that fit. A customer expects an answer today. Production plans in weekly cycles. Procurement works through supplier lead times. Finance closes monthly. Governance meets quarterly. Regulators impose fixed reporting dates. Machines produce events in real time.
Integration can move information between these rhythms. It does not necessarily make the rhythms coherent. The delivery status may update after the customer conversation has already happened. The supplier warning may arrive after production has committed the schedule. The dashboard may be current, but the decision cycle may already have passed.
Timing is not a technical detail. It is part of how enterprise action holds together.
The fourth failure is weak grounding. A connection may exist, but the enterprise may not understand what gives that connection its basis. Why is this handover necessary? Which obligation does this evidence support? Which customer promise depends on this production step? Which supplier dependency affects this delivery commitment? Which document is authoritative, obsolete, or only a local working copy?
Grounding is the structural dependency relation that gives enterprise knowledge its basis. In this article, it is enough to say that ungrounded integration is fragile. It may function operationally or technically while remaining architecturally insufficiently understood.
Integration shows that parts are connected. Grounding explains why the connection matters, what sustains it, and what may fail when it changes.
The fifth failure is manifestation divergence. An integration may be explicit in architecture descriptions, embedded in systems and machines, and partly embodied in how experienced people work. But these manifestations do not necessarily hold together.
The process description says one thing. The system enforces another. The team has learned a third. The manager reports a fourth. The customer experiences a fifth. The regulator expects a sixth.
An enterprise does not become coherent because an integrated solution exists. It becomes coherent when explicit descriptions, embedded arrangements, and embodied practice hold together well enough to support reliable and intelligible action.
Connection is not coherence
Integration creates connection.
Coherence is different.
Integration creates or manages connection between parts of enterprise reality: work, knowledge, decisions, promises, materials, money, machines, systems, documents, rules, roles, suppliers, customers, partners, and obligations.
Coherence exists when these connected parts hold together meaningfully and functionally enough to support reliable, intelligible, and valuable action across boundaries.
These are not the same. A handover may exist without shared understanding. A promise may be recorded without being operationally valid. A status may be visible without being trusted. A document may be available without being authoritative. A machine event may trigger action without being correctly interpreted. A customer record may be shared without preserving customer meaning. A workflow may execute without meaningful coordination.
Integration connects.
Coherence holds.
The distinction matters because many organisations keep investing in connection while leaving the conditions of coherence untreated. They connect more work, share more data, document more processes, automate more flows, build more platforms, integrate more partners, expose more knowledge, and measure more activity.
But the enterprise still struggles to understand what is happening, why it is happening, who is responsible, which knowledge is valid, which dependencies matter, and how action should be coordinated across boundaries.
The coherence problem remains.
What makes integration contribute to coherence
Integration is indispensable. Without integration, coherence often cannot be enacted at scale. A coherent enterprise still needs working connections between its practices, commitments, products, services, obligations, materials, knowledge, machines, systems, partners, and customers.
The problem is not that integration is unimportant. The problem is that integration is often asked to do work it cannot do alone.
Integration can create the possibility of coordination. It does not guarantee meaningful coordination.
Integration becomes a contributor to coherence when it is anchored, grounded, semantically clear, responsibly used, temporally coordinated, and manifested consistently enough in practice.
A connection matters because it supports a practice, decision, obligation, dependency, product, service, risk, commitment, or enterprise change that matters. When terms differ across practices, architecture must not hide the difference under common labels. If work, knowledge, material, money, or obligation moves across boundaries, ownership of consequences must be clear. Timing must fit the decision and dependency. Grounding must show what the connection is based on, what it supports, and what is affected when it changes. The connection must also be understood, trusted, and usable in the practice worlds where enterprise action actually happens.
This is where Interweaving becomes relevant.
Interweaving does not ask only whether parts are connected. It asks whether the connections matter in the practice worlds where work is done, decisions are made, obligations are carried, materials move, systems act, and consequences appear.
It looks for the conditions under which connected parts can hold together: anchored use, grounded dependencies, meaningful distinctions, responsible boundary crossing, coherent timing, and agreement between explicit descriptions, embedded arrangements, and embodied practice.
In that sense, Interweaving treats integration as a possible contributor to coherence, not as proof that coherence exists.
AI can amplify the illusion
If integration alone is insufficient, AI can amplify that insufficiency.
An AI system can retrieve policies, product descriptions, process documentation, system records, architecture models, decision logs, service histories, supplier information, meeting notes, and regulatory material. It can summarise the landscape fluently. It can produce a confident explanation of how the enterprise works.
This is especially tempting in highly integrated enterprises. When policies, process descriptions, product records, customer histories, system documentation, tickets, reports, and decision logs are connected or searchable, AI can move across them and produce a smooth narrative.
The narrative may sound coherent because the sources are connected.
But connected sources are not the same as grounded, current, authoritative, and mutually consistent enterprise knowledge.
AI can make an integrated enterprise appear more intelligible than it is. It can describe connections without knowing whether they hold meaningfully. It can summarise activity without resolving responsibility. It can explain processes without knowing how exceptions are handled. It can answer from documents without knowing whether the documented practice is still alive. It can connect fragments of knowledge without knowing which fragments are authoritative, obsolete, local, intended, or actual.
It can produce fluent coherence over an incoherent basis.
AI can help work with coherence. It cannot manufacture coherence from integration alone.
The question integration cannot answer
Integration matters.
But integration is not coherence.
It becomes architecturally useful only when connected parts are also grounded, intelligible, responsibly used, and able to hold together in practice.
The question, then, is not whether the enterprise is connected. Most enterprises already are.
The harder question is whether those connections hold together meaningfully enough for people, systems, machines, partners, and obligations to act coherently across boundaries.
Where do meanings diverge? Where does responsibility fail to cross the boundary? Where does timing break coordination? Where are connections visible but weakly grounded? Where do documents, systems, routines, and actual practice no longer agree?
These are not secondary questions after integration.
They are the architectural questions that determine whether integration becomes coherence, or merely accelerates incoherence.
This is why the next architectural question is not simply how to integrate more.
It is how to Interweave connected parts so that meanings, responsibilities, timings, dependencies, obligations, and practices can hold together across the enterprise situations where action happens.
That is the coherence problem architecture must learn to see.
/Anders W. Tell
Reimagine Architecture through Reimagining Architectural Understanding using Interweaving
