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.
Where this builds from
The first post in this series established that capability is doing different work in different contexts. Strategic capabilities are claims about potential: what the organisation is structured to do or could achieve. Operational capabilities are claims about reality: what is demonstrably done. ArchiMate formalises the separation. Capability belongs to the Strategy Layer. The business functions that realise it belong to the Business Layer. They are related by a realisation relationship. They are not interchangeable.
- Jacco Meijer
- |
- Mar 9, 2026
- Capability is not confused. It is occupied
Most capability work fails before it starts because it does not ask which type of claim it is making. A diagnostic language for enterprise and security architects.
Most failure begins when one is mistaken for the other. That is the nature distinction. What sits above it is the question this post addresses: even when the type of claim is correctly identified, does the capability hold in the environment it must actually operate in?
Conditions
DoDAF defines capability as the ability to achieve a desired effect under specified standards and conditions. The word is already in the authoritative definition. What most capability work fails to do is name the conditions explicitly and test whether the capability holds under them.
A condition is anything in the operating environment that determines whether a capability performs as claimed. The question is always the same: does this capability hold under the circumstances in which it must actually operate?
The four that follow are not exhaustive. They are the conditions most consistently relevant to enterprise and security architects and the ones most consistently left unnamed. Others qualify: regulatory requirements, cultural context, organisational change and transformation are all legitimate candidates. So are conditions specific to a given domain or operating environment.
Naming a condition is an act of judgement. It requires understanding the operating environment well enough to know which pressures are material and which can be set aside. The model does not make that judgement. The architect does.
Maturity
A capability assessed at CMMI level 2 operates under different conditions than one at level 4. Processes are less defined, repeatability is lower and confidence is correspondingly weaker. Maturity is a condition. It shapes what a capability can claim and what evidence can be trusted.
A high maturity score is evidence of discipline. It is not evidence of effectiveness. The question maturity cannot answer on its own is whether the capability works for the people it is meant to serve.
Adoption
Adoption is that question. The condition is not whether the capability exists formally. It is whether the people it is meant to serve can actually use 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.
A capability that is not adopted is not partially successful. It does not exist.
Stress
Adoption tests whether a capability works under normal conditions. Stress tests whether it holds under adversarial ones. A capability that performs reliably in a defined operating environment may behave very differently under pressure. Individual controls are assessed. The system is not.
A threat actor does not present as a single control failure. It presents as a sequence of interactions: a phishing email exploiting a gap between email security and endpoint detection, compounded by an exception in patch management and an incident response plan that assumes communication channels still work. The capability that failed was not visible from any single control's perspective. It became visible only at the level of the whole system, under the conditions of the actual attack.
If a capability has not been observed under stress, its reliability is assumed, not known.
Complexity
Stress is adversarial pressure from outside. Complexity is pressure from within. When systems are designed to self-organise, learn and produce outcomes beyond what their components were specified to deliver, emergence shifts from something to manage to something to design for. Cynefin gives architects a useful distinction: complicated systems follow best practice while complex systems require discovering emergent practice.
The failure mode is drift: value is created without ownership and without intent. Drift is only governable if it is observable. The mechanism that closes this loop is operational evidence continuously revising what the organisation believes it can achieve. That mechanism is the feedback loop.
What qualifies
Maturity, adoption, stress and complexity illustrate the pattern. The conditions layer sits above the perspective table not because these four are complete but because the question they represent is always present: does this capability hold in the environment it must operate in?
Without that question, capability models answer with increasing precision what is increasingly the wrong thing. Adding the conditions layer shifts the frame from what a capability can do to whether it will hold.
The conditions layer in practice
Two things follow from naming conditions explicitly.
The first is that capability assessments become testable rather than merely descriptive. A capability assessed without named conditions produces a score. A capability assessed against named conditions produces evidence. The difference is not procedural. It is the difference between knowing what the organisation claims and knowing whether that claim holds.
The second is that the assessment boundary becomes visible. When conditions are named, it is clear what the assessment covers and what it does not. A maturity assessment conducted without a stress condition does not tell you whether the capability holds under adversarial pressure. It tells you whether the process is disciplined. Those are not the same finding and treating them as if they are is where the most consequential capability failures begin.
Conditions do not complete the model. They extend it. The third post in this series introduces the feedback loop and the diagnostic instrument that brings the nature distinction, the conditions layer and the failure modes together into something an architect can use in a capability review.
Where this goes
The conditions layer names what a capability must hold under. What remains is the question of what happens when it does not: the failure modes that follow from specific mismatches between perspective, nature and condition:
- Jacco Meijer
- |
- Mar 23, 2026
- What we do is not the same as how we do it
Six failure modes that follow when that distinction collapses. A diagnostic instrument for architects who need to know not just what went wrong but which mismatch drove it.
References
- DoD Architecture Framework (DoDAF): U.S. Department of Defense. DoD Architecture Framework, Version 2.02.
- CMMI: CMMI Institute. Capability Maturity Model Integration (CMMI).
- Sen, A. (1999). Development as Freedom. Oxford University Press.
- Cynefin Framework: Snowden, D.J. and Boone, M.E. (2007). A Leader's Framework for Decision Making. Harvard Business Review, 85(11), pp.68-76.
- COBIT 2019: ISACA. COBIT 2019 Framework.
- ITIL: AXELOS. ITIL 4 Foundation.
- INCOSE Systems Engineering Handbook: INCOSE. Systems Engineering Handbook, 5th ed. (2023). Wiley.
