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!


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!


You can watch a YouTube video titled Roadmapping Masterclass for Enterprise Architects 2017 OPEN GROUP WEBINAR (2017) 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.


TOGAF Architecture Roadmap template document

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


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.

Architecture Requirements Specification

I am continuing my review (and understanding) of the TOGAF 9.1 framework. I recently posted a blog about the Architecture Definition Document. The Architecture Requirements Specification is related to the Architecture Definition Document; but it provides a quantitative view of the solution.

What does quantitative mean? Quantitative has to do with quantity and is measured in numbers.

According to the TOGAF specification, the Architecture Requirements Specification “provides a set of quantitative statements that outline what an implementation project must do in order to comply with the architecture. An Architecture Requirements Specification will typically form a major component of an implementation contract or contract for more detailed Architecture Definition.”

The Architecture Requirements Specification is first created in Phase A: Architecture Vision. Section 36.2.6 of the TOGAF specification states that the Architecture Requirements Specification can contain the following contents:

  • Success measures
  • Architecture requirements
  • Business service contracts
  • Application service contracts
  • Implementation guidelines
  • Implementation specifications
  • Implementation standards
  • Interoperability requirements
  • IT Service Management requirements
  • Constraints
  • Assumptions

I quickly realize that the TOGAF specification does not define what an architecture requirement is. I need some clarification. I understand the difference between qualitative and quantitative; but I do not want to recreate the Architecture Definition Document here with quantitative details. So I will start with defining the term “architectural requirement”. The good news is that there is great blog posting titled Capturing Architectural Requirements here The author defines an architectural requirement as “any requirement that is architecturally significant, whether this significance be implicit or explicit”. He also quotes from the Rational Unified Process® (RUP®) that:

“A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document.”

He notes that the FURPS+ system provides a systematic approach for classifying requirements.

  • Functionality
  • Usability
  • Reliability
  • Performance
  • Supportability

I agree with the author that classifying the requirements will help us to differentiate and understand them better.

The author then provides a five-step approach to gathering the architectural requirements:

  1. Maintain a complete list of architectural requirements (regardless of whether all items are relevant to a particular project). See Appendix B: Architectural Requirements for a sample list.
  2. For each architectural requirement, formulate one or more questions that can help in the specification process. Make sure all the system’s stakeholders can understand these questions.
  3. Assist stakeholders by showing them the potential impact of answering a question one way or the other.
  4. Capture the responses from your stakeholders to each of the questions.
  5. Assist the architect by ensuring that the stakeholders — in addition to answering these questions — assign a priority or weighting to each architectural requirement. This weighting will allow the architect to make tradeoffs between requirements.

Note: You should click on the Appendix B link to view the summary of architectural requirements to consider. They are grouped together using the FURPS+ system.

I also recommend that you view the Sample Architectural Requirements Questionnaire and a summary of the architectural analysis mechanisms. The Questionnaire is how you should organize your requirements questions (and add columns for answer and priority).

This should help me focus on gathering only architectural requirements. Otherwise, I could end up gathering all kinds of requirements.

Another resource for defining an architecture requirement is found here The author states the same concern that I have about TOGAF. That is, there is really no clear definition provided. The author provides the following characteristics of an architecture requirement:

Characteristic Question to Ask
It should describe a necessary change to components in an architecture. This might mean adding new components, removing outdated ones, replacing or improving components, or changing the way in which they are organized and how they work together. What is going to change?
It should include the reasoning or motivations behind the change. Why does it need to change?
It should explain why the existing components are inadequate, limiting or constraining. What problems, issues or concerns are caused by the current architecture?
It should outline the available options for future architectures that address all concerns. How do alternate target architectures eliminate the problems of the current architecture?
It should explain the benefits, value, risks, costs, opportunities, constraints, and future options associated with each alternative. How do we decide between one alternative and another?
It should outline any alternative routes to close the gaps and get from the current to the target architecture. How do we make the transition or transformation from what we’ve got now to what we need in the future?


I think that these are good open-ended questions to ask. It does help with keeping you within a scope. But I would like to start with a structure provided by the FURPS+ system.

The Architecture Requirements Specification is finalized in Phase F: Migration Planning.

You can download a copy of an Architecture Requirements Specification here:

The table of contents is very simple:


There are no examples or detailed descriptions in the document. It’s really not that helpful to get started.

I found another document titled Software Architecture Document that might be helpful here:

It has a lengthy table of contents. Here is part of it:


This document provides examples and detailed descriptions.

To be perfectly honest, I am wondering if anyone creates the Architecture Requirements Specification. Perhaps they prefer a much more agile solution? Or they say that Agile does not support providing this Specification in advance?

I will keep searching for good examples of this document and its use.

Architecture Definition Document

Recently, I have reviewed the TOGAF 9.1 framework. One topic (of many) that interests me is what content is required / recommended in the Architecture Definition Document and the Architecture Requirements Specification. I find that the details are spread out in the TOGAF 9.1 documentation. I will start with the Architecture Definition Document in this blog posting.

According to the TOGAF specification, the Architecture Definition Document is “the deliverable container for the core architectural artifacts created during a project and for important related information”.

Furthermore, the Architecture Definition Document is

“a companion to the Architecture Requirements Specification, with a complementary objective:

  • The Architecture Definition Document provides a qualitative view of the solution and aims to communicate the intent of the architects.
  • The Architecture Requirements Specification provides a quantitative view of the solution, stating measurable criteria that must be met during the implementation of the architecture.”

Let me state this again …

  • Architecture Definition Document provides a qualitative view
  • Architecture Requirements Specification provides a quantitative view

