Developing Roadmaps

Although a roadmap on a one-pager seems to be an easy and straight-forward deliverable, the underlying data points and insights might be complex and have to be thoroughly considered and reflected.

Influencing factors may result out of any phase during an architecture engagement cycle. Depending on the architecture context, a distinct set of influencing factors will be identified as the guiding one.

In case multiple sets of influencing factors are of interest, various scenarios could be simulated to engage with stakeholders to derive an outcome.

There are different ways to represent and visualize a roadmap.

The most commonly used structures are the sunshine diagram as well as the planning chart - as shown in the above image.

There are different types of roadmaps.

Within this unit, we will focus on Business Architecture and Application Architecture Roadmap as the primary roadmap types.

This figure outlines the Roadmap Structuring Elements, including clusters, phases, dependencies, sequences, and elements are the key structuring element of the roadmap.

This figure describes clusters and phases.

The following figure describes elements, sequences, and dependencies.

We will now examine roadmap templates.

The sunshine diagram resonates very well with stakeholders. The following best practices should be applied:

• For the timeline of the roadmap, use fiscal years instead of calendar years (due to budget cycle)
• 3-5 years is the best practice for roadmaps
• Roadmaps should be kept «evergreen» - review on a yearly basis
• Clusters can be structured by
  • Business transformation or IT initiatives
  • Lines of Business
  • E2E Business processes
  • SAP product
  • A mix of the above

Architecture Roadmaps are centered around business needs and priorities which can be structured with the help of an initiative catalog and prioritization matrix by applying the following steps:

1. Determine the set of transformation initiatives
2. Define outcome(s) for each initiative
3. Rate the initiatives in terms of business value and risks
4. Prioritize the initiatives by business value and risks

A value-driven approach for road mapping can be realized with the "Initiative catalog and priorities matrix," which takes future and current initiatives (programs, projects) into account and rates these by the dimensions of "business value" and "project risk". Based on this matrix, "ideal" roadmap candidates can be prioritized over "normal" candidates and initiatives with limited value can be set on a lower priority (or disregarded).

The initiative / outcome / value&risk catalog, in combination with the priorities matrix, provide a good insight into the initiatives and their importance.

In order to be able to create a holistic roadmap including a business and application perspective a "roadmap construction table" has been proven as a handy tool to correlate all required information. This is especially true in case there is no EA modeling tool in use.

The roadmap construction table can also be used to backtrack the rational and dependencies between different EA entities.

The initiative catalog includes both new and current initiatives - a well-defined description is important for a good understanding and to avoid guesswork.

Expansion of the initiative catalog through related outcome(s) turns the initiative into tangible business acumen. Outcomes have been proven as very useful in business architecture roadmaps.

The initiative / value and risk map indicates the value contribution of individual initiative to the company while considering the potential risk at the same time.

As resources are limited, not all new and existing initiatives will be realized. With the help of the business value and project risk matrix, the necessary prioritization of initiatives can take place.

The following figure visualizes an example that provides four exemplary initiatives, including their outcomes and the rating in terms of business value and risk.

The following figure lays out four points that guide our understanding of the evolution towards a Roadmap Construction Table:

• The Initiative / Outcome / Goals Catalog, which provides valuable insights on how initiatives support goals and derive outcomes
• This catalog can further be extended to include additional information from known artifacts such as business capabilities and target application architectures
• In the absence of EA modeling tools, such a "Roadmap Construction Table" has been proven as helpful
• Relationship between different entities get clarified and supported during the creation of a story line "from business strategy to implementation roadmap"

This graph outlines the source of information of the roadmap construction table on the one hand as well as the additional information which can be gathered during the road mapping.

A business architecture roadmap visualizes business outcomes alongside functional clusters and a time horizon of about 3-5 years. The business roadmap complements the application architecture roadmap with a business centric perspective.

The Business Roadmap is an artifact produced as part of the Opportunities and Solutions phase.

As we follow a highly iterative process, initial insights on potential roadmap candidates can be gained during the Business Architecture phase.

The Business Architecture Roadmap uses the following information from the Business Strategy Map:

• Initiatives
• Capabilities
• Outcome
• Time indication

Depending on the stakeholder needs the one over the other entity type can be used (do not mix). Outcome based roadmaps have been proven as very insightful

Depending on the stakeholder needs and concerns, a different set of information can be visualized:

• Initiatives indicate by when certain programs and project take place
• Capabilities indicate by when a certain capability (or higher level of maturity of existing capability) will be available
• Outcomes indicate by when a specific business outcome is expected to be in place

Based on various project experience, outcome-based roadmaps are very well perceived by business stakeholders.

The Application Architecture Roadmap depicts the (technology) solutions required to realize a company's goals. Therefore, a critical element is the identification of the business outcome as defined by the Business Architecture Roadmap.

Road mapping is a planning technique to support strategic and long-range planning, by matching short-term and long-term goals with specific solutions. The Application Architecture Roadmap depicts the solutions required to realize a company's goals within a given time period.

The input for creating the Architecture Roadmap is a mix of all the insights that you have gathered through the creation of the previous work products.

A good start to derive initiatives is the Solution Component Diagram and the Software Distribution Diagram. What needs to be done to implement the building blocks?

Think about pre-requisites that need to be in place before the implementation of solution building blocks can start. Is there any data access required? Is there a specific system integration required, for example?

Check the Statement of Architecture Work: is the roadmap you have defined in sync with the scope of the Statement of Architecture Work?

You might want to create the Architecture Roadmap together with the team or partner implementing your architecture.

