REALIZE Blog series Fact sheet Business Blueprint & Operating Model 
 

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) behind the Realize approach, its main structure, and the strategy elaboration & stakeholder management phase. In this blog post, I will pick up where I left off and dive into the business blueprint & operating model phase.  

Goals 

In previous posts in this series, I defined architecture as a means to help achieve a successful digital transformation. The 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.  
 
In the strategy elaboration and stakeholder management phase, the objective was to understand (1) the goals and stakeholders field for the digital transformation initiative, and (2) the current lay of the land. Somewhat tongue in cheek, and mis-using the terms slightly, you could argue (Cambré et al., 2025; Recker, 2021):  

• That the strategy elaboration & stakeholder management phase was mostly deductive in nature: you collect data about the world as is, and deduce what it is we want to achieve.  
• The current business blueprint & target operating model phase, then, would be more inductive in nature: you build up an image of the future as you would like it to be, and then show how it addresses the agreed upon goals.  

This is a shift in thinking: we move from trying to understand the problem domain to attempting to create a vision for a disirable future. With that in mind, the goals for this phase are: 

•  Goal 1: develop a shared and agreed upon set of principles that form the guardrails for designing a business blueprint, and  
• Goal 2: develop a business blueprint (a high-level aspirational view) that visualizes the desired future to be achieved with the digital transformation initiative.  

On points and vectors 

An interesting sense-making framework that has been mentioned in previous posts in this series is cynefin (D. J. Snowden & Boone, 2007; Hasan & Kazlauskas, 2009; French, 2013; D. Snowden, 2022). Cynefin is a Welsh word that means ‘belonging’. The Cynefin is a sensemaking framework that helps to decide in what type of situation you are operating and what the appropriate response is. Figure below (taken from the complexsystemsframeworks website) illustrates the framework. 

I am not doing the full framework (and related theory) justice with this explanation, but I will attempt to give an overview of the 4+1 domains in Cynefin and related to architecture / digital transformation:

• The simple domain says: we are facing a challenge that is simple to solve. We sense what the challenge is, categorize it as “one of those” (we have done this before! We now a best pratice for this!) and then respond.
• Challenges that fit the complicated domain have the characteristic that they have a provably correct solution before they are implemented. Consider building a bridge: before putting a spade in the ground, we can create a design and prove (using the laws of physics) that the design will work for a given task. I may not have the skills to do so, but others do and they can use good practices to analyze the situation and respond with a correct solution.
• Challenges that fit in the complex domain do not have this characteristic. This is the realm of the messy, wicked problems (Rittel & Webber, 1973). Typically, the number of variables in such a challenge is high, and causal relations are mostly unknown. This means that the effect of an intervention is hard to predict. Typically this is the case in challenges that involve people and their behavior (uncertainty, interestes, politics, etc.) The respons strategy is to probe (to try something), to sense the effect of the probe, and then respond (strengthen/change course) accordingly. 
• The chaotic domain has challenges that are (life) threatening and above all demand urgent action. Think of a ransomware attack. This is not the situation to sit back and think about potential response strategies. The idea is to act first (the adage “a bad decision is better than no decision” comes to mind) and adjust when necessary.
• The disorder domain is in the middle. It is for those situations where you are not yet sure in which of the (other) domains you are operating.

It is my firm belief that digital transformation initiatives mostly operate in the complex domain even when we acknowledge the fact that “parts” of the transformation may be more ordered (in the sense that they belong to the simple or complicated domain). In terms of guiding the transformation with principles and blueprints, this means we have to think of a vector (a sense of direction) rather than a fixed end-point.

Borrowing the example of the operating model dimensions (Ross et al., 2014, 2019), we can come to the conclusion that it is a really good idea to integrate processes through (shared) data. Without specifying exactly and in great detail which data it concerns, how, where, and when we will integrate this data – we still have a sense of direction. It helps us to pay attention whenever a discussion leans towards local, non-integrated data.

Essentially, this means that we need to interpret the blueprints that we create in this phase accordingly: they’re not a (detailed) design but should convey a sense of direction.

Techniques

In this section, I will give a rough overview of the techniques that we tend to use in this phase of our Realize approach. Please beware that this is not a limitative list: you should use what works in your specific setting for achieving the goals in this phase.

Principles

The first technique is the use if architecture principles. A lot has been written about architecture principles in the scientific literature (Greefhorst & Proper, 2011; Haki & Legner, 2021; Grave, 2024). Principles are also the corner stone of various architecture methods such as TOGAF and GEA. I follow the definitions from Greefhorst and Proper which are as follows:

• Normative principle: a declarative statement that normatively prescribes a property of something.
• Design principle: a normative principle on the design of an artifact. As such, it is a declarative statement that normatively restricts design freedom.
• Architecture principle: a design principle included in an architecture. As such, it is a declarative statement that normaltively prescribes a property of the design of an artifact which is ncessary to ensure that the artifact meets essential requirements.

We tend to use principles in a larger constellation with (business) policies, principles, and (technical) standards. A full discussion is beyond this short introduction. Following the recommendations from literature, we tend to document principles with the following structure:

• Metadata (name/number, owner, version, dates, etc.)
• Statement of the principle
• Rationale for the principle
• Implications of following the principle
• Design instructions for following the principle
• Rules for exemption of using the principle

Visualizations

As discussed in the section “on points and vectors”, we believe in designing blueprints as a vector, suitable for setting a course for the digital transformation. More elaborate models can be created in other phases of Realize. The following diagram is borrowed from (Whelan & Whitla, 2022) and illustrates different types of visualizations that exist in the realm of digital transformation. 

Each of the different categories (pictures, diagrams, templated/ad-hoc, standards-based) visuals can work in this Realize phase. However, we tend to lean more towards pictures (particularly rich pictures from the soft systems methodology (Checkland & Scholes, 2005)), various unstructured diagrams, and templated models (particularly the business model canvas and associated templates (Osterwalder & Pigneur, 2013; Campbell et al., 2017; Osterwalder, 2014)). More information about these canvases is available aplenty on the internet and I will not repeat them here. Instead, I will end with an example that is inspired by a (recent) project that we did as Strategy Alliance as illustrated in the following diagram.

The diagram is a slight over-simplification of the actual project result. It does, however, illustrate the key points that will help the organization to stay on track with their digital transformation initiative. Key points:

• The organization has three main primary processes, each with their own data.
• These three processes need to function as a whole. Therefore, we introduce the notion of an integral primary process.
• Integration, here, means that data is shared among them. This helps to ensure that everyone is knowing what everyone else is doing. We do this through the shared data hub.
• This is also the way to connect the primary process, supporting processes, and the strategy process – and help the organization to function as a whole. 

Parting thoughts

The objective for this posting was to give an overview of the operating model & business blueprint phase in the Realize approach. I started by presenting the two main goals for this phase, and the fact that we are switching from attempting to understand the problem space to designing a (direction/vector for a) solution. 

A small personal note: I really like this phase in the Realize approach. To me, it requires a nice mix of analytical skills and creativity. Finding something that tells the right story tends to have high impact which can be very rewarding. I will admit that there is both a science and an art to this. I find that many professionals are reluctant to use creative drawing techniques and rely on (formal) models instead. My recommendation: just get your hands dirty and start doing it. You’ll be better at it than you probably think.

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

• Cambré, B., Elliott, K., & Fierens, J. (2025). How to design and develop a business research project: Demystifying academic research for business professionals (Paperback edition). Edward Elgar Publishing.
• Campbell, A., Gutierrez, M., & Lancelott, M. (2017). Operating model canvas: Aligning operations and organization with strategy. Van Haren Publishing.
• Checkland, P., & Scholes, J. (2005). Soft systems methodology in action: A 30-year retrospective (repr). Wiley.
• French, S. (2013). Cynefin, statistics and decision analysis. Journal of the Operational Research Society, 64(4), 547–561. https://doi.org/10.1057/jors.2012.23
• Grave, F. (2024). Enterprise architecture artifacts’ value for digital transformation. Exploring enterprise architectrue artifacts to improve organizational performance through digital transformations. [PhD]. Open University.
• Greefhorst, D., & Proper, E. (2011). Architecture Principles: The Cornerstones of Enterprise Architecture. Springer-Verlag Berlin Heidelberg. https://doi.org/10.1007/978-3-642-20279-7
• Haki, K., & Legner, C. (2021). The Mechanics of Enterprise Architecture Principles. Journal of the Association for Information Systems, 22(5), 1334–1375. https://doi.org/10.17705/1jais.00696
• Hasan, H., & Kazlauskas, A. (2009). Making sense of IS with the Cynefin framework. PACIS 2009 Proceedings, 47.
• Osterwalder, A. (with Pigneur, Y., Bernarda, G., Smith, A., & Papadakos, T.). (2014). Value proposition design: How to create products and services customers want. John Wiley & Sons.
• Osterwalder, A., & Pigneur, Y. (2013). Business model generation: A handbook for visionaries, game changers, and challengers. Wiley&Sons.
• Recker, J. (2021). Scientific research in information systems: A beginner’s guide (Second Edition). Springer. https://doi.org/https://doi.org/10.1007/978-3-030-85436-2
• Rittel, H. W. J., & Webber, M. M. (1973). Dilemmas in a general theory of planning. Policy Sciences, 4(2), 155–169.
• Ross, J. W., Beath, C. M., & Mocker, M. (2019). Designed for digital: How to architect your business for sustained success. MIT Press.
• Ross, J. W., Weill, P., & Robertson, D. (2014). Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press.
• Snowden, D. (2022). Cynefin: Weaving sense-making into the fabric of our world (R. Greenberg & B. Bertsch, Eds.; Edition 2). Cognitive Edge Ltd.
• Snowden, D. J., & Boone, M. E. (2007). A leader’s framework for decision making. Harvard Business Review, 11(68), 68–76.
• Whelan, J., & Whitla, S. (2022). Visualising Business Transformation: Pictures, Diagrams and the Pursuit of Shared Meaning. Routledge.