Are the rapid Agile development approaches compatible with the longer term strategic planning approach of Enterprise Architecture?
Maybe ‘agile’ is just a very overloaded word and we should instead talk about Iterative and Incremental Enterprise Architecture? 
One of the main concerns I have always had is that the concept of ‘Agile’ is closely associated with ‘Quick and Dirty’ in the minds of many clients who are happy to trade off quality for rapid development. The concept of Agile and of Enterprise Architecture do seem at first glance to be incompatible – you wouldn’t really want to develop a quick and dirty enterprise architecture especially where the impact is strategic, long term and very costly. It doesn’t matter if you have to refactor a solution a few times to get it right for the current set of user stories, but refactoring the whole organisation is less feasible. 
I am fully behind the idea of an iterative and incremental approach to both developing an Enterprise Architecture (as described in TOGAF9 and FSAM) as well as for solution development (with RUP, FDD, Perspective, DSDM etc), but don’t want to encourage low quality outcomes that can result with pure agile approaches like XP. 
I always found the original XP process to be rather anti-Analysis and anti-Architecture but I believe that both Analysis and Architecture are very necessary in the appropriate context and scale. 
For developing a Solution I often used to advocate having two parallel processes that might be called Agile Analysis and Agile Development with the Agile Analysis process feeding requirements/user stories into the Agile Development process.

Are the rapid Agile development approaches compatible with the longer term strategic planning approach of Enterprise Architecture?

Maybe ‘agile’ is just a very overloaded word and we should instead talk about Iterative and Incremental Enterprise Architecture? 

One of the main concerns I have always had is that the concept of ‘Agile’ is closely associated with ‘Quick and Dirty’ in the minds of many clients who are happy to trade off quality for rapid development. The concept of Agile and of Enterprise Architecture do seem at first glance to be incompatible – you wouldn’t really want to develop a quick and dirty enterprise architecture especially where the impact is strategic, long term and very costly. It doesn’t matter if you have to refactor a solution a few times to get it right for the current set of user stories, but refactoring the whole organisation is less feasible. 

I am fully behind the idea of an iterative and incremental approach to both developing an Enterprise Architecture (as described in TOGAF9 and FSAM) as well as for solution development (with RUP, FDD, Perspective, DSDM etc), but don’t want to encourage low quality outcomes that can result with pure agile approaches like XP.  

I always found the original XP process to be rather anti-Analysis and anti-Architecture but I believe that both Analysis and Architecture are very necessary in the appropriate context and scale. 

For developing a Solution I often used to advocate having two parallel processes that might be called Agile Analysis and Agile Development with the Agile Analysis process feeding requirements/user stories into the Agile Development process.

I’ve started this as a discussion on the LinkedIn group on Agile Enterprise Architecture.

3 Responses to “Can Enterprise Architecture be Agile?”


  1. Indeed, these 2 perspectives are not always perceived to work well together. The quick approach of Agile versus the well-planned and well-thought out architecture process. I would agree that incremental architecture is probably a better way of calling this new process.


  2. Enterprise architecture and application development differ by their rate of strokes and by the number of dependencies that need to be considered in these two realms.

    In the environment I am working in as a consultant, enterprise architecture produces blueprints and guidelines which are then implemented by individual projects. When following this model, working software cannot (by definition) be the measure of progress for enterprise architecture.

    Instead, progress is measured by asking different questions: Did our architecture reduce time to market and cost? Did it enable business to deliver new products and services?

    The key mechanism behind iterative development is the feedback loop that is built into this model. Whereas application development benefits from feedback loops that last a few weeks, the feedback loops we see in enterprise architecture are about six months long. This difference may demarcate the transition from an agile model to a (mere but nevertheless highly valuable) iterative approach.


  3. [...] this is a sign of adolescence for EA. Its existence is apparent, and now EA needs to decide who it should hang out with and what it wants to be when it grows up. As part of a wider discussion, Richard Veryard has posted [...]


Leave a Reply