Engineering the Social Enterprise: Enterprise architecture’s founding paradox

The paradox, stated properly

Enterprise architecture has a well-known origin problem. It is a business management discipline built largely by technologists. It emerged from industrial engineering, computer-integrated manufacturing and software design rather than from management science or organisational sociology, and it inherited the assumptions of those fields: that a system can be decomposed into modules, that interfaces can be specified, that behaviour follows from design.

Applied to an enterprise, this produces a particular picture. The organisation becomes a set of capabilities with defined boundaries, realised by processes, supported by applications, running on infrastructure. Change happens through planned intervention. Coherence comes from governance and standards. It is a clean picture and it is genuinely useful.

It is also, as a description of how organisations actually behave, incomplete in a specific way. Real firms run on informal networks, tacit knowledge, negotiated authority and political bargaining. Decisions get made in corridors and unmade in steering committees. The same nominal capability is enacted differently in Frankfurt and Manila because the people are different. Work gets done through relationships that appear on no diagram.

So far, so familiar — this is the standard framing of EA’s paradox, and it is broadly right. But it understates the problem in one direction and overstates it in another, and both corrections matter for what follows.

This problem is seventy-five years old

The socio-technical critique of engineered work design is not a recent insight EA is catching up to. It has a specific origin, and it is worth knowing because it is more damning than the abstract version.

In 1951, Eric Trist and Ken Bamforth of the Tavistock Institute published a study of the Durham coalfields.¹ Mechanisation had arrived in the form of the longwall method — a technically superior approach that raised theoretical output substantially. It also broke up the small, self-selecting, multi-skilled work groups that had organised themselves at the coalface, replacing them with large shifts of specialised single-task workers. Productivity did not rise as predicted. Absenteeism climbed, accidents rose, and output disappointed. The technical system had been optimised in isolation from the social system it depended on, and the social system took its revenge.

The lesson was not that technology is bad, or that people resist change. It was that the technical and social systems are jointly optimised or not optimised at all.

Two more references belong here, and neither appears in most EA discussions of this topic.

The four-component model that circulates in socio-technical analyses of EA misalignment — structure, task, actor, technology — is Harold Leavitt’s diamond, published in 1965.² It is often cited in recent papers as though it were a recent finding. It is sixty years old, and knowing that changes how one reads the claim: the observation that these four elements must move together is not an emerging discovery about digital transformation, it is a long-established result that architecture practice has repeatedly failed to internalise.

And in 1968, Melvin Conway observed that organisations produce designs that mirror their own communication structures.³ Conway’s Law is usually quoted as a warning about system modularity, but its deeper implication is a direct inversion of the architectural instinct. If the causal arrow runs from social structure to technical structure, then an architect who designs a target architecture without changing the organisation is designing something the organisation cannot build. The org chart is not a constraint on the architecture; it is a substantial part of its specification.

Putting the three together produces a sharper statement of EA’s paradox than the usual one. The problem is not that architects forgot organisations are social. It is that the discipline keeps rediscovering a well-established body of evidence and then proceeding as though the evidence were advisory.

How the engineering instinct shows up in practice

The drift toward formalism

John Zachman’s 1987 framework established that organisations needed a structured way to describe themselves as integrated wholes rather than as piles of isolated technology.⁴ TOGAF, ArchiMate and BIZBOK extended the idea into full ontologies. Each iteration added concepts, relationship types and semantic precision, motivated by an entirely reasonable desire: eliminate ambiguity, enable analysis, support automated validation.

The cost is well described by practitioners who have lived it. The instrument meant to reduce complexity acquires complexity of its own. A statement as simple as “System A uses System B” can require a chain of modelling constructs — precise, and harder to read than the sentence. Meetings drift from the business question to the meta-model question: is this a capability or a service? Should the interface be modelled explicitly? The language overtakes the conversation.

Experienced architects resolve this pragmatically, by adopting a working dialect: a deliberately restricted subset of the notation, models built to answer one question rather than to describe everything. The test is whether a reader says “now I understand how this works” rather than “now I understand the meta-model.” This is sound practice and it is worth naming as such, because it is usually treated as a compromise rather than as the correct method.

The documentation trap

The most expensive failure mode is the attempt to comprehensively catalogue the current state before defining a target. The reasoning is drawn straight from software engineering: understand the system, then change it. But the enterprise keeps moving while you document it, so the model ages faster than it can be completed. Value realisation slides to the right, business leaders conclude that architecture slows things down, and they are not entirely wrong.

The business–IT partition

