Agile Enterprise Architecture 101

Layered Architecture

This blog posting, the first in a series, overviews fundamental concepts in enterprise architecture.  This posting provides some definitions of common terminology, then proposes a definition for agile enterprise architecture, then discusses why your organization’s approach to enterprise architecture is an important topic.


  • Enterprise architecture (EA).  An organization’s enterprise architecture consists of the various structures and processes of an organization, including both technical structures and processes as well as business/domain structures and processes.  There is always an enterprise architecture, even when it isn’t documented.
  • Enterprise architect.  Someone who is responsible for identifying, communicating, and evolving the enterprise architecture.
  • Architecture owner.  A person on a disciplined agile delivery team who is responsible for facilitating architecture-level decisions, for mentoring and coaching other team members in architectural skills, and for collaborating with the enterprise architecture team (if one exists) in your organization.  See The DAD Role of Architecture Owner for more details.
  • Reference architecture (agile). A working, high-quality example of an architectural component.  For instance, you may have a web services reference architecture which shows how a web service is built and invoked within your organization’s IT ecosystem.  This example will often be used as a template by developers as a basis for their own work.  This example will including supporting documentation that describes how to properly use it.
  • Reference architecture (traditional). A document, or set of documents, describing an architectural component and strategies for using it.
  • Enterprise architecture model (EAM). An EAM is a representation of those structures and processes. A good enterprise architecture model will depict the organization both as it is today and as it is envisioned in the future, and will map the various views representing the architecture to one another. These views include both business-oriented perspectives as well as technical perspectives. In many ways enterprise architecture models are a communication bridge between senior business stakeholders and senior IT professionals.

What is Agile Enterprise Architecture?

We need to answer this question from two points of view:

  1. 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 software development teams must be willing to work closely with enterprise architects.  The latter is a key philosophy built into DAD from the very start, and the former is being introduced in DAD 2.0.
  2. An agile enterprise architecture is flexible, easily extended, and easily evolved collection of structures and processes upon which your organization is built.

Why Is This Important?

The benefits of agile enterprise architecture can be summed up using three words:

  1. Better.  An agile enterprise architecture enables disciplined agile teams to produce better quality solutions for their stakeholders by providing a more reliable ecosystem with which to work.
  2. Faster. An agile enterprise architecture enables disciplined agile teams to delivery solutions to market faster due to improved reuse and infrastructure quality.
  3. Cheaper. An agile enterprise architecture enables disciplined agile teams to deliver solutions to their stakeholders at a lower cost due to improved reuse, greater quality, and greater platform consistency.

It is important to realize that the better, faster, cheaper (BFC) benefits come at a price. First, you must be willing to invest in the underlying organizational and cultural structures to support them. Second, enterprise architects must be willing and able to work in an agile manner. Third, agile teams must be willing and able to work with enterprise architects effectively.

Related Readings


Have any Question or Comment?

9 comments on “Agile Enterprise Architecture 101

Adrianne Kuzmaak

Looking for a good example of an EAM.


Adrianne, great question. Here are a few thoughts:
1. There are several very good books (and web sites) out there about enterprise architecture. These sources will often have examples of partial models.
2. It’s incredibly rare for organizations to share their actual models with others, in particular their ongoing enterprise architecture models. For example, does your organization share such artifacts with others? You see the problem.


Scott, in the 90s IBM (Holland, I think) did an architecture for sale, for Insurance companies, the IAA. It was very ‘meta’ on the data model side, such that it was with data values that a client would model their own architecture. I see it is still avaiable:!/SSCNZQ_7.0.0/

Now related to the Component Business Model. Any advice on how to leverage these models for agile enterprise architecture?


I would consider things like IAA, Accord, and other models to be reference models that I would look at for inspiration. These industry models typically give you one or two logical views, often data models or XML structures, in an effort to promote consistency within the industry. Particularly for tool vendor offerings. And there are other examples in other business sectors as well.

BUT, the vendors rarely seem to implement the standards and when they do it’s their interpretation of a subset. Organizations rarely seem to implement the models because their legacy systems are typically very different than the industry reference models and there is little value in reworking things simply to be able to better share data with your competitors.

David Wright

Not sure about industry consistency with IAA, it wasn’t a specific insurance model, it was a meta-model that an org would use to document their own unique architecture. It also had a related functional decomposition, and both models could be supported by CASE tools to generate applications. Those of us that are old enough will recall how code generation crashed and burned, the betamax of software development. But the IAA model lives on. So can meta-modeling your architecture speed up delivery of applications? My experience was that thinking ‘meta’ was very difficult, so I was considering methods for logically modeling first, then transform it to the meta-model… But then the project was cancelled and I moved to other things.

Duane Banks


I may need to read this entire series, but I’m not clear on how architecture is Agile (or DAD) specific. That seems to imply that an organization’s architecture is a function of their methodology. It seems to me that an architectural approach underlies any of the methodologies that may be utilized at an organization.

I p’m confused by the concept of agile enterprise architecture.


Reading the entire series is likely a good idea.

The point is that you can take an agile approach to EA, a traditional approach to EA, and so on. The focus here is on an agile approach. The mindset article might be a good place to start.


Great article! I found your AEA articles fascinating.
How do you differentiate DAD 2.x AEA from Lean IT? Do they complement each other?


Thurein, thanks.

The strategy that we promote in DA 2.x is definitely in support of a Lean IT strategy. The EA process blade being one of several aspects of such a strategy.


Leave a Reply to David Wright Cancel reply

Your email address will not be published. Required fields are marked *