Part of the series: Capability is everywhere in the organisation. For architects it is a strategic element. For everyone else it is what they do daily.
Capability is precise. It is also plural.
Architects understand capability with precision. In ArchiMate, capability sits in the Strategy Layer: the ability an organisation, person or system possesses, expressed in general and high-level terms, aimed at outcomes and realised by a combination of organisation, people, processes, information and technology. It is clearly defined, deliberately placed and central to the decisions that matter. That precision comes from the language. It is the right place to start.
For everyone else in the organisation, capability is simply what gets done. Not a framework element and not a mapped asset. Just the daily work that makes the organisation what it is.
The Open Agile Architecture (OAA) Standard noticed this. It defines capability once cleanly in chapter 2: the ability that an organisation, person or system possesses. It then returns to it in chapter 17 and works through six definitions and still finds none of them quite right.
The signal is this: a standard that settles capability in two sentences needs six definitions and a position statement to handle it in operations architecture. That is not a terminology dispute. The concept is doing different work in different contexts and the frameworks have not caught up.
Capability from the OAA Standard
The Standard is precise: when capability is used to mean an activity, even a self-contained one, two issues follow. Terminology becomes a source of confusion and the risk of limiting the range of possible solutions is higher.
When capability is routinely treated as an activity, it limits the range of possible solutions before the problem is fully understood.
The Standard's position is that operational capabilities should refer to outcomes the operating system delivers. Its examples are deliberately concrete, such as delivering inexpensive food quickly from a standard menu with a defined quality level. Not what the organisation has. Not what it does. What it achieves, reliably and repeatedly.
The Standard cites Amartya Sen to make the distinction concrete. When a person enjoys a capability, it implies they have the freedom to exercise it. Having a capability and being able to exercise it are not the same thing.
The OAA maps a specific part of the landscape. The territory is wider. The perspectives that follow provide a structured entry.
Six questions
Capability is not confused. It is occupied, doing different work in different contexts and asking a different question depending on where you stand. The table maps six perspectives, each with its own question.
| Perspective | Core question |
|---|---|
| Enterprise modelling | What are we structured to do? |
| Strategic planning | What can we achieve? |
| Operational performance | What is demonstrably done? |
| Human development | Can this capability actually be exercised? |
| Systems engineering | What fails when components interact? |
| Adaptive systems | What becomes possible when components interact? |
This is not an exhaustive survey of perspectives. It covers the most relevant to enterprise and security architects. It includes Human development because the OAA introduces it through Sen and it highlights Adaptive systems as the condition where capabilities most visibly fail or surprise.
Behind these questions lie two types of capability claim. Strategic capabilities describe what an organisation is structured to do or could achieve. They are claims about potential. Operational capabilities describe what is demonstrably done. They are claims about reality.
ArchiMate makes the separation formal. Capability belongs to the Strategy Layer, expressing what the organisation can do. The business functions that realise it belong to the Business Layer, expressing how it is done. They are related by a realisation relationship. They are not the same element and they are not interchangeable.
Most failure begins when they are treated as if they are. The errors are structural and often invisible from inside the frame that created them. This is why the first question in any capability exercise is prior and non-negotiable: which type of claim is this? If that question is not answered first, everything that follows is unstable.
The human condition as condition
The OAA's citation of Sen is not decorative. It introduces a question most capability frameworks do not ask: can the people this capability is meant to serve actually exercise it?
Consider three common examples. A security awareness programme that treats people as the problem rather than the asset. An incident reporting process that creates fear rather than safety. A zero trust architecture that assumes a level of digital literacy most users do not have. In each case the capability exists formally, mapped, documented and assessed, but fails in practice because adoption was never treated as a condition.
This is what Sen means by real freedom. Resources, activities and outcomes are not the same as the freedom to exercise them.
Most enterprise capability maps describe representations, not capabilities. They describe what the organisation believes is true, not what people can actually do.
This is not only a failure mode. It introduces a condition: any capability must be tested against the conditions in which it operates. That argument is developed in full in the second post in this series. What matters here is the pattern it reveals: the nature of a capability claim determines what evidence can honestly support it.
What experienced architects already know
Experienced architects already navigate this terrain. They move between perspectives, adjust language to context and apply conditions without naming them. When they say a capability looks good on paper but needs to be seen under pressure, they are testing conditions. When they ask whether it actually works, they are invoking the feedback loop.
What is missing is not intuition. It is a shared language precise enough to make that intuition transferable across disciplines and legible to the people who work alongside architects.
The proliferation of definitions across this post is itself a signal. Capability resists unification because it is doing different work in different contexts. The multiplicity is not a flaw in the concept. It is a feature of the territory.
An architect fluent across these meanings, who can move between strategic and operational and who understands what each perspective is asking, is not navigating confusion. They know which question they are answering and why. Most organisations do not.
Where this goes
The nature distinction is the foundation. What sits above it is a conditions layer: a structured way of asking whether a capability holds in the environment it must actually operate in. That is the subject of the second post in this series:
- Jacco Meijer
- |
- Mar 16, 2026
- Having a capability and being able to exercise it are not the same thing
Formal capability is not real capability. A conditions layer for testing whether a capability holds in the environment it must actually operate in.
References
- ArchiMate: The Open Group. ArchiMate 3.2 Specification. Document Number: C226. Published October 2022.
- OAA Standard (Operations Architecture): The Open Group. Operations Architecture Standard.
- Sen, A. (1999). Development as Freedom. Oxford University Press.
- Nussbaum, M.C. (2011). Creating Capabilities: The Human Development Approach. Harvard University Press.
- UNDP Human Development Reports: United Nations Development Programme.
- The Open Group Architecture Framework (TOGAF): The Open Group. TOGAF Standard, various editions.
- Zachman, J.A. (1987). A Framework for Information Systems Architecture. IBM Systems Journal, 26(3).
- BIZBOK Guide: Business Architecture Guild. A Guide to the Business Architecture Body of Knowledge.