Conventional frameworks separate business architecture from IT architecture, with technology positioned as a support function executing pre-defined business requirements. That partition made sense when IT ran the back office. It makes considerably less sense when the product is software, the channel is an app, and the operating model is a set of APIs. Separating the layers obscures the feedback loops that now define the business model — which is why business capability maps drawn in isolation from technical reality tend to describe a company that does not exist.

Why EA keeps struggling — and how strong the evidence actually is

It is worth being careful here, because this is an area where confident numbers circulate with weak provenance.

The most solid evidence for EA’s adoption difficulty comes from Forrester’s Modern Technology Operations Survey: enterprise architecture groups exist in around 45% of organisations globally, while 30% report that their company had such a department and disbanded it. Forrester’s own reading is that teams get established, fall into recognisable traps — the “ivory tower” being the archetype — get disbanded, and are re-formed later in a repeating cycle.⁵ The form–disband–reform loop is a more interesting finding than any single satisfaction statistic, because it suggests the function meets a real need in a way that current practice does not durably satisfy.

A widely repeated claim that 32% of EA deliverables are never reused is often attributed to Gartner. It traces, as far as I can establish, to an EA tool vendor’s blog rather than to a locatable Gartner publication — and the vendor’s own gloss describes 32% as meaning “the majority of what EA teams produce is being quietly ignored,” which is not what 32% means.⁶ The underlying point about unused artefacts is credible from experience. The number should not be cited as though it were measured.

Beneath the statistics, the recurring failure patterns are consistent enough to name. Four dimensions of misalignment show up repeatedly:

Four recurring socio-technical misalignments. Each is a mismatch between a formal model and an informal reality — not a failure of modelling rigour.

There is a harder position worth acknowledging rather than dismissing: that EA is frequently low-value ceremony, and that the disband rate reflects accurate assessment rather than organisational short-sightedness. The honest response is that both readings fit the data. Architecture teams that produce artefacts nobody uses are correctly disbanded. That some organisations then re-form them suggests the underlying coordination problem is real. Which of these describes any particular case is an empirical question about that case, not something the discipline can settle in its own favour by assertion.

Culture is the variable, not the backdrop

If the social system determines whether architecture takes, then culture is not a soft consideration to acknowledge in a closing paragraph. It is the primary design constraint.

The Competing Values Framework — developed by Quinn and Rohrbaugh in the early 1980s and popularised in Cameron and Quinn’s later work — maps culture on two axes, flexibility versus control and internal versus external focus.⁷ It is a serviceable diagnostic for architects, because it predicts which architectural posture will be accepted:

The same architecture practice succeeds or fails depending on cultural fit. This is a diagnostic aid, not a taxonomy of organisations — most firms contain several of these at once.

Two further cultural variables deserve specific mention because they bear directly on model accuracy.

Psychological safety. Amy Edmondson’s work established that teams differ substantially in whether members can raise problems without fear of penalty.⁸ For architecture this is not a wellbeing concern, it is a data quality concern. Where safety is low, status reports get sanitised, technical debt goes unreported, and the architecture repository fills with fiction. You cannot model a system you are not being told the truth about.

Power distance. In organisations with steep authority gradients, junior engineers do not challenge senior designs, so flawed designs survive review.⁹ Architecture review is only a control if dissent is possible in the room.

And organisations are rarely culturally uniform. The business/IT subcultural divide — one side valuing speed and revenue, the other stability and standardisation — remains a primary source of architecture failure. The architect’s job in that gap is translation, and translation is a skill, not a disposition.

What actually seems to work

The practices that survive contact with organisations share a common property: they trade control for influence, and accept partial coherence as the achievable goal.

●        Guardrails over rules. Define boundaries and principles, then let teams decide inside them. The useful analogy is lane assist rather than braking — continuous, low-friction correction rather than periodic hard stops.

●        Federated governance. Autonomy at the edge, alignment at the core. This works where trust and communities of practice are mature, and degrades into fragmentation where they are not. It is not a universally superior model; it is a model with prerequisites.

●        Architecture Decision Records. Short documents capturing a decision, its context, its rationale and its consequences. Their real value is organisational memory: they prevent the Chesterton’s Fence problem of removing a constraint without knowing why it was put there. They also democratise decision-making by making reasoning inspectable rather than authoritative.

●        A restricted modelling dialect. As above: model to answer a question, not to represent the meta-model.

●        Metrics in the language of the person funding you. Cost avoidance, total cost of ownership per capability, time to business value, portfolio agility. Architecture that reports on standards compliance is reporting on its own activity, not on outcomes.

