RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Making Enterprise Architecture Work in Agile Environments : Page 2

The perceived chasm between enterprise architecture and Agile Software Development can be bridged by leveraging the processes common to both.


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.

Scott Nelson plays the roles of development manager, architect, project manager, and portal evangelist on any given day, and blogs lessons learned at Head in the Web when they are not suitable for Developer.com or DevX.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date