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.
Ready to upgrade your roadmaps? Contact our team today.
Schedule a Demo
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 understanding 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.
Avoiding obsolescence
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), and automatically run any algorithms, so that key business information is readily available within your roadmapping tool.
In the ABACUS toolset, we do this by providing an open API, configurable repository, and select adapters and integrations. You can map and then synchronize any external data source into ABACUS.
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 likely 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 no-code algorithms. 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 Sustainability (e.g. carbon footprint, resource re-use).
Setting the course: Roadmap Design
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?
- Plan-Build-Run
- Retain-Refresh-Redesign-Retire
- Tolerate-Invest-Migrate-Eliminate
- Go live date, end of support date, end of extended support date.
- How fine-grained should the roadmap be? Monthly, quarterly, yearly?
- 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 communicate your plans and analysis best? Gantt chart, Milestone chart, Heatmap, Capability Map, Graph View? 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) Using Capability Maps & Heatmaps to Communicate Change
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 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) Manage Dependencies with Dynamic Roadmaps
Impact and dependency analysis can often mean the difference between success or failure of a project. You need 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 sorts of dependencies can catch businesses out if they aren’t anticipated. With the help of tools like ABACUS Graph View (below), teams can understand and manage the cascading effects
of changes in different areas of the business.
4) Using “multiple architectures” to roadmap scenarios
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 scenarios as separate ‘architectures’, comparing planned states with current states. The planned states can be project architectures or transition architectures and ultimately target architectures. Comparing each scenario to the baseline or current state will help determine their viability. The path/collection of architectures from the current state architecture through the transition architectures to the target architecture IS the roadmap.
By using these multiple architectures, your team can streamline and thoroughly check the process of turning roadmaps into projects, with a clear plan at each step.
The art of the possible
Every organization does roadmapping. More sophisticated enterprise architecture teams 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 business colleagues, 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.