●        Scenario modelling. Simulating trade-offs — what does retiring this application actually cost, which consolidation path carries the best risk-adjusted return — shifts architecture from documentation to decision support. This is where EA tooling earns its keep, and it is the strongest available answer to the “what are you for” question.

The agentic turn: what genuinely changes

Autonomous agents — software that reasons over a goal, invokes tools, and coordinates with other agents rather than waiting for instructions — do represent a real shift, and it is worth being precise about what the shift is.

Traditional enterprise software relied on human bandwidth to supply context, judge exceptions and trigger transactions. The application was passive; the person was the active element. When an agent executes an onboarding sequence or a reconciliation, that changes: software becomes an operational actor. In ArchiMate terms, agents sit awkwardly across the layer boundary — modelled as Business Roles when they replace or augment human function, and as Application Components when they execute software services. That modelling awkwardness is not a notation defect; it is the notation faithfully reporting that a long-standing distinction has stopped being clean.

Four architectural consequences follow, and these are the substantive parts of the agentic-EA agenda:

●        Latency. Agents reasoning continuously against enterprise state need data far fresher than overnight batch cycles provide. Streaming and event architectures move from optimisation to precondition.

●        Semantics. An agent reasoning over ambiguous data reasons badly. Machine-readable ontologies and knowledge graphs shift from a data-management nicety to an operational dependency, because the model has no colleague to ask what the field actually means.

●        Interface standardisation. Heavily customised legacy systems are difficult to orchestrate. Reducing bespoke modification and exposing standard interfaces is what makes systems addressable by agents. (Several vendors market proprietary programmes under branded names for this; the underlying principle is vendor-neutral and predates the branding.)

●        Lifecycle management. Agents need to be inventoried, given scoped identities, linked to the capabilities they serve, monitored and eventually decommissioned. Without this, organisations accumulate orphaned agents the way they accumulated orphaned servers.

One economic figure deserves correction, because it is widely misattributed. The estimate of $2.6–$4.4 trillion in annual value is McKinsey’s June 2023 assessment of generative AI across 63 use cases in 16 business functions — not an estimate of agentic AI, and not a measurement of realised value.¹⁰ It is a modelled potential, produced before agentic deployment was widespread. Citing it as the prize for agentic architecture attributes a specific number to a different technology.

Why agents sharpen the paradox rather than resolve it

Here is the claim I want to push back on, because it is the most appealing and the least supported idea in the current agentic-EA discussion: that autonomous execution reconciles EA’s founding contradiction. The argument runs that when abstract capability models become executing code, the gap between the engineered blueprint and the messy social organisation finally closes — the model becomes the operation.

It is a satisfying story, and I think it is wrong in four ways.

1. Only the codifiable part becomes executable

Capability models have always described a mix of the formalisable and the non-formalisable. Agents can execute the formalisable portion — which is, by definition, the portion that was already the easiest to specify. What remains is exception handling under ambiguity, negotiation across units with conflicting incentives, judgement calls where the rule under-determines the answer, and the tacit knowledge that never made it into any document. Those are precisely the parts that resisted thirty years of process formalisation. There is no reason to expect them to yield now, and automating around them does not dissolve them. It isolates them.

2. The politics move upward, not away

Encoding a capability into an agent requires settling what the capability is — which definition, whose thresholds, which exception path, optimising for which objective. Those questions were previously left productively ambiguous, and the ambiguity absorbed a great deal of organisational conflict. Codifying them does not remove the disagreement; it forces it to resolution and then freezes the result in executing code, where changing it requires a release rather than a conversation.

An agent is a political settlement with an execution engine attached. Making capability definitions binding raises the stakes of the definition fight rather than ending it.

And agents themselves become political objects. Who owns this agent. Whose budget funds it. Whose KPI does it optimise when two units want different things. Which team is accountable when it acts wrongly. These are not technical questions and they will be settled by the same informal, negotiated, power-inflected processes that settle everything else.

3. Conway’s Law does not switch off

If organisations produce designs mirroring their communication structures, then a fragmented organisation will build a fragmented agent estate. Multi-agent architectures will reproduce existing silo boundaries, because the teams building them sit inside those boundaries. Agentic architecture is not an escape from organisational structure; it is another medium in which organisational structure is expressed — and a faster-moving one.

4. The Tavistock result applies directly

