Can Enterprise Architecture be Agile?

8 May 2009

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.

About these ads

6 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 [...]

  4. Tim Huffam Says:

    Great topic to raise.

    I agree with Wolf.

    I’d also point out that Agile need not result in reduced quality (if that’s the result you’re getting then I’d question your development team).

    I see EA more as strategy and the implementation of it at a high level – whereas Agile purely as one means of implementing it at a high level – and, as Wolf mentions, using the feedback loop to make sure it meets requirements. This part is key – as, from my experience, the requirements are merely initial assumptions of what the business wants… it’s not until they see something implemented that they can truely realise/understand what it is they want to achieve and *what is the most effective way to implement this*.

    So with EA being macro implementation and Agile working at the micro implementation level – Agile allows fine tuning of the EA strategy – on the fly.

    As I read somewhere – “the reason many IT projects fail is because they deliver exactly what the customer/business asked for”.

    Regards
    Tim Huffam

  5. Shayne Edmondson Says:

    Agree with the views of Wolf and Tim, Enterprise architecture should ideally be performed ahead of projects and articulated as a strategy/‘blueprints’. The architecture can then be fine tunned (and governed) thought the implementation phase.
    This fundamental difference between architecture and project delivery is often overlooked forcing many architects to ‘architect through projects’; it is this approach to architecture that is threatened by agile methods. In this type of organisation, it would be preferable for the architecture function to focus on the project/programme pipeline to identify opportunities to deliver enterprise capabilities that fulfil the requirements of several planned projects. And more importantly once they have been identified, articulating a high level solution and gaining support and funding to deliver the capability. Once funding has been secured, the project can be initiated and agile methods employed to deliver the solution. At this point, architecture will move to a governance role to ensure that the implementation does not diverge from the vision.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 869 other followers

%d bloggers like this: