Agile Enterprise Architecture

I have spent the past few months thinking about why I would want to implement a complex and detailed enterprise architecture framework. I’ve always been an agile thinker. How can I rapidly implement a digital transformation using an enterprise architecture framework? Thus, I did some research and thinking. Below are my summarized thoughts. I include references and sources.

Good enterprise architecture takes a lot of work. The process, roles, and responsibilities are well-defined. There is a benefit to following a model that others use. But does the benefit outweigh the cost?

“The fundamental quality of Enterprise Architecture is its vision of the future.”

– Angelo Andreetto in Is Enterprise Architecture Completely Broken?

The TOGAF framework emphasizes vision definition as early as possible. However, fully defining the vision and creating an implementation plan can take a substantial effort. The actual implementation of the vision could be many months into the future. This approach provides little agility for businesses that are driving fast and deep transformations.

“Our architecture was changing faster than you can draw it. As a result, it wasn’t useful to try to draw it.”

– Adrian Cockcroft in Agile Enterprise Architecture Finally Crosses the Chasm

I can’t recommend using an enterprise architecture framework that essentially follows a waterfall approach while development teams are using Agile and DevOps. The two cannot coexist without creating tension. Only one can emerge victorious – or perhaps neither; but the organization may fail in achieving the vision in the end.

In 2010, the IBM Software Group reported on why enterprise architecture (EA) programs were cancelled. I am listing the top ten reasons below. EA failure was deemed to be due to “overpromising and under-delivering” or to “people issues”. These failures are very concerning to me. The success factors / strategies reported that “people issues” was the primary driver of success.

  1. Insufficient time provided
  2. Project teams didn’t take advantage of the EA
  3. Too difficult to measure benefits
  4. Enterprise architects perceived as “ivory tower”
  5. Development teams couldn’t wait for enterprise architects
  6. No perceived benefit of EA program
  7. No executive endorsement
  8. Enterprise architects weren’t sufficiently flexible
  9. Enterprise architects perceived as impediment to success
  10. Insufficient funding

The IBM Software Group report made the following recommendations.

  • You need to understand the business
    • Architecture must be based on requirements, otherwise you are hacking
    • There are two aspects to architecture, business and technical
  • Individuals and interactions
    • Supplying models and documents isn’t sufficient
    • Support project teams
    • Roll up your sleeves and work closely with the teams
    • Architecture comes from teams, not individuals

I found this report to be quite enlightening. The report recommended more communication and interaction. There should be less focus on models and documents with more focus on solutions that work immediately. For example, reduce the technical risk on a project by proving the architecture with code. This is a recommendation that the TOGAF framework does not seem to support. But you must do this in an agile environment. I often tell people that the benefit of a good diagram is that it explains an idea or concept to many different people. They all can have a common understanding and then continue to work. The value of the diagram is not to create it as part of a framework; the value is in the benefit it provides to others.

Furthermore, the goal is not to create many diagrams. This just means more maintenance work over time. Diagrams can be thrown out when they no longer serve their intended purpose. Thus, another goal is to “travel light” as work moves forward. Use a slim model that can be quickly updated or replaced as needed. It seems to me that the report is recommending moving to a much more agile approach to enterprise architecture.

Scott W. Ambler provided the following principles for capturing enterprise architecture in an agile manner:

  • Organizations are complex systems
  • Complex systems cannot be managed at a fine-grained level, but only at a meta level (management by rules)
  • Documentation for complex systems should be coarse (high level)
  • Describe how things work in principle
  • Predictions should be fuzzy and described as ranged probabilities
  • It is more important to strengthen a system’s resiliency than it is to document
  • Accept some disorder and ambiguity
  • Working examples are more valuable than documents

I think that these principles support agile development. This is probably the right time to mention the Manifesto for Agile Software Development.

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

