REALIZE Blog series Main structure

Introduction

This blog is part of a series of posting on our Realize approach to digital transformation. So far, I have discussed and attempted to define several key notions as well as the philosophical foundations behind the Realize approach. Now, finally, it is time to dig into its main structure. The purpose of this post is to explains two things. First, I will introduce the main structure of Realize. It is an iterative/incremental approach. As discussed in the previous post, we adjust the approach based on customer-specific situations when we need to. Second, I will also show that the Realize approach resembles Design Science Research (DSR). 

History 

When we (Raymond Slot and myself) started Strategy Alliance, we wanted to design our own approach to digital transformation. We wanted to go beyond “let’s just cobble something together” and at least have a little bit of a foundation. We weren’t exactly sure how to go about this but looking at literature seemed like a good start. 

Luckily, I have a fairly big library with a many books and articles about (digital) transformation, leadership, digital strategy, and (enterprise) architecture. Of course we looked at the typical architecture frameworks (TOGAF, ArchiMate, Novius) and project management frameworks (Prince2, MoP, SAFe, Scrum). We also looked at some popular related works with a link to science (Gouillart & Kelly, 1995; Ross et al., 2014; Rouse, 2006; Westerman et al., 2014). 

From these frameworks, we made lists of typical activities and deliverables that we encountered. Most of them have activities around visioning, risk management, and stakeholder analysis (just to name a few). We grouped these into logical units and these became the basis of the first version of Realize. 

Structure

The main structure of Realize hasn’t changed much over the last 10 years. It is illustrated below. Based on suggestions by “friend of the company” Martin van Battum, we did make a version with more human elements (figurines, to emphasize that in an increasingly digital world, you have to put the people first) but that never really stuck. It added clutter to the diagram and we essentially decided to go back to the simpler form. 

The following list explains the main structure. The dark blue “loop” in the background emphasizes the iterative and incremental nature of digital transformation. We believe it is not a matter of “making a plan, executing it, and back to business as usual”. 

The process more or less starts where the process of strategic planning ends. Somewhat tongue-in-cheek, we noticed that a lot of the big strategy consultancies at the time made a fancy PowerPoint-pack and then ran off, leaving organizations confused as to what to do. It appears that this is changing under the influence of increased AI-usage, but still the pattern is there. 

In the strategy elaboration & stakeholder mobilization phase, the objective is twofold. On the one hand, we want to get a better shared understanding of what it is that we want to achieve through digital transformation. Is it all about more efficiency? Or perhaps effectiveness? Do we want to cut costs? Or improve quality by using technology? It is imperative that there is a shared understanding of what we want to achieve. It is often assumed that everyone knows what we want and where we are going, only to find out too late that that is not the case (i.e. because of poor communication, because of power struggles, or simply because a clear direction hasn’t been set yet). To achieve the shared understanding, we need to engage the right stakeholders. The other side of that coin is: when we have the shared understanding, we need these stakeholders to work on the next phases and get the transformation-wheels in motion. 

In the business blueprint and operating model phase, we switch from problem analysis to thinking about a solution. In this phase, the focus is on the big picture only. If we cannot agree on the big picture/sense of direction, then it makes no sense to dive into the details (in the next phase). Typically we take the operating model into account in two senses of the world: (1) how the organization actually operates (Campbell et al., 2017) and (2) the choice for a target operating model type – the degree of standardization and integration of processes (Ross et al., 2014). We typically articulate a set of principles for a solution space (Greefhorst & Proper, 2011) and use these to create a high-level, communication oriented blueprint of what we think the future should look like. This blueprint serves as the anchor for further shaping the transformation. 

We then move to a moder detailed oriented phase: adaptive architecture and design. The name of the phase is deliberate. The field of (enterprise) architecture has a “big design up front’ reputation, where everything is set in stone once the architect is done. Worse, it is often said that the architecture is more important than detailed design and cannot be changed. We wanted to emphasize the fact that architectures should not be set in stone: as more information becomes available (i.e. by going around the Realize loop a few times), we should be able to adapt. We also wanted to emphasize the fact that architecture and (more detailed) design tend to go hand in hand. We tend to use ArchiMate – even though we are well aware that it has quite a few shortcomings. 

