By Mats Ouborg & Bas van Gils
What do you do when you have a high level solution of your digital transformation goals but there are still too many questions to “dig in and get your hands dirty”? Continuing the analysis and adding more details to your insights appears be the logical step. However, this creates some risks. For instance, how do you prevent slowly developed and extremely detailed architecture views when speed (due to changing environments) is required? Along the same line of reasoning: is it even possible to create models for a future state that will be implemented, or is the future so uncertain that models should be seen more as a hypothesis for a future direction? (see for example the CYNEFIN framework)
In our previous blogs we’ve elaborated the first steps of our REALIZE method. During “Strategy Elaboration & Stakeholder Mobilization” and “Business Blueprint & Operating Model”, we have created a high-level solution of the digital transformation goals and a shared vision for the direction of the enterprise. This blog will explain what happens in the next step: “Adaptive Architecture & Design”. In this step, the high-level solution is translated to an architecture, which adds more detail. We typically develop just enough baseline / target architecture to be able to assess impact.
The term ‘architecture’ is often associated with big design up front in an IT-setting. This, however, is not justified. In line with the formal ISO/IEC/IEEE standard, we see the architecture of a system as its fundamental organization, and the principles guiding its design and evolution. Architecture descriptions address the concerns of key stakeholders in light of a (digital) transformation. In other words, architecture is a discipline that is concerned with a big-picture analysis of where we are heading as well as the analysis of why this should be the case.
As with so many things, different settings require a different approach to doing architecture work. In our view, organizations should build an architecture capability that can handle both slow and fast architecture. In practice, the combination (multi-dynamic architecture) is likely required.
In situations where the operational core and systems of record is impacted we typically see a slow approach to architecture. This approach is characterized by a ‘waterfall’ approach, relying on planning, risk mitigation and extensive design for implementation. In situations where the systems of differentiation are impacted, we tend to see a greater need for speed. This is where fast architecture comes into play. Here we see agile architectures, keeping pace with agile delivery teams. In these cases, architecture development and realization go hand in hand. In situations where systems of innovation are impacted, we typically avoid doing any architecture at all. This is the realm of prototypes and experiments.
One of the characteristics of digital transformation is that different layers (i.e. operational core/ systems of record and systems of differentiation) are impacted; change is all over the place. The key to success in these cases is to use a solid business blue print and operating model in order to do just enough, just in time architecture development to facilitate both the need for speed as well as do justice to risk management requirements.
ArchiMate is the language of choice for specifying architectures. The language is extensive, with elements for motivation, strategy, business/ application/ technology/ physical architectures as well as plateau and project planning. Not every aspect of the language is equally usable. We use whatever is required to get the job done: quite often this means that we simplify the language quite a bit. This is something we do with your team to ensure alignment with other approaches already used in the organization, and to make sure that the modelling effort can be sustained after the REALIZE cycle is completed.
One of the key mechanisms that is used in the REALIZE approach is to specify architectures at two levels:
- Architecture building blocks: specify what we want to achieve ultimately
- Solution building blocks: specify options for actual realization, e.g. a fully automated solution or a semi-automated solution
This way of working gives a good insight in the (architecture) decisions that have been made in developing solutions. Together with the capability gap analysis, these models also provide a sound basis for (detailed) gap analysis and roadmapping.
Our approach in architecture is dynamic and adaptive. Architecture is only useful when the excessiveness of its usage is assessed first. We then focus on creating the different solution candidates which can then be elaborated and selected. This will help it keep it simple as possible, and make it adaptive and understandable for the ever changing organization.