Architecture, whether at the enterprise level, domain level, or solution level often describes a target / ideal state. Yet the leap from the as-is landscape to the future state is often significant and requires intermediate architectural states. Getting these transition architectures right can mean the difference between future state success or failure.
Real World Scenarios
Not long ago, I worked on an ERP rationalization project whereby four different ERP solutions needed to be consolidated into one. There were three legacy ERP systems and an ERP stack from an acquisition. Finally there was the target or “greenfield” ERP environment in which everything would be migrated to.
However, the task of reconciling four legacy systems’ business process was virtually insurmountable. Trying to coalesce finance, supply chain, and HR processes across four systems and two operating companies created a roadmap that looked nothing less than terrifying. We needed to take a step back and think about moving discrete business functions and processes over to the greenfield rather than moving entire ERP platforms (and all of the business functions) all at once.
Our divide and conquer plan would dictate that finance moved first, then HR, and finally the supply chain and material requirements planning teams. This required a series of “sub” architectures to get us to our final state of to-be nirvana. A temporal coexistence strategy, if you will.
Transition Architectures Explained
Put simply, a transition architecture is one or more stepping stones towards a final target state. A transition architecture clearly identifies which new objects are introduced and when, while at the same time, which components are to be sunset and when.
Similar to a versioned piece of software, each “release” (iteration of the transitional architecture) adds new functionality while culling legacy components.
The Importance of Transition Architectures
Everyone loves new things, yet people hesitate to remove things. However, when transition architectures are ignored, the symptoms are obvious: multiple tools/stacks, integration complexity, and astronomical software licensing across numerous vendors.
It’s absolutely crucial to hold firm to the removal of tech debt to ensure the enterprise stack avoids ballooning into an additive mess. In other words, for every new piece of technology introduced, a corresponding sunset plan should be considered and implemented whenever possible. It’s about evolving by way of adding and subtracting; not piling on additional layers of complexity that co-mingles the new and old infrastructure forever.
Baking Transitional States into your Solutions
There are many different ways to integrate transition architectures into solution, domain, and enterprise-level architecture practices. A technique I employ borrows a page or two from the product management world. The overall solution will have release versions, such as 1.0, 1.1, and 2.0. Subcomponents may be versioned as well. This is shown below:
The beauty of leveraging transition architectures is that they’re inherently iterative. They allow you to keep crisp focus on the near-term states, while keeping future states progressively coarser-grained. Moreover, each iteration allows a cushion for pivots so that architects aren’t locked into a waterfall or big-bang marches to target states which may turn out to be incorrect after enduring some real-world experience.
