When an organisation makes a significant strategic change, this can result in the need for a large-scale digital transformation. This may feel like you have a mountain to climb, or perhaps several mountains. The organisation may need to modify or gain capabilities in order to meet market demands. This will likely have a profound effect on the architecture of the organisation, for example, decommissioning of legacy systems, launch of new systems, changes in work processes or re-structuring the organisation. These types of changes are often long-term engagements since they affect so many aspects of the organisation’s business, and since the scope of change is often large, they represent a challenge in managing the transformation.
In such large-scale transformations the architect can aid a smooth transformation by providing a solid plan describing how the architecture will change over time. This delivers the following benefits:
- Provides a common plan for all stakeholders
- Helps make the transformation manageable
- Ensures the right activities are done at the right time
- Helps to mitigate business risk
- Provides tangible deliverables and goals for the transformation
I often use a transition architecture approach when working with these large changes. This approach is inspired by methods described in TOGAF ADM (in particular Phase E: Opportunities and Solutions) and provides an iterative approach to the transformation.
When starting a digital transformation, we should know at least two things before executing the strategy:
- The current state of the architecture (sometimes referred to as “as-is”)
- How we want the architecture to be when the transformation is delivered (sometimes referred to as “to-be”)
The current state of the architecture is the Baseline Architecture. This is the current architecture of the organisation which is deployed and operational, as we speak. We can describe the Baseline Architecture by analyzing the current operations within the organisation.
How we want the architecture to be, is largely formed by strategic objectives, which are aligned with the goals for the digital transformation. The objectives provide the architect with a foundation on which to construct the future architecture. This is the Target Architecture.
Since the Target Architecture is often planned for the long-term, it is prone to change. So, we can think of the Target Architecture as a guiding light. It is important to get the balance of detail right in the Target Architecture, just enough detail to guide the transformation. Putting too much detail in the target architecture will make it difficult and time consuming to maintain, as changes occur over time.
Working with just the Baseline Architecture and the Target Architecture presents a problem. The gap between the two architectures is often substantial, and this presents a challenge in managing the transformation in a single jump. We also want to deliver value to the organisation and its customers as quickly as possible, so it is an advantage to deliver parts of the transformation as we go. This is where we can use Transition Architectures to make management of the transformation easier and deliver value incrementally.
The Transition Architectures are like milestones on the way to the Target Architecture. These contain the detailed architecture descriptions and the closer the transition is to delivery, the more detailed the architecture description.
Starting from the Baseline Architecture we can consider how we can change the current architecture in a series of deliverables which will eventually result in the Target Architecture. A good principle is to think about the minimal changes that deliver value in each stage, and the business priorities of the organisation. For example, in the first transition we may focus on a specific functionality, capability or organisational unit which delivers high value.
In large transformations, it is common that each transition will require changes to a number of aspects in the organisation, for example, several systems may change, work processes change, training for personnel is required or infrastructure is modified. These can be viewed as the deliverables of the transition, and may well be executed as separate projects.
Since each digital transformation is unique, the viewpoints used to describe the architecture depend on the type of transformation required. The way the architect describes the architecture is specific to the transformation scenario and relies on the skill and experience of the architect to choose the right viewpoints.
There are many viewpoints which can be used to describe a transition architecture, the diagram above shows an example of the logical system landscape viewpoint which I often use to show how the system landscape will change. This viewpoint shows all the systems in the landscape and their information flows, where each information flow can be regarded as a dependency. This is often a useful way to communicate a transition architecture with stakeholders as it shows existing systems in the system landscape, and systems which will be launched when the transition is complete (boxes with dotted lines). Variants of this viewpoint can be used to show other aspects of the system landscape such as, systems which are decommissioned, systems which are modified, or systems which are unchanged. This viewpoint can be used with many types of stakeholders and a deep technical knowledge is not required to understand the system landscape.
Understanding the information flow between systems in a transformation is really useful as is provides an understanding to all stakeholders regarding complexity, and highlights the need for collaboration between the various product/system owners. For example, perhaps we cannot decommission a system until some other systems are in place, or we cannot change a process until the supporting systems are launched.
A digital transformation which requires several transitions, in this case, would have a logical system landscape view for each transition showing the progression towards the Target Architecture.
As mentioned earlier, we are often working with long timescales (often years) and should expect the Target Architecture to change during the execution of the transformation. It is therefore important to continually review the Target Architecture and adjust Transition Architectures to make sure they are aligned. I find that working with a large digital transformation in this way increases manageability, and provides stakeholders with a common view of deliverables over time. Using this method facilitates delivering value as quickly as possible without having to fully implement the Target Architecture, this aids agility. At the same time the Target Architecture allows stakeholders to adjust their strategy and future state providing a long-term guiding light for the transformation.
Architecturality 