REALIZE Blog series Fact sheet Adaptive Architecture & Design 
 

Introduction 

This blog is part of a series of posting on our Realize approach to digital transformation. So far, I have laid the (theoretical/philosophical) foundation behind the Realize approach, its main structure, and the first two phases. In this blog post, I will pick up where I left off and dive into the adaptive architecture & design phase.  

Journey 

Consider where we are in the digital transformation journey. We are operating in a (mostly) complex domain and consider the transformation with a pragmatist paradigm. This means: we acknowledge that some aspects of the problem space are knowable (positivism) but for other areas, stakeholders will have a different perspective (subjectivism, and perhaps even constructionism).  To shape and execute a transformation, professionals will have to collaborate and align their thinking.  
 
In the strategy elaboration & stakeholder engagement phase, the focus was on attempting to understand (1) what it is that we want to achieve in the transformation initiative and (2) what the stakeholder playing field looks like. The subsequent phase is about developing a business blueprint & target operating model. The focus shifts from trying to understand the problem space, to creating a big picture overview of the solution: what are the key principles? What is the high-level overview of the solution that we think we want to realize? Until we verify with key stakeholders that we got these phases it right, the outcomes of so far should be treated as a working hypothesis. This verification should be an on-going process since insights, priorities, and sense of direction may shift (but hopefully not too much).  

Goals 

With a clear sense of direction, now is the time to “dive into the real architecture” in the adaptive architecture and design phase. The name emerged after a discussion about the tendency of architects being somewhat “rigid” and too “big design up front” in their views. We wanted the name of this phase to reflect our stance that architectures are not fixed and that architecting is an on-going process of adjustment to an ever-changing environment. Recall that definition for architecture was:  
 
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 are intended to help achieve some level of coherence in the system. The artefacts are created by an architecture capability. The architecture, as expressed through artifacts, can be implemented.  
 
With this in mind, it should be no surprise that the goals for this phase are as follows: 

• Goal 1: develop (and continually adjust/adapt) a shared and agreed upon (formal) target architecture model that fleshes out the relevant details of the business blueprint, within the guardrails of architecture principles, as basis for developing a roadmap, and  
• Goal 2: develop the communication-oriented artefacts to socialize and get approval for the architecture.   

In our view, the formal modeling part is important. This phrase is intended to signify the use for well-defined and sufficiently price modeling approaches such as DEMO (Dietz & Mulder, 2020, 2025), ArchiMate (Lankhorst, 2017; Van Gils, 2017), BIZBOK (Business Architecture Guild, 2026),or even UML (Booch, 2005). In our view, no single approach (language/ method/ etc.) is “perfect” for all situations and our recommendation is to use what you expect to work well in your specific context.  

Techniques 

In this section, I will give a very short introduction to three commonly used techniques for this phase: DEMO, ArchiMate, and the BIZBOK.  

DEMO 

DEMO (Design & Engineering Methodology for Organizations) is a methodology conceived in the 1980s by prof. Dietz. It is intended for modeling and analyzing the “essential” structure of business processes and organizations. Its theoretical foundation lies in the language/action perspective, which draws on speech act theory as developed in the philosophy of language by Austin, Searle, and Habermas. The methodology centers around the idea that production of facts results of production and coordination acts.  
 
The central construct, as illustrated shortly, is a transaction which is the complete process from requesting a fact to be established to accepting the result. Transactions can be defined at the ontological level, the infological level, and the datalogical level. An extensive set of diagrams and specifications together are intended to communicate the “essence” of the organization.  
 
As said, the basic building block of DEMO is the transaction. It is a construct where communication/coordination and production meet. The following diagram illustrates the main idea. 

• In a transaction, an actor in a role makes a request for some fact to be established (for example: to complete a specific purchase).  
• The interlocutor assesses the request (is it a legitimate request? Is this actor permitted to make this request?) and may promise to estalblish the requested fact.  
• After this, production takes place.  
• When production is done, this may be stated.  
• The actor that made the request will review the results (Is this what I requested? Does it meet my expectations?) and accept the result.   

This is the “happy flow” of the basic pattern and the model must account for variations too. For example, the purchase completer may not promise to established the fact because the purchaser is not permitted to make the request (you have to be 18+ years old to buy alcohol). Or, the purchaser may not accept the final result (the product is broken, of insufficient quality, etc.) 
 
The simple example shows a transaction (that follows the request – promise – state – accept pattern) between a purchaser and the purchase completer. In order to estabablish the requested fact, the purchase completer engages in a transaction with a payer (to establish the fact that the purchase is paid for) and with the transporter (to establish the fact that the product must be transported).  
 
Note: both diagrams are simplified versions of a complete and correct diagram. They are intended to illustrate how DEMO works.   

ArchiMate 

It is a little dangerous to write about ArchiMate at this point in time. ArchiMate 4 has just been released a week ago – and I havent had the opportunity to do a full review yet. I am fairly confidet that the example below is in line with the new standard but a more thorough read of the new standard is necessary. Therefore, the explanation here will be brief. We will cover the new version of ArchiMate in a separate blogpost after it has been released. 
 
