Red and Blue Architects

I've been thinking about what I expect from a software architect in the highly skilled egalitarian teams doing iterative development that I'm part of, where we're all able to make major changes in response to changing requirements and discoveries in a changing environment.

The traditional software architect's role has been to present a right way of doing something in advanced of stubbing your toes on a problem. That presumes we know enough about our product and it's environment in advanced to make those decisions. It also tends to under-rate the capabilities of other developers to solve problems. Let's call this lot red architects. That was actually true, and good architects in that style were valuable, when I worked in the hardware business: the experts really did have deep knowledge that wasn't available without experience of the product line and general business domain, and the operating constraints of the hardware really were pretty clear in advanced. I haven't worked in that world for many years.

Now I'm working in startup land, it's much faster and looser. The problems of bad architecture still plague us but architecture delivered by red architects just hasn't really worked. We need a different sort of architect, I'll call these new folk blue architects.

Blue architects don't tell me what to do. But they insist that a certain class of question gets asked and answered. Questions that couple the business needs to the hardest technical problems so that they can't be ignored and everyone sees the value in solving them. These are the guys who ask how we're going to handle cache regeneration when we go through database failover, or how we're going to separate our background report from our web front end when the data volume makes the background processes so costly they'll impact the servers responsiveness. They ask what we're going to do when we no longer have a window for downtime because we've become globally successful. Questions that steer us away from the superficial and primitive toward effective and satisfying solutions.

Blue architects guide the whole team to produce better implementations by asking penetrating questions.

Of course everyone with some technical nouse can ask blue architecture questions. But I expect the guy who claims to have architecture specialisation to be better at it, to ask deeper questions, and to frame those questions in ways that lodge in the team consciousness. An architect fails if they can't communicate their insight; I expect anyone claiming specialisation to actually deliver.

In the last few years of work the red architects haven't had much success. On the other hand I've seen individuals deliver blue architecture questions to great effect. Let's have more blue architects.