Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Agile and Architecture Conflict

Agile and Architecture Conflict

Leia em Português


There is a constant tussle between following Agile techniques and still managing to do enterprise architecture. While Agile development focuses on adjusting the design and plan as more insight is gained into the domain, architecture establishes the technology stack. It addresses the quality attributes and communicates to the interested stakeholders. Combination of the two is successful when agile techniques are leveraged to drive towards the desired architecture.

Tom Graves suggested that Agility needs a backbone to drive on. This backbone is provided by architecture.

[A]gility often needs a backbone to give it some direction – something to push against so it that can do more than merely flop about at random. As usual, it’s a question of balance – getting the right balance between the solid bone and the agile muscle.

Jan Van Til agreed with Tom when he suggested that without the back bone which is in the background, it would be tough to see Agile in the foreground.

We definitely need a somehow ’slower’ moving ‘background’ to be able to see agility (on the ‘foreground’). If everything would be fashion… would one be able to distinguish one fashion from another fashion? We definitely need a somehow ’slower’ moving ‘background’ to be able to see fashion (on the ‘foreground’). In other words: we need tradition. Without tradition there is no fashion.

Simon Brown suggested that even the 'most Agile project' would have architectural concerns of some degree. These concerns need to be addressed during the early iterations of the project. According to Simon, the conflict between Agile and architecture boils down to delivering value in small chunks as compared to doing a big upfront design. The key is to do just enough design. It is important to put a high level structure in place but that does not mean drawing countless detailed class diagrams.

John Bauer mentioned an interesting pattern that he had observed over a period of multiple projects.

Agile and agile-like approaches have a positive by product of reducing the occurrence of over architect-ed software solutions. Over architect-ed solutions put stress on the delivery of a software application project as well as drive up the cost of software development and maintenance, in general, disproportionately to the business value produced.

James Coplien & Kevlin Henney presented an efficient way to start with just enough architecture and ensure the success of the project.

But how does it all tie up in the real world?

Simon Brown posted an interesting challenge to replace an aging Internet banking system in a matter of four months. The idea is to move in an Agile way and still deliver. There are a few proposed solutions on the post as well as the ones posted by Kero and John Bauer. You could keep track of more solutions and provide your own.

Thus Architecture and Agile need to coexist. It is not a matter of either/or but both/and. The key is to do just enough. Simon defined just enough as,

Do just enough architecture to give you clarity and vision. In other words, do enough so that you know what your goal is and how you're going to achieve it. The key is that architecture represents the significant decisions, where significance is measured by cost of change. In other words, it's the stuff that's really expensive to modify and the stuff that you really do need to get right as early as possible. For example, qualities such as high performance, high scalability, high security and high availability generally need to be baked into the foundations early on because they are hard to retrofit into an existing codebase. It's also the stuff that you can't easily refactor in an afternoon; such as core technology choices, "architectural" patterns, core frameworks and so on. 

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Lean software architecture

    by Hugo Valk,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    People might be interested in the book by J. Coplien "Lean software architecture".

    Agile != Just go coding
    Agile != Don't plan for the future

  • Agile development and Enterprise Architecture practice – Why they need each

    by Udayan Banerjee,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Agile is self-organizing, EA is top down, structured and planned. So some extent both are Utopian world view.

    As a realist, you need a bit of both.

  • EA = context, agile = delivery

    by Guy Pardon,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Enterprise architecture will give you the set of contexts (cf DDD) in which different agile teams can work. At least that is how I see it.

  • EA

    by David Johnson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I guess we are talking about enterprise IT architecture instead of EA which is more focussed on the business as a whole.

    Agile is used a lot in development and here indeed it might get into conflicts when principals and boundaries are defined in enterprise IT architecture. Although you can just look at it as any other requirement and boundary a project might have. The enterprise IT architecture team is just another stakeholder that the product owner will have to take into account. The conflicts I have seen are usually in situations where a development team think that they are limited in their freedom (e.g. choosing the technology stack for their project). Which can usually be resolved by a better communication between both teams.

    But really I don't see any conflict between them. Agile is a way of working, while enterprise IT architecture is more a type of work. There is even no problem with doing enterprise IT architecture in an agile way. Enterprises are evolutionary systems anyway, so agility is actually a good thing. Enterprise IT architecture just has a broader view than projects and is more focused on vision and strategy, while projects are usually delivery focused.

  • This is not a Boolean issue

    by aditya yadav,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Its not either Upfront Architecture or No Architecture. The agile concept of "Delay decisions till the last responsible minute" comes into play along with "Iterative and Incremental" practices.

    We don't want to spend 6 months doing architecture and producing a 400 page UML intensive architecture document. And I guess this has to do with the speed of changes. If the system changes once in 10 years then perhaps upfront architecture makes sense. If some part of it changes every 1 month then Agile is the way to go even if its EA.

  • Re: This is not a Boolean issue

    by Augusto Rodriguez,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Aditya nailed it. Agile and EA don't conflict, that's a misconception from the same people who took other principles or practices to the extreme (of absurdity).

    The concept of Agile and EA conflicting reminded me of this Dilbert strip:

  • An example of agile and architecture working together.

    by Alexander Samarin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p