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.
Lean software architecture
Agile != Just go coding
Agile != Don't plan for the future
Agile development and Enterprise Architecture practice – Why they need each
As a realist, you need a bit of both.
EA = context, agile = delivery
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
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
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
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.
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015