EA – An Actual Model of a Business?

If you genuinely want to understand how a business is structured and how it improves, think of it as seven interacting systems.

1. Value – What outcomes does the organisation produce, for whom, and why do they matter?
2. Work – What activities transform demand into those outcomes?
3. Organisation – Who performs the work, and where does authority sit?
4. Information – What facts, records and knowledge make the work possible?
5. Technology – What systems automate, constrain or enable the work?
6. Economics – What resources are consumed and where does value leak?
7. Governance – Who decides, who controls, who accepts risk and who is accountable?

Capabilities sit across these systems as a vocabulary describing what must be possible. They are not the systems themselves.

That distinction matters enormously.

This is an exceptionally clean and pragmatic articulation of an operating model. It cuts through the usual consulting jargon and reduces business architecture to its actual mechanics.

The final distinction regarding Capabilities is the most critical insight. A capability (e.g., “Secure Enterprise Connectivity” or “Rapid Product Prototyping”) is simply the definition of what the business must be able to do. It is the “vocabulary.” Actually delivering that capability requires threading it through all seven of the foundational systems.

This distinction becomes painfully obvious during large-scale technical transformations. For example, when executing a massive infrastructure shift—such as a 15,000-user enterprise network migration or embedding UK NCSC-aligned security baselines across an organization—the initiative almost always fails if it is treated purely as a Technology (5) and Information (4) upgrade.

To deliver the capability of a secure, modern network, it must intersect the other five systems:

• Work (2): The security posture cannot introduce so much friction that it breaks daily activities.
• Governance (7): There must be clear accountability for risk acceptance and compliance tracking.
• Organisation (3): The operational teams must have the authority and structure to manage the new environments.
• Economics (6): The licensing, hardware lifecycle, and operational overhead must not leak value.
• Value (1): The ultimate outcome must actually serve the broader goals of the enterprise, not just the IT department.

When leadership confuses a “Capability” with a “System,” they tend to buy a piece of Technology and assume the Capability has been acquired, completely ignoring the Work, Governance, and Economics required to make it function.

Here is a visual representation of how this vocabulary maps across the structural systems:

[ CAPABILITIES ]
                   (The Vocabulary of "What")
                               │
       ┌───────────────────────┼───────────────────────┐
       │                       │                       │
 [ 1. Value ]             [ 2. Work ]        [ 3. Organisation ]
  (Outcomes)             (Activities)            (Authority)
       │                       │                       │
       ├───────────────────────┼───────────────────────┤
       │                       │                       │
[ 4. Information ]      [ 5. Technology ]      [ 6. Economics ]
   (Knowledge)             (Systems)             (Resources)
       │                       │                       │
       └───────────────────────┼───────────────────────┘
                               │
                       [ 7. Governance ]
                         (Decisions/Risk)

The core visual takeaway is that you cannot simply “build” or “buy” a capability in isolation. If the business needs a new capability, that requirement must cascade down and alter the state of all seven underlying systems to actually function without breaking.