The Durham coalfield study is the closest available historical analogue. A technically superior method was introduced without redesigning the social organisation of work, and performance fell short of projection. Organisations now deploying agents into workflows without redesigning roles, accountability and decision rights are running the same experiment. Deloitte’s 2026 survey finding that 84% of companies have not redesigned roles around AI, while around three-quarters plan agentic deployment within two years, describes exactly that configuration.¹¹

Lisanne Bainbridge’s “ironies of automation” adds the operational corollary.¹² Automating the tractable parts of a process leaves human operators with the residual hard cases, while eroding, through disuse, the situational awareness those cases require. Applied to agentic enterprises: the humans left in the loop will handle only the exceptions, will handle fewer of them, and will therefore be less practised at exactly the moments when their judgement matters most. That is an argument for deliberate role design, not an argument against automation — but it is not an argument that the paradox has dissolved.

So the more defensible position is this. Agentic AI does not resolve the tension between engineered models and social systems. It removes the slack that used to absorb it. When execution was human, a badly specified capability model was survivable because people quietly did the sensible thing instead. Agents do not do the sensible thing instead; they do the specified thing at scale and at speed. The cost of a wrong model goes up, and the interval between error and consequence goes down.

That is a strong argument for taking architecture seriously. It is not an argument that architecture has become easy.

Governance for hybrid human–agent organisations

The governance requirements follow from the above, and they are more concrete than most of what EA has previously been asked to govern.

●        Identity and least privilege. Every agent needs a distinct software identity with scoped, revocable permissions. Agents inheriting a human’s credentials is the current default in many deployments and it is untenable at scale.

●        Pre-execution policy evaluation. A control point that evaluates proposed actions against policy, legal constraint and risk threshold before execution, with automatic escalation to a human above defined risk boundaries.

●        Observability. Capture of reasoning chains, tool invocations and outputs — sufficient to reconstruct why an action was taken, not merely that it was.

●        Lifecycle inventory. From proposal through decommissioning, linked to the business capability the agent serves.

On the survey evidence, two figures are worth separating because they are routinely merged. A SailPoint vendor survey of technology professionals reported that around 80% of companies said their AI agents had taken unintended actions, including accessing unauthorised systems and sharing sensitive data.¹³ A separate Deloitte survey of 3,235 director-to-C-suite respondents across 24 countries found only about 21% reporting a mature agent governance model.¹¹ These come from different populations with different methods, and the SailPoint figure comes from a vendor selling identity governance — an interest directly served by the finding. Both are plausible and neither is incident data; they measure what respondents report perceiving. The governance gap is real, but the precision of these numbers should not be over-read.

Regulatory constraints are firmer ground. The EU AI Act and the NIST AI Risk Management Framework impose risk-tiered inventories, approval workflows and post-market monitoring obligations. Data sovereignty requirements increasingly determine where workloads and models may run. These are architectural constraints with legal force, which makes them among the few parts of this agenda that will not be negotiated away under delivery pressure.

What this asks of architects — and of managers

The demands run in both directions, and the second direction is usually understated.

Architects need to shift from gatekeeping to enablement, which is easy to say and involves a genuine loss of formal authority. It also means adopting the vocabulary of management — financial performance, risk appetite, customer outcomes — rather than expecting executives to learn service meshes. And it means a real competency in behavioural and organisational analysis, not as an adjunct but as a core method: if the social system determines whether the architecture takes, then reading the social system is architectural work.

Managers and executives need corresponding technical fluency, and this is where most organisations are weakest. Three capabilities in particular: understanding business functions as composable, API-addressable services rather than as departments; treating data semantics as an operational asset that requires executive decisions about definitions and ownership; and being able to set risk thresholds, autonomy boundaries and auditability requirements for automated decisions. That last one cannot be delegated to the architecture function. Deciding how much autonomy a system may exercise over a customer decision is a business judgment with legal consequences.

The asymmetry matters. EA has spent three decades asking architects to learn the business. The agentic shift makes the reverse requirement urgent, and no certification track currently addresses it well.

Where this leaves us

Enterprise architecture’s paradox is real: a discipline built by engineers, applying engineering models to organisations that are not machines. But it is not novel, and framing it as EA’s peculiar affliction obscures the more useful reading. Trist and Bamforth established the underlying result in 1951, Leavitt formalised the components in 1965, Conway inverted the causal arrow in 1968. Architecture practice has had the answer available for most of its existence.

The agentic turn does not settle the question. It raises the cost of getting it wrong. When execution runs through people, a flawed model is buffered by human discretion; when it runs through agents, the flaw executes. That makes the architectural task more consequential and, if anything, harder — because it now requires getting the semantics right in advance, at machine precision, for processes whose ambiguity was previously doing useful work.

