Part of the series: Getting it organized properly. Notes from a field still finding its shape.
The capability approach
This piece starts with Amartya Sen.
Sen was an Indian economist and philosopher, awarded the Nobel Prize in Economics in 1998. His work shifted the question development economists had been asking. The standard question was about resources: what does a country produce, what do people earn. Sen asked something different. Having resources is not the same as being able to do something with them. A person may have formal access to education and still be unable to attend. A person may have legal rights and still be unable to exercise them. The gap between what is formally available and what a person can actually do, given their circumstances, is what Sen named the capability approach.
The distinction is between formal freedom and real freedom. Sen argued that development should be measured by the second kind: not what people have access to, but what they can actually do and be.
That distinction travels further than development economics. It arrives, with some precision, in the middle of enterprise architecture.
The Open Agile Architecture standard noticed this. In its treatment of capability, OAA places Sen's definition alongside others and marks the contrast.
That is the move this article picks up. Not to replace what any discipline does, but to ask what it would mean to carry Sen's question alongside, across the rest of the staircase.
The staircase
The word capability is used across four distinct disciplines, each asking a different question.
Enterprise modelling asks: what are we structured to do? The answer is a capability map. ArchiMate places Capability in the Strategy Layer: an ability that the enterprise can exercise, now or in the future. The map describes potential. It is intentionally clean, intentionally abstract. That is its purpose.
Strategic planning asks: what can we achieve? The answer is a portfolio of strategic objectives, roadmaps, investment decisions. Capability here is the means by which objectives become reachable. DoDAF defines it as the ability to achieve a desired effect under specified standards and conditions.
Operational performance asks: what is demonstrably done? CMMI applies capability levels to practice areas and requires evidence before a level can be claimed. ITIL asks what services demonstrably deliver. The word capability here carries a different weight. It is not potential. It is measured reality.
Performance measurement asks: what does the practice produce? KPIs and OKRs sit on top of operational reality and ask whether the results are the ones intended. Capability here is almost a verb: it is what the practice is shown to be capable of producing.
Four disciplines. Four questions. The same word at every step.
Where Sen is on the staircase
At the first step, enterprise modelling, Sen is intentionally absent. EA capabilities are clean by design. The map describes what the organisation is structured to do. It is not designed to ask whether the people who need to exercise a capability can actually do so. That question would collapse the instrument. A capability map that descended into the human conditions of every capability would not function as a strategic tool.
That is a reasonable design choice. The cleanliness has value. But it means Sen's question is not answered here. It is not asked.
At the second step, strategic planning, Sen is nearly present. DoDAF names standards and conditions as part of the definition. But the conditions it has in mind are operational: the environment the capability must function in, the standards it must meet. The human conditions for exercise are not what DoDAF is asking about.
At the third step, operational performance, Sen is implicit. CMMI requires evidence of what is demonstrably done. ITIL asks about service delivery. The people doing the work are present here, at least in the background. But the question being asked is about process consistency and repeatability, not about whether the people the capability is meant to serve can exercise it. A process can be mature and still fail the people it is built for.
At the fourth step, performance measurement, Sen is downstream. The results are visible. But results are downstream of exercise. If the capability was never exercised by the people who needed it, the measurement will show the gap only after the fact, if at all.
Sen is not at any step.
Do we need Sen?
No. That is the honest first answer. The staircase functions. Each step does its work. Enterprise architects map capabilities. Strategists plan. Operations teams mature their processes. Performance measurement tracks results. Organisations have run this way for decades and produced real value. There is no structural emergency. Sen is not missing in a way that has stopped the world.
That is the world the article is written from. Not one where the staircase is broken, but one where it works and could work better.
Could Sen be useful? That is the question this article is actually asking.
The origin
The question came from a security architect's vantage point. A security architect spends time on every step of the staircase and sees the gap between formal capability and what people can actually do more often than most. The cost of that gap, in the security case, is concrete: a capability that exists on the map and is not exercisable by the person at the keyboard is not a defence. Security is the trigger, not the destination. If Sen's question is useful for security, it is because something about it is useful for the staircase. The remaining sections look at where that usefulness shows.
Reading the standards through Sen
The gap between strategy and execution is well-known in the field. Hohpe describes it as the distance between the executive penthouse and the IT engine room. TOGAF defines gap analysis as a method. Business architecture links capability maps to value streams. The vocabulary is rich and the answers are real. Security standards take a different shape: they hold both potential and reality in the same document, because a Respond function that only describes potential is useless when the incident arrives.
NIST CSF 2.0 is explicit on this. The framework defines outcomes, not just capabilities. Each function, each category, each subcategory names what should be happening, not only what should be possible. That is a structural commitment to reality, not just potential.
ISO 27001 Clause 7.2 requires that people doing work under the organisation's control are competent. Clause 7.3 requires that they are aware of the information security policy, their contribution to its effectiveness, and the implications of not conforming. Read through Sen: competence is a real condition for exercise, not a formal one. Awareness is a real condition, not a documented one. The standard is asking, in its own vocabulary, whether people can actually do what is required of them.
Neither standard uses Sen's language. Neither names the capability approach. But the territory is the same. Formal provision is not enough. The standard requires evidence of actual capacity. That is Sen's question, answered in the language of controls and clauses.
The gap that remains is the one between what the standard requires and what organisations audit for. Competence can be evidenced by a training completion record. Awareness can be evidenced by a signed policy acknowledgement. Both satisfy the clause. Neither tests whether the person can actually exercise the capability when it is needed. The standard approaches Sen's question. The audit practice often stops short of it.
Sen on the staircase: a second pass
If Sen's question travels with each discipline without replacing what that discipline does, the staircase looks different on the second pass. Not a different staircase. The same one, with one additional question at each step.
Enterprise modelling. The capability map stays clean. That is correct and should not change. Capabilities in ArchiMate describe the organisation's potential, and the abstraction is the instrument's value. But the business and application layers below the Strategy Layer are where the human conditions for exercise actually live. The business processes, the roles, the organisational actors, the assigned responsibilities: these are the ArchiMate elements that determine whether a capability can be exercised. Modelling those layers with Sen's question in mind, asking whether the people represented can actually do what the model assigns them, changes what gets included and what gets left out.
Enterprise architects who work in human factor groups already know this. The observation here is that Sen gives it a name and a structural location: not inside the capability, but in the layers that realise it.
Strategic planning. A strategic plan names capabilities and assumes the people who will exercise them. Sen's question turns that assumption into a deliverable. A strategic plan that does not name the human conditions for its capabilities is planning for a different organisation than the one it has.
Operational performance. Maturity describes how the process is run. Adoption describes whether the people the process is for can use it. CMMI level 4 with zero adoption among the people the process serves is not a contradiction in CMMI terms. It is a contradiction in Sen's terms. Maturity and adoption can move in opposite directions, and an assessment that measures only the first will not notice.
Performance measurement. KPIs measure what gets done. Sen's question asks who can do it. A green KPI says the result was achieved. It does not say by whom, or whether the capability that produced it is exercisable beyond the people who exercised it this quarter.
The obvious question
If Sen would be useful, why is he so rarely used? Sen is not absent. He is present in many organisations, as the human factor or with another name. Not much has been written on using Sen's work as a foundation for that practice. But the capability approach exists. It is decades old and names this territory with precision. It can be picked up.
A shared question
Sen's capability approach can travel into enterprise architecture. It does not replace what any discipline does. It gives the human factor a name and a structural location on every step of the staircase, expressible inside each discipline's own vocabulary.
That is a different move from the one Hohpe describes. The elevator asks the architect to leave their floor and ride between levels. Useful, and sometimes necessary. Sen offers a complement: a question each discipline can ask from where it already stands, in the terms it already uses. Connection without displacement. Both moves matter. They are not in competition.
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 18, 2026
Reading the security architect three ways
CISSP, TOGAF, SABSA and what each one is for
References
- Sen, A. Development as Freedom. Oxford University Press, 1999.
- The Open Group. ArchiMate 3.2 Specification. 2023.
- The Open Group. Open Agile Architecture (O-AA) Standard. 2020.
- The Open Group. TOGAF Standard, 10th Edition. 2022.
- U.S. Department of Defense. DoD Architecture Framework (DoDAF), Version 2.02. 2010.
- ISACA. CMMI Model V3.0. April 2023.
- Axelos. ITIL 4 Foundation. 2019.
- 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. O'Reilly, 2020.
