Here we run through a few best-practices when building an enterprise architecture roadmap, and provide a structure to set your course.
You’ve decided to go to Hawaii for some sun and seafood. You’ve put a picture of your “target state” – Hawaii – on your wall. What you now need is a detailed plan which sets out the best path to take on each leg of your journey.
In the world of enterprise architecture, we call this process “roadmapping”. Of course, the destination isn’t Hawaii, but a future state your business is aiming to achieve. The most effective roadmaps also consider the multiple ways of completing the entire journey, not just one leg. They consider multiple options for each of the transfers, whether to fly or take a cruise, stopovers along the way etc. Likewise for a business.
Holding all of these permutations in your head is, of course, impossible. And you’ll quickly outgrow basic business tools such as Excel and PowerPoint. That’s why you turn to your Enterprise Architect.
Their role is to chart these multiple options and weigh which are best in order to navigate with confidence towards the desired business endpoint.
The long game
The most effective roadmapping involves thinking about the long game. It’s not just setting strategy and budget for next year. By considering the forks in the road well in advance, a business will have time to choose the optimal route.
Also, don’t underestimate the importance of investing time in building an accurate snapshot of your current state. Tempting as it may be to simply picture your ideal ‘green field’ or ‘blue sky’ state and start working towards it, this rarely works.
To put it more succinctly: to get where you’re going you have to know where you’ve been.
Make sure it is efficient and easy to keep the data in your roadmapping tool up to date. If not, it will quickly become obsolete. This means that you will need a tool which you can plug into your other information sources (including at least your ERP and CMDB) so that key business information is automatically available within your roadmapping tool.
In the ABACUS toolset, we do this by providing a completely open API and configurable repository. You can map and then synchronize any external data source into ABACUS. As we like to say, there is no need for the ‘T’ in Extract-Transform-Load (ETL).
Tailoring your metrics
Of course, not everyone wants to go to Hawaii for sun and seafood. Perhaps snow and schnapps in the Swiss Alps is more your style? Similarly, each business has a different destination in mind and a different set of core metrics to guide them there. If what you primarily care about is using high-cost resources efficiently you will need quite a different set of roadmapping priorities to an FMCG company, which is primarily focused on time-to-market.
In ABACUS you can set any number of goals and then use the tool’s powerful analytics to quantitatively assess potential options. This includes out-of-the-box algorithms using equational, structural, discrete-event and Monte-Carlo techniques. You can run these using a range of metrics including Financial (e.g. TCO, ROI, NPV), Technical (e.g. resource utilization, response times, availability, reliability, etc) and Environmental (e.g. carbon footprint, resource re-use, sustainability, heat & power consumption).
Setting the course
We find that a useful way to provide structure to your planning is to work through the questions below:
- What elements should be on the roadmap? Services? Strategies? Standards? Projects? Applications?
- What properties or lifecycle stages are there to display on the roadmap?
- Go live date-end of support date-end of extended support date.
- How fine-grained should the roadmap be? Monthly, quarterly, yearly, decades?
- What is the direction of / are there dependencies between the roadmaps? E.g. Technology Standards influence roadmaps of IT elements which influence roadmaps of Business elements. Or the other way around – starting from a project roadmap going to roadmaps of IT elements?
- What visualizations suit you best? Gantt chart, Milestone chart, Sunset chart, Sankey diagram? Something else?
The four styles of roadmapping
Once you’ve considered all these questions you’ll be in a good position to choose which style of roadmap will work for you. We believe there are 4 basic types of EA roadmaps:
1) “Tagging with recommendation and heatmaps”
This style is the most basic and uses a metric like Retain-Redesign-Refresh-Retire or Tolerate-Invest-Migrate-Eliminate to allow you to color or ‘heatmap’ your business capability maps or technology landscapes to show WHAT is changing. Red-Amber-Green, for example. This type of roadmapping is simply about making a recommendation of what SHOULD happen, but doesn’t address the other questions such as HOW or WHEN.
2) “Lifecycle properties and Gantt charts”
These roadmaps explore in-flight and proposed change initiatives as the HOW and use actual date/time properties for WHEN the changes are going to happen. They require a deeper understanding of Project Portfolio Management (PPM) approaches and the transformational side of the business. However, they are limited when dealing with interdependencies. While they provide a one-degree-of-separation analysis mapping programs and projects to the ‘things’ in the business they directly impact they don’t go any deeper than that.
3) The “ripple-effect” or “dynamic” roadmap
Dynamic roadmaps exploit the ‘hidden’ dependencies or n-degrees of separation structure that you have at your disposal in your ABACUS repository. You are able to understand the cascading effect that a given change might have on every other area of the business. For instance, a project is proposing to upgrade a service which requires an application that is hosted in a data centre being decommissioned by another project! These sort of hidden dependencies can reveal the true knock-on effect of, for example, putting a ‘hold’ on a project that was going to deliver a capability critical for another project.
4) The “multiple architectures” roadmap
As you mature in your roadmapping approach, you will find yourself asking TWO critical questions: is our target state possible in and of itself? … and … is it actually possible to get to our desired target state from where we are today? We call this “feasibility analysis” and “reachability analysis”.
Using ABACUS, you can model multiple states as separate ‘architectures’, comparing planned states with actual states. The planned states can be project architectures or transition architectures and ultimately target architectures. Comparing each scenario to the baseline or current states will help determine its viability. The path/collection of architectures from the current state architecture through the transition architectures to the target architecture IS the roadmap. If one exists it proves feasibility and reachability.
The art of the possible
Every organization does roadmapping. More sophisticated enterprise architecture groups are turning to tools which allow them to keep dynamic, up-to-date views of both IT and business future states, and to present these to other business groups clearly, using rich visuals.
This style of future state modeling and optimization and the certainty it can give to business planning is exactly what we wanted to enable when we designed the ABACUS toolset. We believe it is one of our core capabilities, and one we do better than any other tool on the market.
Download a copy of our more detailed whitepaper “Roadmapping with ABACUS” here, or to ask for a demonstration including examples of successful deployments in your industry please contact us at firstname.lastname@example.org
Or watch our Roadmapping Masterclass for Enterprise Architects webinar below