Disciplined Agile

Enterprise Architecture

Enterprise Architecture Hex

The Agile Enterprise Architecture process blade overviews how a disciplined agile EA team will work. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built. The act of agile enterprise architecture is the collaborative and evolutionary exploration and potential modelling of an organization’s architectural ecosystem in a context-sensitive manner. The implications are that enterprise architects must be willing to work in a collaborative and flexible manner AND other teams must be willing to work closely with enterprise architects.

This article is organized into the following topics:


Why Enterprise Architecture?

Enterprise architecture, when performed in a disciplined agile manner, is an important enabler of agile software delivery. This is true for several reasons:

  1. Common architecture enables agile teams to focus on value creation. A common enterprise architecture enables reuse across delivery teams. When agile teams have high-quality assets – such as micro-services, legacy data sources, and frameworks – available to reuse they are able to focus on creating new value for their stakeholders and not on reinventing new versions of existing infrastructure.
  2. Common technical guidance enables greater consistency. When team follow effective, common conventions it results in greater quality. This makes it easier to learn about assets that are new to them, in particular existing source code, and to evolve those assets as needed. Greater consistency also makes it easier for people to move between teams because it will be easier for them to come up to speed on what the new team is doing and to share their skills with those team members.
  3. Agile architectures enable disaggregation. When your solutions are built from loosely coupled, highly cohesive components it is easier to spread development work across smaller teams. This reduces overall risk and organizational complexity, which in turn reduces time-to-delivery.
  4. Common infrastructure enables continuous delivery. When there is a common technical infrastructure to delivery teams to deploy into it is easier to deploy. The easier it is to deploy, the more often it makes sense to deploy.
  5. Enterprise architecture scales agile. A disciplined agile approach to enterprise architecture enables organizations to scale agile strategies “horizontally” across their entire enterprise.


The EA Process

Some methods will choose to prescribe a single approach, such as capturing architectural requirements in the form of epics or pre-building “architectural runways,” but the Disciplined Agile (DA) tool kit promotes an adaptive, context-sensitive strategy. DA does this via its goal-driven approach that indicates the process decision points you need to consider, a range of techniques or strategies for you to address each decision point, and the advantages and disadvantages of each technique. In this section we present the goal diagram for the Enterprise Architecture process blade and overview its process process decision points.

The following diagram overviews the potential activities associated with Disciplined Agile Enterprise Architecture.

The following diagram overviews the potential activities associated with Disciplined Agile Enterprise Architecture.

Figure 1. The enterprise architecture goal diagram (click to enlarge)

The process decision points that you need to consider for enterprise architecture are:

  1. Support stakeholders. Enterprise architects will work with their stakeholders on a regular basis to understand their needs and to help them develop a vision for the organization.
  2. Support delivery teams. Enterprise architects will work with solution delivery teams, and ideally be active members of solution delivery teams, on a regular basis. They may guide the teams in the business and technical roadmaps, help them to identify potentially reusable assets, to identify technical debt, and transfer their skills and knowledge to team members.
  3. Negotiate technical dependencies. Like it or not, there are dependencies between the solutions that we create. For example, if your system invokes a web service, or calls an API, provided by another system then you have a dependency on that system. Enterprise architects will often find that they need to negotiate these dependencies with other teams, either at a high-level in their role of Enterprise Architect or sometimes at a detailed level in their role of Architecture Owner on a delivery team.
  4. Explore architectural views. Organizations are complex and as a result they must be understood from a variety of view points. It’s not just a matter of writing “architectural epics” on a collection of index cards.
  5. Tailor architectural framework. The enterprise architecture team may choose to adopt, and likely tailor, an existing enterprise architecture framework. These frameworks typically suggest a multi-view collection of artifacts to create and techniques for doing so.
  6. Evolve enterprise architecture. Enterprise architects will collaborate with one another, and with their stakeholders, in a variety of ways. They may choose to hold architecture envisioning/modeling sessions or regular meetings where they share learnings with one another. They will often work together, or with solution delivery teams, to investigate new technologies or identify candidate architecture strategies.
  7. Evolve roadmap(s). An important output of your enterprise architecture effort will be one or more roadmaps describing your business and technology architectural strategies. In agile organizations this roadmapping occurs in a rolling wave approach where the roadmap(s) are updated regularly.
  8. Capture enterprise architecture. There are two broad categories for how enterprise architects can capture their work: as documents or as working/executable examples. High-level models work well for documentation, although sometimes you may find the need for detailed documentation as well. Executable artifacts, such as executable reference architectures or architectural runways, are usually preferred over documentation by delivery teams.
  9. Govern architecture. Architectural activities within your organization should be governed in a lightweight, collaborative manner. This is an important activity for enterprise architects as well as for your governance team.


Workflow With Other Teams

The following diagram overviews the major workflows that your disciplined agile enterprise architecture activities are associated with. Note that feedback is implied in the diagram. For example, where you see the Roadmaps & Models flow from Enterprise Architecture to Asset Management there is an implied feedback loop from the asset engineers to the enterprise architects. Also note that the workflows do not necessarily imply that artifacts exist. For example, some of the models provided by enterprise architects may be communicated via discussions rather than diagrams or documents. 

Enterprise Architecture workflow

Figure 2. Enterprise Architecture Disciplined Agile Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade

Workflow with EA

Asset Management

Enterprise architecture will provide the roadmaps and models to the asset management efforts so that they can better identify potentially valuable assets. The asset management team may have assets that the enterprise architects can use in their work.

Continuous Improvement

The continuous improvement activities will provide potential improvement suggestions for improving enterprise architecture efforts. Similarly, the EA team may have insights to share with the rest of the organization.

Data Management

Enterprise architecture will provide guidance to the data management activities. Operational intelligence pertaining to production data sources and data activities will be made available to the EA team to support their long-term planning efforts.


The Governance efforts will provide guidance to the EA team.

Portfolio Management

Enterprise architecture provides the roadmaps and models to portfolio management. The roadmap is used as input into identifying potential business value and into prioritization decisions.

Product Management

Enterprise architecture will provide the roadmaps and models to product management which is an input into evolving the vision for a product and identifying new potential features for products. Product management provides the business roadmap and stakeholder priorities to enterprise architecture which is used as input into evolve the enterprise architecture.

Program Management

Enterprise architecture will provide guidance to large solution delivery teams (programs) in the form of coaching and mentoring the teams in architectural issues, providing the technology roadmap, and providing development guidelines (such as coding conventions, security conventions, database guidelines, and so on).

The activities associated with these process blades are often very highly related. For example, in some organizations the activities associated with enterprise architecture and reuse management are fulfilled by a single group. In other organizations some product management activities are performed by the portfolio management team and some by the enterprise architecture team. Some organizations may choose to have a separate group for each process blade. And of course the organizational structure will evolve over time as your various teams learn how to work with one another. Every organization is different.


Workflow Within the Team

The workflow within a disciplined agile enterprise architecture team is depicted in the following diagram.

Enterprise Architecture

Figure 3. The workflow within a disciplined agile enterprise architecture team

There are four major activities:

  1. Envision initial architecture. The enterprise architects will spend several days developing initial, high-level models of the enterprise architecture. This will be a face-to-face, initial architecture envisioning session where the scope is the entire organization, not just a single solution or value stream. Ideally this is done in an agile modelling room, also called an Obeya room, so as to streamline the communication and collaborative modelling efforts. Such a room is large with lots of whiteboard space, enabling the team to work on several models in parallel (each of which has its own section of wall space). The primary purpose of this session is for the EA team to develop a common understanding, at least a high level, of the current state of the enterprise architecture and a vision for how the team would like to see it evolve. Secondary outcomes include creating some initial artifacts which the enterprise architects will evolve over time, (potentially) meeting one another for the first time, and building bonds between the team members. Potential challenges to this activity include getting an agile modeling room (you may have to convert an existing room, or accept lower productivity if you can’t get access to such a room) and the logistics of getting the right people together at the same time.
  2. Collaborate with business stakeholders. On a regular basis enterprise architects work with business stakeholders to understand their needs, work with them to envision the future, and help educate them on the possibilities and constraints of technology. This collaboration may be in the form of working sessions, presentations, or one-on-one conversations. These sessions occur as needed and at times it can be difficult to gain access to stakeholders as they are often very busy people.
  3. Collaborate with IT stakeholders. Disciplined agile EAs will spend the majority of their time, 80 to 90% of it typically, working as members of solution delivery teams. By doing this they bring their knowledge, vision, and skills to the team in a pragmatic, hands-on manner. On Disciplined Agile Delivery (DAD) teams they will often take on the role of architecture owner (AO). Enterprise architects will also work with other IT stakeholders, including operations engineers, support staff, the data management team and so on so as to understand their needs.
  4. Evolve architecture assets. The enterprise architecture team, or at least the portion of the team who is currently available, will meet on a regular basis to evolve the enterprise architecture assets based on their learnings. A common pattern we’ve seen it for the team to meet every Friday afternoon for two hours where they discuss what they’ve learned that week from working on delivery teams and working with their various stakeholders. As the result of the meeting several of the enterprise architects may take on action items to update existing EA artifacts. These artifacts may include EA models, reference architectures, development guidelines, white papers, and so on. When a new major topic arises, such as the potential adoption of a new platform or a merger with another organization, the EA may choose to schedule agile modelling sessions to explore the topic.