The practical implication is unglamorous and fairly clear. Design the social system and the technical system together, or accept that you have designed neither. Model to answer questions rather than to achieve coverage. Govern agents as identities with scoped authority rather than as features. Argue in the language of the people who fund the work. And treat the informal organisation not as noise obscuring the architecture, but as a substantial part of what the architecture actually is.

References

1. Trist, E. L., & Bamforth, K. W. (1951). Some Social and Psychological Consequences of the Longwall Method of Coal-Getting. Human Relations, 4(1), 3–38. The founding study of socio-technical systems theory.

2. Leavitt, H. J. (1965). Applied Organizational Change in Industry: Structural, Technological and Humanistic Approaches. In J. G. March (ed.), Handbook of Organizations. Source of the task–structure–people–technology model.

3. Conway, M. E. (1968). How Do Committees Invent? Datamation, 14(5), 28–31. http://www.melconway.com/Home/Committees_Paper.html

4. Zachman, J. A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3), 276–292.

5. Forrester, Enterprise Architecture Is Still Not Getting The Recognition It Deserves (February 2023), drawing on the Modern Technology Operations Survey 2022. https://www.forrester.com/report/enterprise-architecture-is-still-not-getting-the-recognition-it-deserves/RES178892

6. Avolution, Enterprise Architecture in 2026: Trends, Skills, and Strategies. Source of the widely circulated 32% figure; cited here as the origin of the claim, not as evidence for it. https://www.avolutionsoftware.com/our-resources/enterprise-architecture-trends-skills-strategies-2026/

7. Quinn, R. E., & Rohrbaugh, J. (1983). A Spatial Model of Effectiveness Criteria. Management Science, 29(3), 363–377. See also Cameron, K. S., & Quinn, R. E. (1999/2011), Diagnosing and Changing Organizational Culture.

8. Edmondson, A. (1999). Psychological Safety and Learning Behavior in Work Teams. Administrative Science Quarterly, 44(2), 350–383.

9. Hofstede, G. (1980/2001). Culture’s Consequences. On power distance as a cultural dimension.

10. McKinsey Global Institute (June 2023). The Economic Potential of Generative AI: The Next Productivity Frontier. Source of the $2.6–$4.4 trillion estimate across 63 use cases. https://www.mckinsey.com/capabilities/tech-and-ai/our-insights/the-economic-potential-of-generative-ai-the-next-productivity-frontier

11. Deloitte (2026), State of Generative AI in the Enterprise survey wave; N = 3,235, director to C-suite, 24 countries. Source of the 21% mature agent governance and 84% roles-not-redesigned figures.

12. Bainbridge, L. (1983). Ironies of Automation. Automatica, 19(6), 775–779.

13. SailPoint (May 2025), AI agent adoption and security research. Vendor survey of technology professionals; source of the 80% unintended-action figure. https://markets.financialcontent.com/wral/article/bizwire-2025-5-28-sailpoint-research-highlights-rapid-ai-agent-adoption-driving-urgent-need-for-evolved-security

14. A Socio-Technical Analysis of Enterprise Architecture Misalignments. International Journal of Advanced Computer Science and Applications. https://thesai.org/Downloads/Volume17No3/Paper_87-A_Socio_Technical_Analysis_of_Enterprise_Architecture.pdf

15. Enterprise architecture: beyond business and IT alignment. Innovation & Regulation Chair, Telecom Paris. https://test-innovation-regulation.telecom-paris.fr/wp-content/uploads/2017/12/DEDM13_Enterprise-architecture-beyond-business-and-IT-alignment.pdf

16. Bückle, S. et al. Socio-technic Dependency and Rationale Models for the Enterprise Architecture Management Function. Technical University of Munich (sebis). https://www.cs.cit.tum.de/fileadmin/w00cfj/sebis/publications/2011/Bu11e.pdf

17. McKinsey, Rethinking Enterprise Architecture for the Agentic Era. https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/rethinking-enterprise-architecture-for-the-agentic-era

18. Architecture Decision Record (ADR) organisation and templates. https://github.com/architecture-decision-record/architecture-decision-record

19. INNOQ, Socio-Technical Architecture as a Competitive Advantage (2025). https://www.innoq.com/en/blog/2025/04/soziotechnische-architektur-als-wettbewerbsvorteil/

20. European Union Artificial Intelligence Act (Regulation 2024/1689); NIST AI Risk Management Framework (AI RMF 1.0, January 2023).