REALIZE Blog series  Architecture Capability 
 

Introduction 

This blog is part of a series of posting on our Realize approach to digital transformation. In the first postings of the series, I defined several concepts around architecture and digital transformation. However, I have not yet defined the notion of architecture capability. This seems relevant since many organizations claim to have one.  
 
Where the previous post involved a (mini) literature review, I will keep the definition discussion relatively short in this post.  

Capability 

The notion of capability seems elusive and difficult to define. It shows up in various frameworks for (enterprise) architecture such as TOGAF and BIZBOK. I have done a cursory exploration through my own library which results in the following:  

• The oldest paper I have that uses the word capabilities is Richardson (1972). It is stated that “It is convenient to think of industry as carrying out an indefinitely large number of activities, activities related to the discovery and estimation of future wants, to research, development and design, to the execution and co-ordination of processes of physical transformation, the marketing of goods and so on.”  
  
• The notion of capability also shows up in a military context. For example, Davis writes about capability based planning (CBP) and states that, “Capabilities-based planning (CPB) is planning, under uncertainty, toprovide capabilities suitable for a wide range of modern-day challenges and circumstances” (Davis, 2002). Essentially the approach boils down to formally specifying requirements to capabilities and assessing the enablers that are needed to satisfy these requirements.  
  
• Organizations like The Open Group have provided guidance on how to model (with) capabilities. Capabilities are defined as “an ability to do something” but also (more formally) as “particular ability or capacity that a business may possess or exchange to achieve a specific purpose or outcome (The Open Group Architecture Forum, 2016). 
  
• Capability modeling tends to use the notion of a capability map (capmap)  (see e.g. (Van Riel, 2025)) and should help the organization to achieve its strategic objectives such as increased agility (Cummins, 2017).  
  

This doesn’t help much, but at least sets us off on the right path. In my opinion, more (scientific) research is needed to come to a widely accepted definition that everyone can adhere to. 
 
For the time being, my take on the definition of capability is simple. The equation CAPABILITY = CAPacity x ABILITY captures the essence: capabilties are about the abilities of an organization, as well as the capacity that the organization has to actually execute/peform these abilities. As an example, we say that an organizaiton may have a manufacturing capability. What we mean is that the organization may have the ablity to manufacture things. This implies that there must be (availability of) resources in the organization (staff, equipment, etc.) in the organization if we actually want to manufacture anything. Note also that the equation also implies that if either capacity or ability are zero, then the (level of) capability is also zero.  
 
The term capabilty map (capmap) is, therefore, in my mind a misnomer. We are modeling the ablities of the organization so perhaps ability map is a better word (even though it doesn’t sound as nice).  

Architecture capabilty 

In the previous  blog post, I wrote that,  
 
Architecture is a conceptualization of the fundamental organization of a system and the principles guiding its design and evolution. It can be represented as a set of artifacts which are intended to help achieve some level of coherence in the system. The artifacts are created by an architecture capability. The architecture, as expressed through artifacts, can be implemented. 
 
 The architecture capability of an organization, therefore, is the ability of an organization to “do” architecture and consists of both the architecture abilities and the resources that offer capacity to be used in the execution of these abilities. The abilities deliver the artifacts that describe the architecture (at a certain point in time). This is illustrated by the following diagram:  

One aspect may need further explanation: the notion of time. Organizations evolve through time. Therefore, we may document the architecture of the organization at a specific point in time. If we describe the architecture “as is” (or perhaps even: “as as”), then this has the connotation of bookkeeping: we are capturing what exists. This is useful for various purposes including an analysis, planning, and communication. Describing the architecture as it “will be” (perhaps more precise: as we think it should be), then this has the connotation of design. Based on strategies, goals, strengths, weaknesses and many other factors we create the architecture as we think it should be. The associated artifacts ought to contribute to executing the digital transformation of the organization in an effective manner.  

Dynamic capability 

A topic that is being actively discussed in the world of research is dynamic capability. It appears that the notion was introduced formally by Teece et al. (1997). Citing older work, Teece and colleagues state the following: 
 

We define dynamic capabilities as the firm’s ability to integrate, build, and reconfigure internal and external competences to address rapidly changing environments. Dynamic capabilities thus reflect an organization’s ability to achieve new and innovative forms of competitive advantage given path dependencies and market positions. 
 

