Two Capabilities on the same back-plane

Part of the series: Getting it organized properly. Notes from a field still finding its shape.

Security architecture

Security architecture is changing what enterprise architecture has to organise. The gap between potential and reality is well known. Security makes it visible. This article is one telling, from where the security architect stands.

Security architecture is motivation and strategy. It is also the core elements on the business, the application and the technology layers. Security is a cross-cutting concern and that is the only way it can work.

When an enterprise architect talks with a security architect about capabilities, the security architect could wonder where these capabilities live in the core elements. A brief conversation with an ITIL professional clarifies that ITIL asks a different question to define Capability.

The enterprise architect asks what are we structured to do? The ITIL professional asks what is demonstrably done? Both answer with the word Capability. The answers are not of the same kind. One describes potential. The other describes reality.

This is the view from the back-plane. Most professionals work with one at a time. Security architects cross both. Because security does. A threat does not stop at the model.

A closer look

A closer look at Capability reveals a wider image. Many disciplines use the word, each has a unique perspective that changes the question.

Capability travels through all four, with different meanings in each:

Same word, four meanings, four sets of evidence.

The four disciplines relate closely. Enterprise modelling describes what the organisation is structured to do. Operational performance describes how well that structure is being run. Strategic planning sits on top of the model and asks what can be achieved with it. Performance measurement sits on top of operations and asks what is actually being produced.

Two of them describe what exists. The other two ask what those descriptions are good for. Which is to say: potential and reality.

Potential and reality

Enterprise modelling describes potential. Models are layered and can express an organisation at rest and in motion. None of that makes a capability real. It says what could be done, given how the organisation is shaped.

Operational performance and performance measurement describe reality. What is being done, at what level, with what result. Maturity is reality about practice. Metrics are reality about results.

Notice the language. Enterprise modelling calls its objects capabilities. The others qualify: process capability, capability maturity, service capability. Outside its own discipline, Capability on its own usually means the enterprise-modelling kind.

The capability map describes what the organisation believes about itself. Belief is not dismissive. It is what strategy rests on and what investment decisions justify. The word names the kind of claim being made.

Potential and reality belong together. The act of modelling tends to separate them. Capabilities get drawn first as a clean noun-form layer at the top. Operational reality moves in second, or worse, gets drawn second. The model gives the impression that the two are tidily stacked when in practice they are interwoven.

The gap

The gap is well-known in the field. Hohpe describes it as the distance between the executive penthouse and the IT engine room. TOGAF ADM simply defines a method called gap analysis. Business architecture writers describe it as the gap between strategy and execution, or between ideas and reality. The vocabulary is rich. The observation is not.

Each tradition has an answer. TOGAF puts requirements management at the centre of the ADM, so every phase of the architecture cycle stays connected to operational requirements. BIZBOK links capability maps to value streams. Hohpe asks the architect to ride the elevator between floors. The OAA standard observes that Capability has multiple meanings and asks them to be held together. Each of these closes the gap from inside its own discipline.

The disciplines remain separate. Enterprise modelling produces a model. Operational performance produces a maturity assessment. Performance measurement produces a scorecard. Strategic planning produces a portfolio. The artefacts do not merge. The professionals who produce them rarely sit in the same room. The gap between potential and reality is a gap between roles, methods and outputs, and no single tradition holds all of them.

On the back-plane

Security cannot work on potential alone. A threat that arrives today does not wait for the model to be updated. The defence either runs or it does not. Whether a Detect capability is detecting is not a question that can be answered from the capability map.

Security standards reflect this. NIST CSF 2.0 names six functions: Govern, Identify, Protect, Detect, Respond, Recover. Govern is closest to enterprise modelling, with strategy, policy, risk appetite and oversight. The other five hold the operational practice that the maturity assessor will examine. The framework is one document, both halves are on the same page, and the relationship between them is the framework's structural premise.

ISO 27001 and ISO 27002 do the same in a different shape. ISO 27001 defines the management system. ISO 27002 expands its controls into operational guidance. Same series, both meanings.

Hohpe's elevator carries the architect across disciplines. Riding it is necessary and hard. Disciplines are home for the people who work in them: where the vocabulary fits, where colleagues understand each other without explaining. Leaving home is uncomfortable by design.

A security standard does travel the elevator. The difficulty is apparent. The standard binds both disciplines into the same document.

Many large organisations see their IT engine separated by many floors from the executive penthouse, which also separates business and digital strategy from the vital work of carrying it out.

Gregor Hohpe, The Software Architect Elevator

Security architects work on the back-plane because that is where security has to work. Most of the time, the rest of the architecture community can keep the two meanings of Capability apart. Each profession does its own work, with its own vocabulary, and the working arrangement holds. From the back-plane, the arrangement looks slightly different. The two meanings are sitting in the same document, in every security standard worth using. The connection between them is not a problem to be solved. It is the subject matter.

Organising this is harder than naming it. The work is collective and slow. The field gets organised by many people writing carefully about what they can see clearly. This article is one small contribution to that work.

• Jacco Meijer
• |
• May 16, 2026

The human factor on the capability staircase

Can Amartya Sen's capability approach travel into Enterprise Architecture?

read more

Sources cited

• The Open Group. ArchiMate 3.2 Specification. 2023.
• The Open Group. TOGAF Standard, 10th Edition. 2022.
• Business Architecture Guild. A Guide to the Business Architecture Body of Knowledge (BIZBOK Guide), v14. 2025.
• US Department of Defense. DoDAF 2.02 Architecture Framework. 2010.
• ISACA. CMMI Model V3.0. April 2023.
• Axelos. ITIL 4 Foundation. 2019.
• ISACA. COBIT 2019 Framework. 2018.
• National Institute of Standards and Technology. Cybersecurity Framework 2.0. February 2024.
• International Organization for Standardization. ISO/IEC 27001:2022 Information Security Management Systems. 2022.
• Gregor Hohpe. The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise. O'Reilly, 2020.
• The Open Group. Open Agile Architecture (O-AA) Standard. 2020.