The name for the next phase is quite tricky. We tried several versions and ended up with migration strategy and value management. Truth be told, we do change the name in specific engagements when we have to. At this point in the Realize loop, we have a pretty good understanding of a) where we are, and b) where we want to go with the organization. The question to be address is: how do we make the transition? With the naming, we wanted to emphasize that we need to strategize and carefully decide how to make the transition. We advocate an approach for roadmapping that balances between (early) value creation on the one hand, and sufficient attention to building a sound foundation on the other. 

This brings us to change execution which is where the proverbial rubber hits the road. Based on the analysis of what we want to achieve, the big picture, the architecture, and the roadmap, we now execute the transformation. Note that this goes beyond technology. The key point of a transformation is that we are trying to change the fundamentals, which may include processes, roles and responsibilities, data, systems, and even culture. Therefore, change execution should be seen as a broad topic. 

Going around the Realize loop is a good way to shape and execute a transformation. We know that this doesn’t happen simply because we want it to happen. This is where governance and support come in. The governance part is about the formal roles, accountability, and decision making. We see this as the “top down” part. At the same time, we are very well aware that we ask difficult things from colleagues: they are doing their normal job and now also have to think about a potentially radically different future version of the organization. They may not have the knowledge, skills, or time to do so. Therefore, we wanted to emphasize in the name of this phase that these colleagues need support if we want them to be successful. 

Design science

Loosely speaking, Design Science Research (DSR) is a research method that aims to improve a situation by treating it with an artefact and doing so by a) building on/adding to the scientific body of knowledge, and b) using scientific tools and techniques. There are many flavors of DSR. For purposes of this post, I will use Wieringa’s Design Science Methodology (Wieringa, 2014). The main structure is illustrated below:

I will discuss each of the three layers in turn and attempt to focus only on the essence:

• ·Social context: this is the realm of the problem domain where we want to make changes. This is where the problem exists that we want to “treat” with an artefact. As an example: improving business processes by improving underlying data flows such that stakeholders have timely and correct information at their disposal in order to make better business decisions. This is also where stakeholders live, and they set the constraints on the artefact we intend to create. 
• Knowledge context: in creating the artefact, we want to use and contribute to the body of knowledge. We can do this on two levels of abstraction: (1) knowledge about the problem-solving process/the way we want to tackle the problem, and (2) answering knowledge questions about the problem domain itself. 
• Design science: This is where we want to create (improved) designs to meet the goals from the social context, within the constraints that are set, and leveraging insights from the knowledge context. Note that design questions have many underlying knowledge questions. For example, if we do want to improve a business process by addressing the underlying data flows, we would want to know what patterns have already been researched, before we start designing our own.

In my opinion, the similarities with Realize are striking. In Realize, we also operate in a social context – the customer context. We also have to deal with a knowledge context, notably (1) industry reports, (2) documentation of/about the customer, (3) documentation we have of previous/similar engagements, etc. Lastly, we also make designs in Realize. Especially in the business blueprint & operating model phase and the adaptive architecture and design phase. To some extent also in the migration strategy and value management phase. 

In a way, the similarities are coincidental: we did not design Realize to mimic DSR. At the same time, it is not really a coincidence. It makes a lot of sense (particularly using a pragmatist philosophy) to make sure we understand the problem domain and its stakeholders, as well as use the existing bodies of knowledge when creating designs that shape a digital transformation. 

Conclusion

In this post, we explained the main structure of Realize. The story is rater linear, explaining how you go from strategy to execution. It doesn’t do justice to the need for adaption to specific situations, nor to the iterative and incremental nature of the approach. We discuss these in more detail in the next post. 

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

• Campbell, A., Gutierrez, M., & Lancelott, M. (2017). Operating model canvas: Aligning operations and organization with strategy. Van Haren Publishing.
  
• Gouillart, F. J., & Kelly, J. N. (1995). Transforming the organization. McGraw-Hill.
  
• 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
  
• Ross, J. W., Weill, P., & Robertson, D. (2014). Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business Review Press.
  
• Rouse, W. B. (Ed.). (2006). Enterprise transformation: Understanding and enabling fundamental change. Wiley-Interscience. https://doi.org/10.1002/0470007826
  
• Westerman, G., Bonnet, D., & McAfee, A. (2014). Leading digital: Turning technology into business transformation. Harvard Business Review Press.
  
• Wieringa, R. (2014). Design science methodology for information systems and software engineering. Springer.