The Architecture Definition Document is first created in Phase A: Architecture Vision. Section 36.2.3 of the TOGAF specification states that the Architecture Definition Document can contain the following contents:

  • Scope
  • Goals, objectives, and constraints
  • Architecture principles
  • Baseline Architecture
  • Architecture models (for each state to be modeled):
    • Business Architecture models
    • Data Architecture models
    • Application Architecture models
    • Technology Architecture models
  • Rationale and justification for architectural approach
  • Mapping to Architecture Repository:
    • Mapping to Architecture Landscape
    • Mapping to reference models
    • Mapping to standards
    • Re-use assessment
  • Gap analysis
  • Impact assessment
  • Transition Architecture:
    • Definition of transition states
    • Business Architecture for each transition state
    • Data Architecture for each transition state
    • Application Architecture for each transition state
    • Technology Architecture for each transition state

The above list should be your starting Table of Contents for your Architecture Definition Document. You will need to add content to those sections in order to finalize the document.

The Architecture Definition Document should also contain sub-sections for:

  • Baseline Business Architecture
  • Baseline Technology Architecture
  • Baseline Data Architecture
  • Baseline Application Architecture
  • Target Business Architecture
  • Target Technology Architecture
  • Target Data Architecture
  • Target Application Architecture

That is, you could be these under each state of the architecture model.

Phases B, C, and D add documentation to the applicable sections in the Architecture Definition Document. The documentation is the output of the steps in each phase. For example the steps in Phase B: Business Architecture are:

  • Select reference models, viewpoints, and tools
  • Develop Baseline Business Architecture Description
  • Develop Target Business Architecture Description
  • Perform gap analysis
  • Define candidate roadmap components
  • Resolve impacts across the Architecture Landscape
  • Conduct formal stakeholder review
  • Finalize the Business Architecture
  • Create Architecture Definition Document

As I indicated earlier, similar steps are noted for Phase C: Information Systems Architecture and Phase D: Technology Architecture.

This is where it gets confusing (at least for me). Documentation is created from each of these steps in the phases. Most of the documentation is added to the Architecture Definition Document. Some of the steps create documentation that is added to the Architecture Requirements Specification.

The last step is Create Architecture Definition Document. The following sub-steps are performed:

  • Document rationale for building block decisions in the Architecture Definition Document
  • Prepare the business sections of the Architecture Definition Document, comprising some or all of:
    • A business footprint (a high-level description of the people and locations involved with key business functions)
    • A detailed description of business functions and their information needs
    • A management footprint (showing span of control and accountability)
    • Standards, rules, and guidelines showing working practices, legislation, financial measures, etc.
    • A skills matrix and set of job descriptions
  • If appropriate, use reports and/or graphics generated by modeling tools to demonstrate key views of the architecture. Route the document for review by relevant stakeholders, and incorporate feedback.

Basically, these sub-steps are adding more documentation to the Architecture Definition Document. The last sub-step requires a review. Thus, it is not enough to add documentation.

But don’t forget to add all of the documentation from the previous steps within the phase! The following documentation is added to the Architecture Definition Document from the steps in Phase B: Business Architecture:

  • Baseline Business Architecture, if appropriate
  • Target Business Architecture, including:
    • Organization structure — identifying business locations and relating them to organizational units
    • Business goals and objectives — for the enterprise and each organizational unit
    • Business functions — a detailed, recursive step involving successive decomposition of major functional areas into sub-functions
    • Business services — the services that the enterprise and each enterprise unit provides to its customers, both internally and externally
    • Business processes, including measures and deliverables
    • Business roles, including development and modification of skills requirements
    • Business data model
    • Correlation of organization and functions — relate business functions to organizational units in the form of a matrix report
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns

Thus, there is a considerable amount of documentation that is added to the Architecture Definition Document in this phase! This is what I found a little bit confusing. You must look through all of the steps to determine the documentation to add to the Architecture Definition Document and the Architecture Requirements Specification.

The steps, sub-steps, and documentation are repeated in each of the next phases:

  • Phase C: Information Systems Architectures – Data Architecture
  • Phase C: Information Systems Architectures – Application Architecture
  • Phase D: Technology Architecture

I could list all of the required documentation for each of steps in each of these phases here; but it becomes too lengthy (and you can read it for yourself in the TOGAF specification).

Now we enter Phase E: Opportunities & Solutions. This is where we finalize all of the documentation that is in the Architecture Definition Document. The following additional sections (with content) may be added:

  • Transition Architecture, number and scope as necessary
  • Views corresponding to the selected viewpoints addressing key stakeholder concerns

Now the Architecture Definition Document should be reviewed (again) by the applicable stakeholders and considered final.

Are you done? No, of course not!

You should have reviewed your Architecture Vision. Confirm that the Architecture Definition Document is describing the same outcome as the Architecture Vision. If not, you have a problem! The Architecture Vision was communicated to your stakeholders at the very beginning. You may have even provided a summary version of the draft Architecture Definition Document.

You should also be tracking the reviews and versions of the Architecture Definition Document throughout the ADM process.

Final edits to the Architecture Definition Document are completed in Phase F: Migration Planning. You may need to add a Transition Architecture State Evolution Table. Also, you may need to update details on the implementation if there were changes to the implementation approach because of the Transition Architecture. Now you are done – assuming the document is reviewed and approved.

You can download a copy of an Architecture Definition Document here:

I like this template because each section has a purpose, description, and quality criteria. There are even some content examples. Here is a screenshot of the Table of Contents:


You can also download templates from TOGAF here

The Architecture Definition template has the following Table of Contents:


I prefer the first template. I would add sections from the TOGAF template and update the Table of Contents. I may still need to add sections for Transition Architectures and Views.

In conclusion, I have a better understanding of the Architecture Definition Document. I also have a sample template that I can use.