BT

Agile and Architecture Conflict

by Vikas Hazrati on Jun 15, 2011 |

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. 

Hello stranger!

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

Get the most out of the InfoQ experience.

Tell us what you think

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

Email me replies to any of my messages in this thread

Lean software architecture by Hugo Valk

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

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.

setandbma.wordpress.com/2011/04/11/agile-develo...

EA = context, agile = delivery by Guy Pardon

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

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.

Agile and Architecture Conflict by Alexandre Poitras

Architecture = Planning ahead
When do you plan : when a change is costly and/or the risk of a wrong decision is low.
When you do not plan : when changing is cheap and/or the risk of a wrong decision is high.

Another thing to keep in mind is the cost of change can sometimes be lowered by investing in a platform or a tool. For instance, having a database that offer easier refactoring.

This is not a Boolean issue by aditya yadav

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

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: globalnerdy.com/wordpress/wp-content/uploads/20...

An example of agile and architecture working together. by Alexander Samarin

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

Email me replies to any of my messages in this thread

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

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT