Project Management

Disciplined Agile Enterprise Architecture: A Goal-Driven Approach

From the Disciplined Agile Blog
by , , , , , , , , ,
This blog contains details about various aspects of PMI's Disciplined Agile (DA) tool kit, including new and upcoming topics.

About this Blog


View Posts By:

Scott Ambler
Glen Little
Mark Lines
Daniel Gagnon
Valentin Mocanu
Joshua Barnes
Michael Richardson
Klaus Boedker
Kashmir Birk
Mike Griffiths

Recent Posts

The Disciplined Agile Enterprise (DAE) Layer

Disciplined Agile (DA)'s Value Streams Layer

The Disciplined DevOps Layer

Would you like to get involved with the 20th Anniversary of Agile?

The Four Layers of the Disciplined Agile Tool Kit

This posting, the latest in a series focused on a disciplined agile approach to enterprise architecture (EA), overviews the activities that a disciplined agile EA team may perform. 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) toolkit promotes an adaptive, context-sensitive strategy.  DAD does this via its goal-driven approach that indicates the process factors you need to consider, a range of techniques or strategies for you to address each process factor, and the advantages and disadvantages of each technique.  In this blog we present the goal diagram for the Enterprise Architecture process blade and overview its process factors.

The following diagram overviews the potential activities associated with disciplined agile enterprise architecture.

Disciplined Agile Enterprise Architecture

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

  1. Support stakeholders. Enterprise architects will work with business and IT 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 IT delivery teams, and ideally be active members of IT 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. 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.
  5. 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.
  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 IT 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 technology strategies and/or your 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 IT governance team.

Our next blog posting will describe the workflow of enterprise architecture with other key IT activities such as portfolio management, reuse management, and IT delivery teams.

Related Readings

Posted by Scott Ambler on: June 03, 2015 01:24 PM | Permalink

Comments (0)

Please login or join to subscribe to this item

Please Login/Register to leave a comment.


"You can't build a reputation on what you are going to do."

- Henry Ford



Vendor Events

See all Vendor Events