A recurrent topic in meeting rooms and discussion groups is “Can enterprise architecture work in an Agile Software Development environment?” The question is so often asked that even those architects and developers who have already found the answer through personal experience stop to think about it. They wonder if perhaps they have missed something and need to re-evaluate their conclusions.

They likely haven’t missed anything, but the fact that they even question their experiences is a testimony to the perceived chasm between the enterprise architecture (EA) and Agile disciplines. In fact, EA and Agile have great potential to work together to the benefit of architects, Agile developers and entire development organizations. This article helps define that potential.

Enterprise Architecture and Agile Development Viewpoints

Viewpoint is a key influence on perception. Many factors shape a viewpoint (which is a topic worthy of study in itself), but for the purpose of this discussion consider two broad viewpoints at the core of an individual’s (or organization’s) beliefs regarding EA and Agile:

• The two disciplines are fundamentally similar.
• The two disciplines are fundamentally different.

Let’s take a close look at these in order.

EA and Agile Are Fundamentally the Same

EA and Agile share the following process:

1. Review the current state of the solution landscape
2. Elicit the desired state from business
3. Determine the technical and non-technical gaps between the current and target states
4. Take steps to narrow the gap by implementing one or more solutions towards the target
5. Review the results of the implementation to choose the next step and revise (if necessary) the approach towards the target state

For those who believe that enterprise architecture and Agile Development are fundamentally different, the list above most likely presents a new viewpoint. Practitioners of either discipline agree that discovering a new viewpoint should trigger a re-evaluation of existing views. The new viewpoint also suggests that the accepted principles should be confirmed or expanded as necessary.

EA and Agile Are Fundamentally Different

Just as the two disciplines clearly share a fundamental process, they also have fundamental differences that often fall into the categories of discipline or compatibility. Again, using broad strokes, the discipline differences are in meeting formats and deliverables.

Starting with the differences of how the disciplines approach meetings, the format of most EA meetings is very detailed and structured as pre-defined goals are part of the EA framework. Conversely, most Agile meetings have a very high-level structure with a high-level goal of agreement and mutual understanding. EA meetings tend to last hours and even days, whereas Agile meetings are completed in minutes. Developers rarely attend EA meetings and EAs rarely attend Agile meetings.

Deliverables are also different. The deliverables from enterprise architects are documents and other non-functional artifacts that describe the enterprise architecture. Agile developers deliver code and documentation that describes anything that is either not explicit in the code or is necessary for those who are not developers to interact with the application.

The common misconception that enterprise architecture produces excessive documentation or that Agile developers deliver no documentation is generally based on a one-sided viewpoint looking for differences. In fact, many who believe the two disciplines are incompatible point to documentation as proof. While both enterprise architects and Agile developers deliver documentation at a fine-grained level, the EA and Agile documentation are very different because they are intended for different audiences and contexts. That said, the documentation delivered by both disciplines share a common principle at a high level: produce only as much documentation as is necessary to achieve the goal. Of course the level of documentation can vary from enterprise to enterprise, as some modify their standard framework to include documentation that is not explicitly necessary to the goal. Still, all commonly recognized EA and Agile frameworks recommend reducing documentation to only what is needed for the given solution.

Another difference frequently cited as a conflict between EA and Agile is enterprise architecture is inflexible and delivered as a whole whereas Agile development is nimble and delivered incrementally and iteratively. From the viewpoint of someone who has worked only in development this looks quite valid. On the other hand, development begins after the enterprise architecture team has gone through multiple stages and iterations to provide the best direction possible prior to the delivery of the software. The deliverable from enterprise architecture at that point will include a set of principles that enable the development team to focus on development.

The EA lifecycle also includes processes for the development team to communicate the need for exceptions or corrections to these principles, and a way to determine whether it is an exception or a correction. Where Agile dictates that working code should be changed only when it can be obviously improved or is no longer necessary, EA frameworks advocate governing the architecture to maximize re-use and reduce redundancy. Oh, wait! Those are really the same things but from two different points of view.

Bridging the Gap Through Multiple Viewpoints

One key process shared by both disciplines is re-evaluating earlier conclusions each time new variables are generated or discovered. Conflicts between enterprise architects and Agile developers reduce the effectiveness of both disciplines in many enterprises. It is understandable how people who are really skilled in either discipline may view the other as a roadblock to their success, because becoming really skilled takes a lot of focus on the chosen role. Still, it is also quite obvious why people once thought the Earth was flat and the Sun revolved around it. At that time a limited number of viewpoints were being utilized, leading intelligent people to invalid conclusions. Embracing other viewpoints increases understanding and expands potential.