A simplified roadmap can limit itself to show only events in time, marking the start or the end of some step. That is often the case in deliveries of shorter SAP services like Value Implementation Strategy, Architecture Point of View, Implementation and Strategy Roadmap and so on.

A complete roadmap will also show durations of initiatives. Durations have to be estimated based on experiences. It can be done by SAP architects, partners, or in a collaborative manner with the customer.

Durations are influenced by the following:

• Complexity of the initiative
• Availability of (system) resources
• Bandwidth of key players
• Dependencies to other initiatives

Generally speaking, there are three major groups of implementation approaches. Each option has it's pros and cons.

With the support of the Scope Dimension Matrix technique, the implementation roadmap for a specific roadmap cluster can be derived in a four-step approach by considering multiple implementation scenarios.

In a first step, the scope of the cluster is determined by selecting the most relevant dimensions (either "WHAT and WHERE" or "WHAT and WHOM").

In a second step, the logical sequencing of the building blocks (WHAT) takes place by considering constraints and relevant requirements.

In a third step, potential options for the parallelization of the implementation are identified while taking known constraints into consideration.

As a last step, the most viable scenario is chosen and reflected on the Application Architecture Roadmap.

The Scope Dimension Matrix is a technique to derive a well-structured implementation approach for an initiative for a roadmap cluster by taking the dimensions of WHAT, WHERE, and WHOM into account.

Depending on the context, the dimension of "WHAT and WHERE" or "WHAT and WHOM" are getting assessed based on the defined scope (number of building blocks - WHAT).

While the WHAT and WHERE are defined straight forward, the WHOM might different from context to context. Multiple roadmap clusters may apply various WHOM dimensions - for example, in procurement the differentiation of the WHOM dimension could be defined as direct and indirect materials while in Asset Management different group of assets would be the denominator.

When the building blocks (WHAT) for a specific initiative are defined, these need to be put into a sequence and a decision has to be taken if a parallel approach might make sense.

In particular instances, a pilot implementation might be considered.

The example provided in the following image details out the "Fast Close" initiative, which consists of 3 building blocks / solutions SAP S/4HANA, Business Planning and Consolidation (BPC) and Shared Service Framework (SSF).

The following is considered::

• From a "WHAT x WHOM" perspective, the implementation across different business units is considered.
• The "WHAT x WHERE" dimension considers regions and a specific country (Brazil - derived from the particular business requirements).
• From a sequencing and parallelization perspective a combination of the dimensions was applied
  • BPC will need to be implemented first
  • Followed by Business Unit specific SAP S/4HANA implementations
  • Brazil will act as a pilot for SSF followed by other regions
  • The roadmap indicates the timing and duration of the defined implementation strategy

The last step is the backward connection to the outcome-based roadmap. With help of the outcome-based roadmap the desired availability times of the outcomes were discussed with the business.

The Outcome-Based Roadmap and Application Roadmap provide the same information but from different points of view. It is of crucial importance to keep the two roadmaps in sync and to allow consistent communication to both the business and IT stakeholders. A consistency check (timelines, dependencies, completeness, etc.) is required between the two roadmaps.

This starting point is used for a backward planning of the required IT initiatives that make the outcome possible.

But it might turn out that a detailed consideration of technical necessities and constraints make it difficult to achieve the desired outcome availability times.

Usually the steps that led to the timing should be reassessed, and when the conflict cannot be resolved the outcome-based roadmap has to be adapted and the change needs to be communicated to the business stakeholders of the outcome.

The purpose of the Transition Architecture is to provide "staging points" that enable a better understanding of the evolution from baseline to target architecture. Sequential Transition Architectures will lead to the target architecture, while the time horizon to be taken into consideration will be defined by the initiative.

• A formal description of one state of the architecture at an architecturally significant point in time.
• One or more Transition Architectures may be used to describe the progression in time from the Baseline to the Target Architecture.

Related to the roadmap, we define also the Transition Architecture.

The creation and maintenance of roadmaps is a crucial activity in the work life of an enterprise architect. Beside the previously discussed entities of business capabilities, solutions, technology etc. the additional dimension of time is added to the overall equation.

As trust with our stakeholders is created through consistent and trustworthy information, we highly recommend to use a sophisticated EA tool for the creation and maintenance of roadmaps. Furthermore, a EA tool helps to increase the efficiency of EAs, enables collaboration, and can be used to simulate specific scenarios while supporting decision making.

• For sophisticated roadmap planning, it is highly recommended to use an EA modeling tool
• A central EA repository ensures consistent roadmaps across multiple entities and well as lifecycle information
• Multiple viewpoints can be provided based on the stakeholder needs
• Collaboration across stakeholder groups can be enabled

A work-breakdown structure in project management and systems engineering is a deliverable-oriented breakdown of a project into smaller components. A work breakdown structure is a key project deliverable that organizes the team's work into manageable sections. Source: Wikipedia

The Work Breakdown Structure is a hierarchy, which breaks down a project into smaller components: it is done in order to better define, organize, and control the total work of a project, in other words, to structure initiatives into manageable sections and deliverables. It serves as a basis to do an effort and cost estimations for the various initiatives. WBS, effort and cost estimations are often done in collaboration by Enterprise Architects and the implementation team (lead) and can mark the start of the handover from the architecture planning phase to the implementation phase.

A work breakdown structure organizes deliverables of an initiative into manageable sections. A work-breakdown structure in project management and systems engineering is a deliverable-oriented breakdown of a project into smaller components.

The following graph provides you with a simple template for the work breakdown structure.

The following graph provides you with an example of a work breakdown structure.