In later work, it was specified that dynamic capability is about sensing, seizing, and integrating changes and related to the world of architecture (e.g. (Winter, 2003; Wetering, 2021; Pattij, 2025)). For example, Wetering (2021) states that, “This study explained how EA (enterprise architecture)-driven dynamic capabilities enhance a firms’ agility through digital project benefits.” Again, referring to earlier work, “EA-driven dynamic capabilities leverage the firms’ EA to bridge the communication gap between business and IT stakeholders, facilitate cross-organizational dialogue and input […] and improve digital strategic alignment […].” 
 
My main take-away is that the architecture capability as just defined, helps the organization to sense, seize, and integrate changes in an effective manner and therefore aids the realization of the dynamic capability of the organization.  
 
This puts me in mind of the Cynefin framework (e.g. (French, 2013; Hasan & Kazlauskas, 2009; Snowden & Boone, 2007)). I’ve followed the research on Cynefin over the last few decades and it remains an intriguing and relevant tool.  There is a lot to be said about this sense making framework. For now, I want to emphasize the difference between the notion of a complicated domain and that of a complex domain. When we experience a situation as complicated, then by its very nature, we feel we can do a sufficiently complete analysis of the domain, design a solution, and implement it. When we experience a situation as complex, though, we know that the cause-and-effect relationships are too complex for a full analysis and all we can do is probe (try an intervention in the domain), sense the implications, and adjust accordingly.  
 
Both situations map on the notion of dynamic capabilities but in a different way. As such, the role of (enterprise) architecture is also different. In the complicated domain, we can make “the” design of some future situation and get ready to implement it. In the complex domain, though, all we can do is create architectures that are our best estimate of what we think might work, and act accordingly. Of course, in reality, problem domains have “parts” that appear complicated and other “parts” that appear more complex, making it challenging for architects to correctly play their part.  

Conclusion 

The above discussion introduces the notion of architecture capability. A lot more can be said about various elements that I have introduced and used in this introduction. For example: why would you create an architecture in the first place? And what are good ways of documenting an architecture in artifacts? When are the success factors against which (the performance of) an architecture capability can be evaluated?  
 
Answering these important questions is beyond the scope of this posting. In future posts, I will describe more details about the philosophy behind “doing architecture” (with our Realize method) as well as give an overview of the tools and techniques that we have used in practice over the last decade. For now, it is sufficient to understand that architecture contributes to the dynamic capability of an organization, and that it may help to deal with challenges in complicated and complex domains.  
 
The main/corresponding author for the Realize series is Bas van Gils. He can be reached at bas.vangils@strategy-alliance.com. If you have thoughts of questions, then feel free to reach out. 

References 

• Cummins, F. (2017). Building the Agile Enterprise with Capabilities, Collaborations and Values (2nd ed.). MK OMG. 
  
• Davis, P. K. (2002). Analytic Architecture for Capabilities-Based Planning, Mission-System Analysis, and Transformation. RAND. 
  
• French, S. (2013). Cynefin, statistics and decision analysis. Journal of the Operational Research Society, 64(4), 547–561.  
  
• Hasan, H., & Kazlauskas, A. (2009). Making sense of IS with the Cynefin framework. PACIS 2009 Proceedings, 47. 
  
• Pattij, M. (2025). Understanding enterprise architecture management in the context of today’s dynamic and digital world [PhD]. Open University. 
  
• Richardson, G. B. (1972). The Organisation of Industry. The Economic Journal, 82(327), 883. https://doi.org/10.2307/2230256 
  
• Snowden, D. J., & Boone, M. E. (2007). A Leader’s Framework for Decision Making. Harvard Business Review, 11, 68–76. 
  
• Teece, D. J., Pisano, G., & Shuen, A. (1997). Dynamic capabilities and strategic management. Strategic Management Journal, 18(7), 509–533.  
  
• The Open Group Architecture Forum. (2016). Open Group Guide—Business Capabilities (No. G161). The Open Group. 
  
• Van Riel, J. (2025). Leading with capabilities: Capability-based management as a driver for strategy implementation. Grammar factory publishing. 
  
• Wetering, R. van de. (2021). Understanding the Impact of Enterprise Architecture Driven Dynamic Capabilities on Agility: A Variance and fsQCA Study. Pacific Asia Journal of the Association for Information Systems, 13, 32–68. https://doi.org/10.17705/1pais.13402 
  
• Winter, S. G. (2003). Understanding dynamic capabilities. Strategic Management Journal, 24(10), 991–995.