The kind of long-range planning an architect is asked to do, which so readily turns into a long-term commitment, triggers a sort of allergic reaction in most agile software developers these days. I know it did for me. It kind of still does.
However, I've found a way around that with value-stream-oriented architecture. At least, I found a way that works for me. Using a tool like VSOA, you can avoid creating the kinds of plans that become commitments or that interfere with implementation-decisions better made by individual teams.
So I'm coming around to accepting the value of someone doing architecture. The next question is should it always be the same someone? Put another way: should there be "an" architect or should architecture be another kind of activity in which an agile team engages? I'd like to warn you right now that I don't have the answer.
Pros
The most obvious argument on the pro side of the question is that if you have a designated architect, architecture will get done. Architecture, while a valuable task under certain circumstances, is not usually a task critical to the completion of any given story in an agile environment. If you don't have someone dedicating some portion of their time to it, then it is likely to fall by the wayside. The effects of not doing long-term planning an coordination are felt much later and difficult to trace back to a lack of architectural attention.Designating an individual as a team's or enterprise's architect ensures that time will be spent on the task. Most agile teams have designated product owners for precisely this reason: someone needs to be thinking about the next steps. In fact, my friend Mike Brown likes to refer to architects as product owners of technical value.
Just like a product owner, this also means that if coordination must be done with other sites or organizations, you already know who is going to head out there to do that. While that may be distracting for the architect, it allows the rest of his team/enterprise to focus on creating valuable products.
It is also possible that concentrating the architectural tasks into one person allows them to gain a perspective on the whole that they otherwise would not have. That perspective would then allow them to create more coherent visions for future development, better interact with product ownership, and better drive developers toward that vision.
Cons
The most obvious argument against having a designated architect is that putting someone in that kind of position is tantamount to handing them a bunch of dynamite and they might take themselves and their teams out just as easily as they could blast out a quarry.
It's to true to ignore. In some respects, I wonder if the notion that someone who is interested in politics ought to be banned from politics also applies to architecture. Most people who want the power of being an architect will not use it to create value. Few architects today are architects because they wanted the influence.
The fact that an architect can be like a kind of product owner carries both edges of the product owner sword. Sure, only one person has to travel but that means that the one person responsible for those kinds of decisions and that kind of learning is often not available for questioning. Sure, they might get a better perspective than they otherwise may have had but it is still a single perspective and thus more vulnerable to confirmation bias.
Widening Our Options
In Decisive, it is said that dichotomies are a decision-making smell. I've observed that for myself several times since having read the book. So I'm going to add one more option.
The team that I was working on went through similar gyrations with product owners (POs) for several years. These issues were exacerbated by the POs' very aggressive travel schedule. What we settled on was a blend of the "have a PO" and "share PO responsibilities throughout the team" options.
We have product owners and they do own product design but they do not make all of the product design decisions. They are responsible for the product design decisions and, for that reason, they can countermand one they don't like but we don't wait on our thumbs for all product innovation to flow from the product owner as someone preaching a very strict, very academic version of scrum might suggest.
Instead, the team as a whole contributes to product design. The product owners guide that effort with the knowledge and perspective they have gained and they set direction by making big decisions and performing long-range planning.
Sound familiar?
So the other option I would like to put forth is that you can have a designated architect who is responsible for making sure that long-range technical planning is done and teams are coordinated and you can have architectural work being shared throughout a team or enterprise by all of the developers.
No Answer
I stand by my earlier statement that I have no answer to this question. For one thing, I didn't have an answer when I started writing this entry. For another, I'm not sure I do even now. Certainly, the idea of decoupling ownership of architectural issues from execution of architectural tasks is an interesting one. The success my current team has had by employing that strategy with product ownership makes it a tempting one.
So tempting I'm going to try it but I still don't have an answer. Not yet.
