Agile and Architecture Conflict

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.