Planning and Roadmapping : Introduction
Sep 25, 2018
A key driver for management in general and enterprise architecture in particular is to get a better grip on the future, on the evolution of your enterprise. A common technique to support this is roadmapping. A roadmap is a strategic plan that shows the main steps or milestones needed to achieve a desired outcome. It articulates the strategic direction of your enterprise and shows the path forward. It helps you identify what is needed and what the main dependencies and priorities are, and serves as a communication instrument to align the organization along a common course of action.
It is important to realize that the further into the future we plan, the less concrete our plans can and must necessarily be. On the one hand we can only explore and develop the requisite knowledge on-the-fly, for example because our users can only give us their requirements in an ‘I know it when I see it’ manner. On the other hand the world keeps changing around us, so we will have to adjust our plans anyway, making it almost impossible and therefore a fruitless exercise to define detailed plans far into the future. A roadmap is certainly not a communist five-year plan, but a flexible instrument to give direction to your enterprise and identify key dependencies. The big picture and the more distant parts of your roadmap will therefore be painted using a broader brush.
One important use case for roadmaps is capability-based planning. The evolution of capabilities in terms of so-called ‘increments’ is something you can perfectly express with a roadmap. The figure below shows a simple roadmap where the Customer management capability is gradually improved by a number of projects to homogenize the information and data on customers across business units, improving global access to that data, and harmonizing billing processes across different business units.
These projects will be detailed out in smaller pieces of work, and the capability increments themselves will require specific improvements to various aspects of the architecture. These may be developed by specific work packages within these projects and expressed as appropriate deliverables.
Roadmaps can be defined in various ways and at multiple levels. In the context of agile software development, for example in the Scaled Agile Framework, you will often see multiple levels and time scales, such as:
All of these we consider part of ‘roadmapping’ as a general technique.
The evolution of your capabilities may be expressed in features and stories and put on the backlog of some sprint, to be developed by the various agile teams employed. Several sprints from multiple agile teams together result in a release that provides a capability increment, and a series of releases in turn may together result in a specific business outcome.
When creating a multi-level roadmap, you will define the detailed contents of sprints only in the short term, with specific user stories to be implemented and concrete changes to processes and systems. Releases will be planned perhaps a few months into the future, but the features for each release will be specified in a higher-level, more coarse-grained manner and be detailed out only for the nearest release. Roadmap stages at a higher level and longer time scale will be even more abstract, e.g. identifying capability improvements, as in the example above, or even just giving direction in the form of long-term goals and desired outcomes.
Two key ArchiMate concepts for modeling roadmaps are Work Package and Plateau. Work Packages are used to model the work to be done at the different levels involved, from individual sprints to entire roadmaps. The resulting evolution of the architecture is captured in Plateaus, which aggregate the architecture elements valid during a certain time span.
The example below shows some of this. On the left we see the development of concrete processes, systems and data organized in sprints modeled with ArchiMate’s Plateau and Work Package concepts. Multiple teams may be at work during the same sprint period, hence the replication of the Work Packages. On the right we see more abstract capability increments organized in releases that are themselves the result of a series of sprints. In the underlying model (but not shown in the figure), all the elements created or changed in the two sprints contribute to the first capability increment. (Note that unlike the previous figure, this one does not depict a timeline from left to right).
As mentioned above, the further you look ahead the less concrete your roadmap will be. Hence the concepts used for the near future are typically the concrete and detailed business, application and technology layer elements. For the medium-term future, you might use the more abstract capabilities and resources, and the longer term you would perhaps express using goals and outcomes only. In the next installment in this series, we will explore in more detail how you can model your roadmaps using ArchiMate concepts for different time frames and levels of detail.
Finally, in a third installment in this series, we will go into more detail on advanced functionality of Enterprise Studio for working with roadmaps and lifecycles, for example to show time lines, analyze dependencies between the lifecycles of parts of your enterprise, or detect conflicts between planned changes. Stay tuned!
ALSO CHECK: Organizing Architecture Governance With Workflow And Forms
