13   Transition Architecture: Managing Complex Roadmaps

Until now, this Guide made the effort and process simple by describing most of the concepts using a linear time scale. It gave an impression that creating a well aligned set of work packages vectored by business cycle and planning horizon gives you potential transition states and a near linear roadmap. Recall this simple statement made in Chapter 5 in the context of the EA Repository: “Baseline provides reference for all change. The target state is what stakeholders have approved. Transition states are partially realized targets between current state and target state. Mix the four characteristics of the EA Landscape: breadth, depth, time, and recency. Mix the different Architecture Projects that can work on the same subject at different times and at different levels of detail.” That’s the only hint to indicate real-world complexity.

In addition to characteristics, other organizational factors that add to complexity are:

This is the reality. One Enterprise roadmap gets broken down into segment, portfolio, or geography. The Enterprise will be pursuing more than one concurrent goal, say efficiency and retooling. For each business cycle, the roadmap is revisited to make adjustments, bottom-up and at times top-down. This is a clear use-case that drives the need for a good EA Repository: a repository that maintains the integrity of the current state and target state, but allows creation of variants.

13.1      Roadmap Grouping

Start with one version that supports the initial strategy. Flesh out the repository from strategy to project. Upon acceptance of the portfolio, create versions as necessary. Once the candidate versions are accepted, baseline both current and Target Architectures. Create multiple baselines of the current transitional state. Create copies of the architecture, one per variable, concern, or a related group of variables.

Use the same planning horizon to showcase the impact and outcome. The moment planning horizons change, analysis becomes complex and results in loss of continuity for most decisions.

Each distinct parent roadmap – say if there is a separate roadmap for European Union Operations and Australian Operations – name and identify them as such. Employ appropriate naming and versioning concepts for and derived roadmaps of those created for what-if analysis. Make it intuitive to identify discarded alternatives.

13.2      Comparing Architectures

The point of creating separate roadmaps is to align the scope of each Architecture Project. When the Enterprise has any one of the characteristic or organizational factors identified earlier in this chapter, it would make sense to create a separate Architecture Project and roadmap to deal with this complexity.

Employing a standard reference architecture for process, business terms, applications, etc., supports cross-project and cross-roadmap analysis. Using a standard model provides the flexibility required to map across implementation models of the solution suppliers. It also helps in evaluating bids and offers from potential suppliers. This is another place where use of ABBs would come in handy. Implementation and use of ABBs across projects can be analyzed with ease.

Basing all of the architectures on an implementation-neutral reference model allows impact of modifications to a specific architecture to be identified easily. As shown in Figure 17, the EA Repository tool could provide support to identify the change, whether it is to one of the attributes of an architectural component or a modification to the catalog of components. While working with a federated team, uses of such a tool and use of common reference models can go a long way to coordinate and communicate the impact of architecture changes. Within the roadmap, it is better to keep the analysis patterns consistent.

Figure 17: Using Repository for Managing Roadmaps – I

This same concept of comparing architectures can be used to create and analyze year-over-year modifications to the architecture. In Figure 18, the EA Repository tool in use allows the Practitioner to trace a change to the baseline or the revised version.

Figure 18: Impact Analysis of Architectures

When creating the roadmap, pay attention to impact of change. Any change, when introduced, will tarnish the efficiency, overall throughput, and sometimes call for duplicative investments. Such short-term negative impacts can mask deviations from the roadmap. Inject appropriate markers to identify any unintended sub-optimization or deviations from the roadmap. The value and outcome map should present the time to value and gain/loss at the end of the planning horizon.

13.3      General Guidance

A work package or an architecture specification that intersects more than one Architecture Project or change effort also introduces complexity. The environment for every Enterprise is highly dynamic, forcing a need for trade-off and expert judgment every so often. Implementation Projects are invariably insulated from all impact from developments in the external environment. Complexity happens because every transitional state is a fully functional and operational state for the Enterprise. The architecture and roadmap evolve to stay abreast or ahead of such external changes.

When starting afresh, the Practitioner potentially has the benefit of working with the limited set of information about the landscape. As the landscape is populated from ongoing Architecture Projects, continually pay attention to ruthless abstraction of detail. Set your biases and baggage aside. Set the stakeholder preference aside. It is all about the least and absolute necessary information to guide a choice. Keep the dataset consistent. Eliminate noise and distortions when performing analysis of architectures.

Common traps while creating roadmaps include incorrect scoping. The Architecture Project may exclude certain functions from the scope. Earlier chapters of this Guide explicitly warned you not to stray away from the charter of the Architecture Project. The fine-print is that, if you identify a need, a gap, call it out – don’t work on developing the architecture. It is the responsibility of the Practitioner to call out the dependency and document its existence and the disposition of the gap in the roadmap. Such deferred items will become its own roadmap. When developing architecture for this gap at a later date, make sure that you operate in a fixed block of time (same end dates as related roadmaps), not a fixed block of duration (say three years for each roadmap).

return to top of page

Copyright © 2022 The Open Group, All Rights Reserved.
TOGAF® is a registered trademark of The Open Group
<<< Previous Home Next >>>