This is an important topic, and I intend to approach it un-gently. Apologies in advance…
Software Architecture, at its worst, is the art of creating solutions looking for problems. Unfortunately, it has the ability to achieve its worst if we are not diligent.
There is not, has never been, and will never be a role called “Architect” on Scrum or XP teams. Scrum says that Product Owners own problems, “the what”, and Teams own solutions to those problems, “the how”. The Whole Team needs to decide how to best solve the problems it faces with the simplest solution possible in a short time frame. Therefore, the Whole Team owns the architecture of the solution.
Recently, at a client, it was pointed out that if teams are allowed to solve problems however they see fit, and if multiple teams solve the same problem different ways, then no one will know what the best solution is. Chaos will ensue.
Interesting problem. Let me take a stab at it:
- I don’t have any problem with chaos per se. It might even be good for you.
- If the organization has multiple teams that are capable of solving the same problem, over and over, in simple effective ways, without learning anything new, then we may have a problem. It’s a problem I would love to have.
- Given that we mostly don’t have this problem (Not anywhere that I have looked) perhaps we should try to foster teams that can create simple solutions, learning as they go, and then solve that problem when we get to it.
Reuse is mostly a red herring. There is a distinct lack of evidence that we can design for reuse and create a solution that is sufficiently simple to be flexible and responsive to change. Since Agile teams value the latter, it may not be in their best interest to attempt the former. Instead, what we tend to do is to build solutions that are more complex than the problem at hand requires (Remember essential complexity?) That complexity is like a weight we have to carry with us everywhere we go. It effects the nimbleness with which we adapt to change.
When we “architect” we bring in that accidental complexity in the name of things like reuse, performance, scalability, testability, security, etc. Not that those goals aren’t worthwhile, but they are things which are best seen in the context of what our users need to do rather than as ends to themselves. Generally, from the user’s perspective, it needs to work and do something useful first and foremost.
This is where I go back to the idea of essential complexity: first build a solution that is too simple to work. That is zero architecture. Then build that solution up incrementally, massaging and caring for the design along the way, until you have something that solves the problems you set out to solve. That is evolutionary architecture. Anything bigger or more upfront than that is probably creating solutions looking for problems.
Hi Adam,
While I agree in principle with much of your post, your perspective is very contextual. I’ve been exploring what it means to develop a large complex product on my blog. Here is a link to the post:
http://www.leadingagile.com/2010/05/ive-been-rambling-on-for-past-few-years.html
In these kinds of contexts, architecture DOES NOT emerge. The are key decision that have to be made up front when you are coordinating 100-150 people or more across a multi-product solution.
You can certainly make that case that maybe we just shouldn’t build products like this… but I can give you example after example of people doing it, and doing it well.
I think it is important to establish context before making blanket statements, however valid in your context. Just my opinion, overall, nice post.
Mike
There was a recent webinar on that very same topic you may be interested to see: http://www.sei.cmu.edu/library/abstracts/presentations/20100422webinar.cfm
Hi Mike:
I agree that 100-150 people working on a large project cannot do it the way I described. I also agree that there are numerous examples of such large project teams that have delivered successful products. The one caveat is that I don’t believe you can remotely call such an approach Agile.
The communication needs of 100-150 people trying to work together cannot be met by direct face-to-face contact alone. You need a hierarchical organization with command-and-control structures and numerous hand-offs.
Not everyone on the 100-150 person team has a direct line to the customer. Not everyone is able to make decisions that use business value as the single driver.
It is probably impossible for a 100-150 person team to deploy solutions into the hands of the customers on a bi-weekly or sooner basis with zero upfront work. Then to gather immediate feedback and make changes in an equally short time frame.
Because of these things, the work of the 100-150 person team is antithetical to the approach I describe. Not wrong, just incompatible.
To be fair there is a lot of room for disagreement here, and there are those who feel that software architecture has a place at the table. If you’ve read my other posts then you know that I come from a different school. I believe strongly that an overwhelming majority of software systems are needlessly complex, and that, therefore, focusing on how we build very complex systems is missing the point.
At the point that it becomes clear that a very complex system is the simplest thing that could possibly work then I might start to agree that some upfront management of that complexity is required (Though one way to manage it might be to build it test first.) I have not encountered such a situation yet. What I have encountered are needlessly complex systems and a lot of rationalization of why they were built that way.
I have also seen some mind-numbingly simple solutions that achieve their goals while thumbing their noses at all of the usual assumptions. I believe, strongly, that the future lies that way.
Context. At the end of the day, we might all agree that it’s about context. For the types of projects you seem to be addressing – those that are reasonably tackled by a small, dedicated, co-located team with direct customer engagement – I imagine most would agree with your premise. The team owns the solution, and nearly all aspects of the design will become clear as the solution is built. In a different context, like the large-scale solution Mike speaks to, the best approach is likely going to include a more disciplined approach to architecture. Fortunately, many of us are finding great success in applying Agile approaches, including principles and practices, to these larger scale and more complex initiatives.
It’s interesting that many of the arguments – er, spirited debates – around the most effective means of producing software stem from 1) a desire to push things to a black-and-white, one-size-fit-all approach (e.g., thou shalt not have architecture), and 2) failure to establish a context or boundary within which the stated argument is intended to be valid. At the end of the day, this puts one in the position of arguing unbounded absolutes. Rarely a defensible position.
Hi Brian:
Context:
My expertise is in the behavior of small teams solving business problems, and how to maximize their effectiveness by incorporating a disciplined approach to design and testing.
I contend that most, perhaps not all, problems can be solved by such small teams. I further contend that, for such teams, constant face-to-face communication and continuous deliberate application of simple design and refactoring are effective in achieving the goals that would otherwise be relegated to architecture.