Architecture Roadmap


According to TOGAF 9.1, the Architecture Roadmap is “an abstracted plan for business or technology change, typically operating across multiple disciplines over multiple years.”

“Abstract” can mean “thought of apart from concrete realities, specific objects, or actual instances”. Thus, the roadmap should have fewer details or specifics. The details and specifics will appear in another document – the Implementation and Migration Plan.

So what content goes into the Architecture Roadmap? I will try to describe the content by phase.

Phases B, C, and D

Each of the architecture development phases (B, C, and D) have a step for defining the candidate roadmap components. The candidate roadmap components are identified during the gap analysis between the Baseline and Target Business Architectures.

In addition, the initial roadmap in each of these phases will be used as raw material to support more detailed definition of a consolidated, cross-discipline roadmap within the Phase E: Opportunities & Solutions.

Phase E

One of the objectives of Phase E is to generate the initial complete version of the Architecture Roadmap, based upon the gap analysis and candidate Architecture Roadmap components from Phases B, C, and D.

“The Architecture Roadmap lists individual work packages that will realize the Target Architecture and lays them out on a timeline to show progression from the Baseline Architecture to the Target Architecture.

Each work package identifies a logical group of changes necessary to realize the Target Architecture.”

The detail of the initial Architecture Roadmap should be at a similar level of detail as the Architecture Definition Document developed in Phases B, C, and D. See my blog post on the Architecture Definition Document. Note that there can be a lot of content for the Architecture Definition Document.

As part of the activities executed in Phase E: Opportunities & Solutions, we should perform a review of “the findings of the Business Transformation Readiness Assessment previously conducted in Phase A and determine their impact on the Architecture Roadmap and the Implementation and Migration Strategy.” Any risks that are found should be documented in the Consolidated Gaps, Solutions, and Dependencies matrix.

The Architecture Roadmap that is completed in Phase E: Opportunities & Solutions should address the Request for Architecture Work.

However, the final Architecture Roadmap does not need to have all of the details displayed that are in the Implementation and Migration Plan. The Implementation and Migration Plan must demonstrate the activity necessary to realize the Architecture Roadmap – not vice versa. The Implementation and Migration Plan forms the basis of the migration planning in Phase F. Essentially, the Architecture Roadmap has the definition; but not the activities. The Architecture Roadmap contains the following content at the end of Phase E:

Work package portfolio:

  • Work package description (name, description, objectives)
  • Functional requirements
  • Dependencies
  • Relationship to opportunity
  • Relationship to Architecture Definition Document and Architecture Requirements Specification
  • Relationship to any capability increments
  • Business value
  • Implementation Factor Assessment and Deduction Matrix
  • Impact

Identification of Transition Architectures, if any, including:

  • Relationship to Architecture Definition Document

Implementation recommendations:

  • Criteria measures of effectiveness
  • Risks and issues
  • Solution Building Blocks (SBBs)

Phase F

The Architecture Roadmap is finalized in Phase F: Migration Planning. The Roadmap is integrated with the enterprise’s other change activity in Phase F. These activities include assessing the dependencies, costs, and benefits of the various migration projects.

Other Sources

At this point, I realize that I do not have a clear picture of what the roadmap is. I basically think of a roadmap as a visual representation of a timeline. I’m not seeing that explanation in TOGAF. So I looked for other examples.

I read a blog posting titled How to build a Roadmap. The author described a method to create a roadmap based on the SEI-CM IDEAL model. He described a six step pattern that all roadmaps must follow.

  1. Develop a clear and unambiguous understanding of the current state
  2. Define desired end state
  3. Conduct Gap Analysis
  4. Prioritize
  5. Discover the Optimum Sequence
  6. Develop and Publish the Road Map

The author included the image below which I found to be very helpful in describing the pattern!

pattern

He also includes a sample roadmap image. I found this article to be very helpful in putting a program into practice.

The same author published another blog on the same topic. This blog posting provides three good explanations as to how the roadmap will be used:

  1. a vehicle for communicating the program’s overall intent to interested stakeholders at each stage of its planned execution
  2. a basis for performing up-front analysis to validate (or uncover deficiencies in) in design decisions and refining or altering those decisions where necessary
  3. achieve program and systems understanding

I recommend reading these blog postings!

Webinar

You can watch a YouTube video titled Roadmapping Masterclass for Enterprise Architects 2017 OPEN GROUP WEBINAR (2017) https://www.youtube.com/watch?v=prBtW_4GzZM This webinar walks through how to leverage standards including TOGAF® and ArchiMate®, both Open Group standards, and existing data from SharePoint, Excel, Google Sheets and other sources to build compelling roadmaps.

The webinar provides a good explanation, recommendations, and best practices for roadmaps. I’m fine with the discussion and promotion of using the ArchiMate tool. I’ve worked for software vendors, too.

One of many good points that were made in the webinar is: “Having the what, when and how is great, but success depends on communicating the why. Don’t assume the benefits are obvious.”

The image below showed that the roadmap not only moves us from the baseline architecture to the target architecture; but also achieves the organization’s objectives.

roadmap

TOGAF Architecture Roadmap template document

You can download a TOGAF Architecture Roadmap template document from here. The Table of Contents appears as below:

TOC5

In summary, the explanation of the Architecture Roadmap in the TOGAF documentation is very dry and abstract. The content in the blog postings that I linked to and the webinar provide a more practical explanation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s