Here we run through the 5 types of architecture that in our experience represent the hallmarks of best practice multiple architecture analysis.
We’ve had a great response to our article “How to build an EA roadmap: 4 styles to consider”. The accuracy and certainty achieved by a “multiple architecture” roadmap in particular resonated with a lot of you.
So here we’d like to drill down further into this concept of multiple architecture analysis, which maps out current states, transition states and future states as discrete options.
Multiple architecture analysis – hallmarks of best practice
In our experience, there are a number of hallmarks of best practice multiple architecture analysis. Expert execution of this approach with a tool with the correct functionality will yield a mature and robust roadmap, allowing your business to compare past- current- and future-states in setting the optimal course.
In a best practice approach:
- The EA team will be doing much more than comparing “pictures” of two or more architectures
- The EA team will be comparing the numerical values attached to different architectures
- Each architecture should be discrete, so that you can quantitatively compare different states according to the KPIs the business is focused on improving
- The architectures under consideration will include a current state plus at least one “target” or “future state” architecture
- The EA team will achieve superior results by continually comparing the current state architecture with a range of “sandbox” or “test” architectures.
In the ABACUS enterprise architecture toolset you can set up as many discreet “possible” architectures as you like, providing a safe, secure environment to explore plans and ideas which can be saved or frozen, then re-explored when you are preparing to present various options or scenarios to your colleagues.
Current state architectures
The first thing most EAs will do with an enterprise repository is to build a current state architecture.
But of course the enterprise is ever-changing so what was the “current state” today is “history” tomorrow.
In order to manage this, we believe it is useful to consider a number of architectures to capture the dynamic nature of your existing business. It is straightforward to set these up in the ABACUS toolset.
1) Historical, Archived or As-Was architectures – These are old versions of the enterprise or As-Was’s, As-Is or Production architectures which have been frozen for updating. They can be retained in the ABACUS repository for analytics and reporting purposes.
What is the point of historical architectures? They can be incredibly useful in telling a story of business change or improvement. For instance, it’s great to be able to zero in and show that you’re currently spending $5M on something that cost you $10M two years ago, and that through further efficiencies, this spend could be reduced to $3M.
2) Current State, Production or As-Is architectures – ABACUS users typically keep these actual architectures up-to-date with changes they know have occurred in the enterprise. These may be data updates or the addition of new capabilities. When a significant milestone is reached, such as the end of a quarter or year, we encourage users to baseline the current state by “rolling forward” the latest actual architecture and archiving the current one to indicate that it is now a Historical or As-Was architecture. This effectively “updates” the baseline whilst also setting up a clear version control process in the tool.
3) Staging, Soon-To-Be or Nearly-Is architectures – These are architectures where the users of the repository have decided to work in a quarantined area until that point where the architecture is approved and made “public”, becoming a Production or As-Is architecture.
Moving forward: future state architectures and roadmapping
When an ABACUS user wants to move on to planning or roadmapping they begin by taking the latest actual or current state architecture and “evolving” it. By creating these various “what-if” architectures they are able to confidently explore a solution space for the future.
This exploratory process will generally result in several detailed options and ultimately a set of planned architectures can be selected.
In ABACUS, we offer 2 types of planned or “branch” architectures:
4) Transition, Interim or May-Be architectures – These are intermediate states that represent natural stages along the path to a certain end state. They may be the logical stages or options of the transformation program (e.g. phase 1, phase 2 option A, phase 2 option B etc) or time-based intervals (e.g. year 1, year 2 etc).
5) Target, Future State or To-Be architectures – This is the combination of all the planned changes from all the transition architectures against a given baseline or actual architecture.
The development map or decision tree
Stepping back, you will see what the sum total of all of these architectures will allow you to create. In ABACUS you can produce a “tree” which logs a “trunk” of historical and current state baselines with speculative transition and future state architectures “branching” off it.
This tree-based approach will be very familiar to anyone who has managed software development – it has served that community very well for many years. And just like in software development, users can do “diffs” and “merges” between architectures in ABACUS.
Take a look at the figure below. You will see that 2011, 2012, 2013 and up to 2014 Q3 are Historical architectures and 2014 Q4 is the Current State architecture. The figure also shows an upcoming / Staging architecture (2015 Q1) with various options as potential roadmaps for 2015 and beyond.
The 2020 Target architecture for the business is then shown as the culmination of the Transition architectures from the Current State. You’ll note that it’s possible to record many intermediate architectures between the Current State architecture and the Target architecture for this business.
We find it is typical for clients to archive a historical architecture approximately every 3 months. This means rolling your baseline forward and freezing your current architecture. This also creates a saved state against which you can later perform longitudinal analysis.
The EA team is also in control of deciding when a project will become a separate architecture. For instance, if you’re particularly uncertain about a decision or transformation facing your company, and getting it wrong could be extremely costly, then yes, it is a good idea to log it as a separate architecture. This allows you to perform trade-off analysis against that state, or wind it back later on.
Using ABACUS you can model “multiple architectures” to describe and analyze the past, the present and the future of your business. By having these different architectures you are able to objectively compare options, see how the business has changed over time and determine the optimal path for its future.
To request a demonstration of the ABACUS toolset including examples of successful deployments in your industry please contact us at email@example.com