The original version of ArchiMate was developed in the early 2000s in a mixed science/industry project. It was adopted by the OpenGroup as an “open” standard a few years later as a sister standard to TOGAF. The original core model (with a business, application, technology layer / active structure, passive structure, behavior aspect) was at that point extended with a motivation extension and an implementation extension. This allowed modellers to capture what :  

• Motivation: how do we see stakeholders and their concerns? What is the state of affairs regarding these concerns? What goals and principles can we agree on? 
• Architecture: how do we see/design the interplay between business/ application/ technology aspects? 
• Implementation: how do we move from where we are to where we want to be? 

The ArchiMate 3.x series made further additions in the form of a strategy layer and a “physical” (sub)layer. Thise changes indicate that the language (like natural language) continues to evolve with ever changing (modeling) needs. In the ArchiMAte 4.x series, further changes have been made – and we will discuss them later in a separate blogpost. The following model provides an idea of what a (simplified) architecture might look like based on current understanding of ArchiMate 4.x.  

Here, we start with (an unknown actor in) the customer role. From the perspective of the customer, engagement starts with placing an order and ends when the order is received. Both are modeled as services. From the perspective of MyCompany (modeled as a business actor) in the role of supplier (a role), the process starts by receiving an order and ends when we ship the order. In the handle payment process step, we use the services of Mollie (business actor) in the role of payment handling provider. The actual handling of the payment (between Mollie and the unknown actor in the customer role) is out of scope in this diagram.  
 
Note: the model only concentrates on the business aspects of the architecture. Application and infrastructure aspects are not included to keep this introductory diagram easy to read. 

BIZBOK 

The third and final framework to be discussed here is the BIZBOK, created by the business architecture guild. The standard is developed by a large community of professionals and is therefore rooted in daily practice. It links to (scientific) theories in various places. The BIZBOK provides a shared vocabulary, framework, and set of practices for the discipline of business architecture — essentially defining what business architecture is and how to do it consistently across organizations. It  is structured around a set of interconnected core domains that together describe an enterprise from a business perspective.  
 
The four foundational domains are Value Streams (how a business delivers value to stakeholders through a sequence of stages), Capabilities (what a business does, independent of how or by whom), Organization (the structure of business units, roles, and stakeholders), and Information (the key business objects and their relationships). 

This short example gives a (simplified) value stream map with four value stages. Each of the value stages is described in terms of the participating actors, entry/exit criteria (what must be true at the start of the value stage, what will be true at the end), the value items, and the required capabilities. 
 
Note that the use of capabilities as a modeling construct is increasingly popular. It is also used in e.g. ArchiMate and remains a topic to be studied more deeply (Lankhorst, 2017; Van Riel, 2025). 
 

Parting thoughts 

The objective for this posting was to give an overview of the adaptive architecture & design phase in the Realize approach. I started by reviewing our philosophical orientation (pragmatist) and where we are in the digital transformation process. Based on this, I positioned the goals for the phase and presented three approaches that we typically use in our work. 
 
One thing that I want to mention here is the need for open approaches. With this I refer to “freedom” rather than “free beer”. In my view, it would be beneficial to the community at large if everyone has access to a standard, can use it freely in teaching, consultancy, in problem solving in a specific organization, and to develop tool support for it. This is rarely the case.  
 
My understanding regarding “is it free or not” is as follows. DEMO was developed in the scientific domain. At this point in time, the formal language specification is maintained by a foundation. Other than that, use of DEMO in any shape and form is free. ArchiMate was developed in a scientific/industry consortium and is now maintained by The Open Group with a strict set of guidelines regarding what is and is not allowed and costs (e.g. for obtaining a certification, for being allowed the use of ArchiMate in a commercial setting, etc.) may be required. BIZBOK is maintained by volunteers, and an editorial board makes the decision about further development. Access to the full guide is a membership benefit (which costs a small fee). There is a feedback loop with the community: practitioners apply the framework, encounter gaps or improvements, and channel those back through volunteer teams. 
 
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 

• Booch, G. (with Jacobson, I., Rumbaugh, J., & Safari Tech Books Online). (2005). The unified modeling language user guide (2nd ed). Addison-Wesley. 
  
• Business Architecture Guild. (2026). A guide to the business architecture body of knowledge (BIZBOK Guide) (15th ed.). https://www.businessarchitectureguild.org/ 
  
• Dietz, J. L. G., & Mulder, J. B. F. (2020). Enterprise Ontology. A human-centric approach to understanding the essence of organisation. Springer Berlin Heidelberg. https://doi.org/https://doi.org/10.1007/978-3-030-38854-6 
  
• Dietz, J. L. G., & Mulder, J. B. F. (2025). Enterprise design fundamentals: Settling an enterprise business and devising the enterprise organisation. Springer. https://doi.org/10.1007/978-3-031-83262-8 
  
• Lankhorst, M. M. (Ed.). (2017). Enterprise architecture at work: Modelling, communication and analysis (4th ed). Springer. 
  
• Van Gils, B. (2017). SciFi architecture. Organizational Design and Enterprise Engineering, 1(1). 
  
• Van Riel, J. (2025). Leading with capabilities: Capability-based management as a driver for strategy implementation. Grammar factory publishing.