The architect is dead. Long live architecture!

As an agile coach I am often confronted with an odd folk named "software architects". Actually I have been one of those guys for a long time myself. I just had an interview where a group of my current company wanted to hire me as a co-architect. Feeling honored on the one hand I still couldn't really explain an annoying feeling on the other hand. Something was disturbing me and I tried to get a grasp on it. I noticed I'm in constant struggle with these architects since I began to breathe agile air. So why is that, what is really behind this sudden resentment towards the job title "architect"? 

Is the architect outdated in an agile world? Should we get rid of them? I say "yes" (just to do some shocking). 

But does that mean that in an agile world there's no place for architecture? Of course not. That would be silly. Even if we claim that software architecture should be evolving out of the teams and that means along stories or epics it still makes sense to think around the corner. It would be incredibly dumb to build a feature plain dumb simple just to get a quick win on stories delivered when you already know the extensions needed thereafter in the consecutive sprints. A good architecture should be extendable. This means spending some more time on the realization of a feature than the one-way, non-extendable quick shot. And the guys taking care about good architecture are software architects, right? Ok maybe also a little bit of the "better developers" of the team. But the overarching work remains in the hands of the chosen ones, the software architects. Agree? Well, I don't. I come from West Berlin and I don't like it. 

What I try to flame here are not the architects as persons but an (in my eyes outdated) way of working prevailing for many software architects. Therefore the radical "no" to architects, but let me explain how I mean it. No to architects in their classical role, hovering somehow above the teams and proclaiming wisdom, gracefully spreading it amongst their underlings, e.g. the teams. So how should modern, agile architects (does that exist or is it contradictory?) behave and act? 

During the interview I digged a bit deeper and asked the architects trying to hire me how they work. How they maintain their day-to-day business, what are the clues, what are the hard times. It turned out they had a lot of meeetings. A lot of coordination of "requirements from the most different parts of the company. And then they all change their minds". Wait a minute: Wasn't that product owner stuff to get all the stakeholders under the hood? This was inspiring to me. I recognized there's a working style which doesn't fit good into the agile world. And I guess this wasn't something special about these guys but a working style prevalent in most companies with the architect's role. 

The software architect comes from the old, plan-driven world. In many companies it's still a career level and dubs and elder, experienced developer. He is the most experienced guy and knows best how to look into the crystal ball. Due to her vast experience she foresees the future best thereby delivering the most elaborate and excellent high class architecture meeting the requirements even of tomorrow. Every half-way experienced developer dealing with complex systems knows this is bullshit. But still the role prevails, often accompanied with some extra title like "chief" or "lead" architect. Leadership and guidance isn't something bad or evil from the core. But knowing where the classical architect's role comes from it gets a bit of an extra bitter aftertaste. 

I wouldn't claim every architect has to behave like that. I guess there are a lot of cool architects out there perfectly fitting into an agile landscape. But I think they are a tiny minority and most often even don't know they are doing a thing called software architecture. Therefore I would like it best to find another title for them, not mixing them with the gray eminence described before. Although I have to admit I don't have a good name in mind right now.  

So how can architecture be dealt with in an agile world? I would say just as any development work along stories or epics. The special thing about architectural stories is that they often overarch many systems, teams and epics. This makes it so complicated. I think it's a good way that architects stick together in some horizontal organizational unit, just as ux designers may stick together or football fanatics from different teams. Talking with other people beneath your own artificial borders is always good. Anyway I think that architects should clearly be part of the teams. 

Then there are frameworks like the scaled agile framework (SAFe). There it's the first time in the agile world that the architect is back with an explicit role. I don't like this pattern so much. While I think it's quite good to have some architectural board where all the guys stick together and discuss good architectural needs beyond the bounds of their teams I still believe that the harbor should be service for a team and not some unit hovering above the team. Horizontal networking is good and should be encouraged. The role of the system architect as described in SAFe can be a good one and coordinating one. Still I believe that architecture should be evolving out of the teams and not be foreseen. 

In my eyes an architect should be an experienced agilist and developer. His special duties are to see stories and epics of neighbor teams and finding architectural stories or enablers as named in SAFe. He should have the vision to put those enabler stories together with the product owners (or product manager on a higher abstraction layer) into the backlogs. That's basically what agile is all about from a developer's perspective: A good developer is asked to fill the backlog with technical stories and helping the product owner out on this one. An inexperienced developer won't make any proposals. And this is what architecture is about. I think it's good when people take the responsibility to take care about the overall architecture. But it should be emerging from the teams and influence the others, not the other way round in some top-down style where architecture is poured upon the teams from the pulpit of the architect's sanctuary.  

Developers, who have found their claim on architecture, interested in the bigger system, should be encouraged to do so, just as developers who have written a good usability into their cookbook or clean code craftsmanship. I'm not so sure if all these guys need an extra title on their own. I guess not. That's why I would say: Stop running around as an architect. Start doing good architecture – together, within a team.