Thus, in my opinion, the enterprise architecture framework must support successful agile software development. It should not be the reverse situation. That is, agile software development must not support successful enterprise architecture implementation. In the latter case, both would fail because they cannot coexist in harmony.

An agile enterprise architecture framework that supports agile software development would benefit an organization. This would allow an organization to rapidly implement digital transformations in response to market pressures.

Next Steps

Marc Lankhorst lists two new enterprise architecture frameworks that provide a more agile approach: Scaled Agile Framework (SAFe) and Disciplined Agile Delivery (DAD). He provides a comparison of TOGAF’s Implementation Governance (Phase G in the ADM) with SAFe. Marc states that “agile methods strongly rely on feedback loops, whereas TOGAF’s governance is rather feed-forward in nature”.

I think that I need to read more of Marc’s blogs and other resources. I want a better understanding of what an agile enterprise architect must do to support the enterprise organization and the agile software development teams. At least, I want validation that my current understanding is on the right path.


Link Title Author Published Agile enterprise architecture Scott W. Ambler May 27, 2016 Is Enterprise Architecture Completely Broken? Jason Bloomberg July 11, 2014 Agile Enterprise Architecture Finally Crosses the Chasm Jason Bloomberg July 23, 2014 Agile Strategies for Enterprise


IBM Software Group 2010 Enterprise Architecture and Agile Development: Opposites Attract? Marc Lankhorst May 28, 2016


I recently earned the Open Group Certified TOGAF 9 Foundation and the ITIL Foundation certifications. Like others before me, I found points of integration between TOGAF and ITIL. However, I found it difficult to define the points of integration.

Here are a few resources that I recommend. Also, I recommend that readers keep in mind that authors often build upon the works of those who came before them.

Link Description Published
White Paper This white paper describes the development of TOGAF (The Open Group Architecture Framework) and ITIL® as a background to discussions about the potential overlap in the

processes they both describe. It does not describe the models themselves.

Sept, 2009
Webinar Traditionally, ITIL and TOGAF professionals have been part of different teams within an organization. Due to the ongoing alignment of business and IT, these professionals now often find themselves on the same team. Because of this crossover, there is a growing trend towards organization of work based on multiple best practice models. Aug, 2013
White Paper This White Paper traces the development of The Open Group Architecture Framework (TOGAF®) and ITIL® as a background to discussions about the potential overlap in the processes they both describe. It does not give an account of the models themselves. Aug, 2013
SlideShare This slide deck attempts to offer some concrete guidance on how Architectural activities and outputs can be integrated into the ITIL framework. The focus is on integrating into ITIL processes. Sept, 2014

Most of the time, I see an image showing the relationship like the one below. You can see the image in the first White Paper that I listed above. It shows a dividing line between ITIL and TOGAF as they cross domains and roles. The image implies that there is no overlap. This is because of the perspective. That is, ITIL was developed to support Service Management and TOGAF was developed to support organizations in the development of Enterprise Architecture. The focus of ITIL is therefore on services, whereas TOGAF is focused on architecture. Thus, the perspectives are different. The definition of perspective is a “point of view”. ITIL and TOGAF view business and information technology from different points of view. Thus, it is difficult to find overlap because of this difference.

I have also seen an image that shows more detail about the domains and implies overlap. This image describes the scope of ITIL and TOGAF. It implies some overlap. I understand that it is high-level; but I still want more details. The first White Paper and the Webinar includes the image below.

The following image provides specific points of overlap or connections. The Webinar includes the image below.

The Webinar seems to focus on a progression from enterprise architecture to solution design. This is one way to look at the relationship – and I do not think it is wrong. However, it seems to imply that there is a separation.

This SlideShare presentation provides a similar analysis as above; but it goes much further. Below is the primary view of TOGAF and ITIL provided by the author. The SlideShare presentation provides specific details where there is overlap between TOGAF and ITIL. This is what I felt was missing in previous analysis. I cannot do justice to explaining the detail provided in the presentation. It is quite extensive and well-thought out. Honestly, I have to keep coming back and reviewing the content to understand it.


There are well-defined points of integration or overlap between TOGAF and ITIL. There was an evolution of thought over this relationship. The SlideShare presentation summarizes this evolution and provides an excellent and detailed explanation of the integration or overlap. Of course, the new problem is when do you use TOGAF or ITIL? Perhaps both at times? Or perhaps it does not matter?

The next topic that I am pondering is agile enterprise architecture.

Using WorkBoard to Manage Objectives and Key Results for Enterprise Architecture

In an earlier blog, I described how a user can use WorkBoard in Microsoft Teams. In this blog, I am writing about how WorkBoard can be used to define the objectives of enterprise architecture and the associated metrics. TOGAF 9.1 states that enterprise architectures must meet the “strategic, interim, and tactical business objectives and aspirations”. Normally, key elements of the Architecture Vision — such as the enterprise mission, vision, strategy, and goals — are documented as part of a wider business strategy or enterprise planning activity.

There are some tools specifically developed for managing the goals and metrics of enterprise architecture. I’m not performing a comparison with those tools in this blog posting.

What are the Objectives of Enterprise Architecture?

One of the challenges of defining the objectives of enterprise architecture is that they seem to end up being the objectives of IT operations. That is not exactly how it is supposed to be.

TOGAF 9.1 identifies the business strategy, business goals, and business drivers of the organization in Phase A: Architecture Vision. These are assumed to be defined outside of the enterprise architecture activity. I found an article titled Enterprise IT Architecture: Goals, Trends and Perspectives published online on The authors provided prospective strategic IT goals (or objectives):

  • Implementing a new business process management methodology
  • Automating and optimizing primary business processes
  • Supporting new products
  • Adapting IT systems to meet new market requirements
  • Estimating required investments in technology modernization
  • Calculating potential financial and efficiency returns from the strategic IT plan

I have a few other enterprise architecture objectives that I want to see included:

  • Improve social collaboration between employees and with outside partners and customers
  • Improve usability of mobile devices with business and web applications for employees and customers

Note: This is not a comprehensive list of goals or objectives by any means. However, I found the article interesting since it also described using the Zachman framework for analysis of an enterprise IT strategy.

Each of these goals (or objectives) could fit into one or more work streams. At least, I am calling them work streams here because that is how they fit into what WorkBoard provides.

  • Operational productivity: improve efficiency to create a quick return on investment
  • Optimization of business processes: include an analysis of the entire process, not just its separate parts
  • Mass customization: Customer involvement results in greater levels of client and market satisfaction

What are the Metrics (or Key Results) for the Objectives?

The metrics should be sufficiently clear so that the vision phase (in TOGAF 9.1) may scope the business outcomes and resource requirements, and define the outline enterprise business information requirements and associated strategies of the enterprise architecture work to be done. For example, these may include:

  • Business requirements
  • Cultural aspirations
  • Organization intents
  • Strategic intent
  • Forecast financial requirements

I used metrics from the following online articles:

12 critical metrics for IT success from

7 Key Enterprise Architecture Metrics from

Obtaining Enterprise Architecture Metrics – Part 1 from (Sadly, this blog post written by Mike Walker is no longer available.)

WorkBoard and OKRs

WorkBoard uses Key Results in place of metrics. The image on the right comes from the Elevate Business Performance with OKRs document published by Workboard Inc.

You can see the flow from Objective to Insight.

However, you don’t see that OKRs (Objectives – Key Results) can be related by using work streams.

My Sample Objective – Key Results (OKRs)

I created a list of OKRs in the table below. These are examples and you should configure OKRs that match your organization’s strategic objectives.

Objective Key Results Rating (examples) Work Stream
Continuous improvement of online services Online application performance. The average time it takes to render a screen or page. Less than 1 second Operational Productivity
Continuous improvement of online services Online application availability. The percentage of time the application is functioning properly. 100% Operational Productivity
Continuous improvement of online services Production incidents. The number of production problems by severity. Zero Operational Productivity
Reducing costs by leveraging common solutions and rationalizing processes, technology, and data. Architectural Integrity. The percent of applications on preferred technologies, another indication of how difficult applications are to maintain 100% Operational Productivity
Improve enterprise architecture delivery Project satisfaction. The average score from post project surveys completed by business partners. 100% Optimization of business processes
Improve enterprise architecture delivery Project delivery. The percentage of projects delivered on time. 100% Optimization of business processes
Improve enterprise architecture delivery Project cost. The percentage of projects delivered within the cost estimate. 100% Optimization of business processes

I also would like to compare the OKRs that I have with other enterprise architects. I suppose that some of the common tools will come with a more complete sample list.

Entering OKRs into WorkBoard

I entered the OKRs into WorkBoard. The three main objectives are displayed below.

I click on the first objective and it expands to display the key results.

I can also open the objective to see the Key Results, Work streams, and Comments.

I click on and I can see all of the work streams. The new workstreams that I created are displayed.

I click on Operational Productivity and the display changes.

I click on the 2 Objectives tab and the two objectives for the Operational Productivity work stream are displayed.

Microsoft Teams

I want to see what information that I can add from WorkBoard to the Enterprise Architecture tab in the Contoso IT channel.

I add Workboard to the Contoso IT team.

I select the Enterprise Architecture channel and click on Set up for the Tab.

I click on the Boards.

I select Operational Productivity. This is the same work stream that I displayed earlier in Workboard. I click Save to continue.

The Operational Productivity board view is displayed – just like I can see it in Workboard.

I can add tabs to display the other work streams, too.

Next I add the Business Review to a new tab in Microsoft Teams. Now I can see exactly what I saw in Workboard. I may not even have to go to the Workboard site.

Next Steps

I need a more robust and complete list of OKRs for enterprise architecture. At least, a better list to start with. Still, I feel like Workboard can be used to manage this information for enterprise architects.


I have added sample OKRs for enterprise architecture. Then I added tabs in Microsoft Teams for a work stream and a business review. I can continue my enterprise architecture work on Workboard from within Microsoft Teams.

It looks like Workboard can be used for managing enterprise architecture OKRs.

Stakeholder Management


Knowing who your stakeholders are and their role within an organization is important during the presales phase of a business opportunity and during project execution. The right stakeholders will help you identify the organization’s business objectives and the project requirements. Each stakeholder has a unique role in their organization with unique expectations. Each can uniquely impact organizational change.

How do you know which stakeholder(s) that you need to communicate with? Which one is the decision-maker? Which one(s) do you need to inform about decisions and project status?

Let’s start from the beginning with some definitions and work our way to an example of a stakeholder map.

Note:    I lean heavily towards using The Open Group Architecture Framework 9.1. I will also make reference to other sources as needed.

Why identify stakeholders?

We identify stakeholders so that we can make note of their concerns, issues, and organizational cultural factors. All three must be noted during presales activities and resolved (or mitigated) during project execution. Any gaps will likely create and/or increase risks during the project execution. A risk is the possibility of an event or condition that would have a negative impact on a project. We might be missing the opportunity to identify and mitigate risks by not properly identifying stakeholders.

In enterprise architecture, we use viewpoints to represent the concerns of stakeholders.

  • A stakeholder is an individual, team, or organization (or classes thereof) with interests in, or concerns relative to, the outcome of the architecture. Different stakeholders with different roles will have different concerns.
  • A concern is an area of interest. So, system reliability might be a concern/area of interest for some stakeholders.
  • A viewpoint is a model (or description) of the information contained in a view. A view is what you see; a viewpoint is where you are looking from — the vantage point or perspective that determines what you see.
  • A view is the representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature.

I won’t get into the details of how to create views and viewpoints for enterprise architecture here. However, we must identify stakeholders so that we can represent their concerns.

Who is a stakeholder?

Consider the business opportunity and/or the project. Now think of anyone who is affected by it or who has influence and/or power over it or has interest in its successful or unsuccessful conclusion. The obvious thing to do is to look at the organizational chart and pick out the applicable executives, line   managers, project managers, partners, suppliers, clients, etc. Also, consider that some stakeholders are represented by one person and others are represented by an organization (or group of persons). However, you should identify a person who can represent a group.

You can find a list of sample stakeholders in the TOGAF 9.1 standard. You can also find a comprehensive list of 105 stakeholders here The site also includes industry-specific stakeholder lists. Of course, I am interested in the ITIL and the IT project stakeholder lists.

How can stakeholders be identified?

Well, we can start with a list and put some contact information beside it. We can ask questions of these stakeholders to identify additional stakeholders (see TOGAF 9.1 standard).

  • Whoever is paying is definitely a stakeholder.
  • Who gains and who loses from this change? (“everyone” is not an acceptable answer)
  • Who controls change management of processes?
  • Who designs new systems?
  • Who will make the decisions?
  • Who procures IT systems and who decides what to buy?
  • Who controls resources?
  • Who has specialist skills the project needs?
  • Who has influence?

How can stakeholders be classified?

I think this is a critical step in the process. This step will provide the reasoning for where we place stakeholders on the power grid.

Thus, we can take the stakeholder list and contact information and place it into a table like the one below. We can place stakeholders in groups. Later we can use these groups for creating viewpoints.

We also categorize the stakeholders in the six remaining columns.

Category Description and Values
Ability to Disrupt Change Some change we create; some change is created by other people and events.

H = can create change in the organization

M = can create change in parts of the organization

L = can create limited change in parts of the organization

Current Understanding What level of understanding does this person have of the project?

H = understands the value and expected outcomes. Can see how it meets the organization’s strategic objectives.

M = has some understanding of the value and expected outcomes. May see how it meets the organization’s strategic objectives; but likely only understands how their own objectives are met.

L = has limited understanding of the value and expected outcomes. May only understand how some of their own objectives are met.

Required Understanding What level of understanding should this person have of the project in order to guarantee a successful outcome?

H = understands the value and expected outcomes. Can see how it meets the organization’s strategic objectives.

M = has some understanding of the value and expected outcomes. May see how it meets the organization’s strategic objectives; but likely only understands how their own objectives are met.

L = has limited understanding of the value and expected outcomes. May only understand how some of their own objectives are met.

Current Commitment What level of commitment does this person have of the project?

H = Committed to the successful outcome of the project

M = Sees this has one of many projects that require some level of commitment. Will try to help the project based on priorities at the time.

L = The successful outcome of this project is a low priority.

Required Commitment What level of commitment should this person have of the project in order to guarantee a successful outcome?

H = Committed to the successful outcome of the project

M = Sees this has one of many projects that require some level of commitment. Will try to help the project based on priorities at the time.

L = The successful outcome of this project is a low priority.

Required Support TOGAF 9.1 uses this column; but I do not what value it brings.

The table below provides an example of stakeholder information that can be used to create a stakeholder power grid. A stakeholder (e.g. John Smith) with a high ability to disrupt change has a high power rating. However, their level of interest should be high if they require a high understanding and / or high commitment. You will have to ask some questions of each stakeholder and rate (H, M, L) their response.

See Step 3 on mindtools blog post for a set of excellent questions to ask. Here are some examples.

  • What financial or emotional interest do they have in the outcome of your work? Is it positive or negative?
  • What motivates them most of all?
Stakeholder Group Stakeholder Ability to Disrupt Change Current Under-standing Required Under-standing Current Commit-ment Required Commit-ment
CIO John Smith




CFO Jeff Brown




You can perform a gap analysis on this table. For example, a gap in understanding exists when a stakeholder (e.g. John Smith) has a M rating for Current; but requires a H rating. Thus, you need to fill that gap! However, the importance of filling that gap can be determined by reviewing their Ability to Disrupt Change. In this example, John Smith has a H rating for Disrupt Change. I would consider it a high priority to fill the understanding gap. In addition, there is a gap between Current Commitment (L) and Required Commitment (M). Thus, it appears as though we do not have the required level of commitment from John Smith. We need to do more communication with John Smith!

Stakeholder power grid matrix

Our challenge is that we many have many stakeholders identified for large opportunities. A power grid matrix is recommended for presenting a high level overview of our stakeholders. The matrix places stakeholders relative to each other using Power and Interest.

My concern with using a power grid matrix is that the values are different than the ones I used in the table above. Thus, I recommend using Ability to Disrupt Change in place of Power. Also, I am not concerned so much about a stakeholder’s Interest as I am about their Required Understanding and Required Commitment. I recommend using these two factors for determining the Required Interest.


Adapted from Mendelow, A.L. (1981). ‘Environmental Scanning – The Impact of the Stakeholder Concept,’ ICIS 1981 Proceedings, 20.

I adapted content from a blog post on mindtools website to show the power grid matrix above with additional explanation.

  Low Required Interest High Required Interest
High Power Keep Satisfied

Put enough work in with these people to keep them satisfied, but not so much that they become bored with your message.

Manage Closely

You must fully engage these people, and make the greatest efforts to satisfy them.

Low Power Monitor

Monitor these people, but don’t bore them with excessive communication.

Keep Informed

Adequately inform these people, and talk to them to ensure that no major issues are arising. People in this category can often be very helpful with the detail of your project.

I put John Smith on the power grid matrix. I placed him in the Manage Closely quadrant. I used the free Interactive Screen App on mindtools website. I renamed the Y-axis to Required Interest. I can add more stakeholders to the matrix.


Now I can see what level of communication is required with stakeholders for a successful outcome. Of course, I still need to define how that communication is executed in a communication plan.

You can see additional examples of stakeholder matrices here

  • Business Process Management Stakeholder Matrix
  • Stakeholder Influence Grid
  • Power and Support Stakeholder Analysis
  • Power and Interest grid
  • Support and Importance stakeholder matrix
  • Influence and Interest stakeholder matrix
  • Attitude and Knowledge stakeholder map

You may want to consider using more than one matrix to represent your stakeholders.

Stakeholder Map

We have collected a lot of information about stakeholders. We need to organize it so that it is useful. TOGAF 9.1 provides an example stakeholder map. The stakeholder map lists:

  • the stakeholders that were identified earlier
  • the key concerns from stakeholder interviews
  • the class from the power grid matrix
  • the artifacts that must be created to represent the stakeholder viewpoints

You can customize the map to suite your purposes, too.

Stakeholder (via identification) Key Concerns (from stakeholder interviews) Class (from power grid matrix) Artifacts to Create for Viewpoints (e.g. Catalogs, Matrices, and Diagrams)



e.g., CEO, CFO,


The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business. KEEP SATISFIED Business Footprint diagram


Service diagram

Organization Decomposition diagram


Management Office



e.g., Project

Portfolio Managers

Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision making. KEEP SATISFIED Requirements catalog

Project Context diagram

Benefits diagram

Business Footprint diagram

Application Communication diagram

Functional Decomposition diagram



In this blog post, we:

  • Explained why we identify stakeholders
  • Defined who a stakeholder is
  • Described how to identify stakeholders
  • Described how to classify stakeholders
  • Created a power grid matrix
  • Created a stakeholder map.

The stakeholder map provides a summary of the stakeholder information that was collected in the previous steps. It provides us with the understanding we need of the stakeholders for a successful outcome of our business opportunity and/or project execution.


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.