Architect As Keeper Of The Flame

I've often wondered what it means to be a SoftwareArchitect. Is it just a job-title-on-steroids for programmers who don't want to associate themselves with that messy code stuff? Does it mean you can demand an extra 20k per year for doing the same job you always did? Or is there something fundamentally different about what a software architect does to what other developers do?

I've come to think of the architect as the 'keeper of the flame' (KoF). The phrase is lifted from a childhood misspent reading Spiderman and Batman comics where KoF was a title bestowed on loyal readers who wrote in to say things like "the current storyline is crap, Spiderman would never leave his best friend to Doc Oc's minions because of what happened to his uncle Ben...". These kids who wrote in really loved the fictional universe created for them, had followed all the storylines over the years, and had a view of the characters that went beyond the sum of all the words written and pictures drawn. So they really knew what was right for Spiderman to do even when the writers and illustrators who actually produced the strips lost sight of it.

For me, this is exactly the role played by the software architect. The type of technical jobs an architect does is covered in ChiefArchitect but I've met people who do all these things and somehow still aren't a good architect (probably because they do all these things but they do them badly). I think of a good architect as someone who really understands the system - not just the classes and the collaborations but the real 'soul' of the system. They're the sort of person who, given a particular change in requirements for their system, will come up with three different solutions but will instinctively know which is the right one to go for (and will then find all the technical justification in terms of changability, performance, robustness, etc.) because they know the system so well. They probably love the system a bit too.

Unfortunately this person or group of persons isn't always the one with the title of architect. Often that just indicates who's been around the longest which is sometimes exactly what is required to understand the flame well enough to keep it alive and intact ... but usually that alone is not enough. If I want to figure out who the real architect of a system is I look for the person who can always answer question quickly and decisively, who always works through 'what if' scenarios with a small smile on their face, who knows what all the dodgy bits of the system are but has plans for making them better. Sometimes this is even the person with ChiefArchitect on their business card.

BTW, and for what it's worth, one of the reasons I see XP as working towards a fundamentally better way of developing software is that XPer's spread the flame around. CRC, pair programming, working to produce user stories - all of these help to pass on understanding of the style, the philosophy, the soul of the system and the best systems are always developed by teams who share and buy into the architecture.

--PaulDyson

I was wondering what happens if you have a very large system. I have certainly heard the argument that once a system passes a certain size, no one person can be KoF (I have heard of architects as "Keepers of the Project Vision" before - I think somebody vaguely famous said that). Of course, in theory you could always just make the components of the architecture bigger to allow easier understanding, but I have my doubts about that.

--AndyMoorley

Look at the FieldStudyOfTheSoftwareDesignProcessForLargeSystems which suggests that even for large systems the ArchitectAsKeeperOfTheFlame is true. --PeteMcBreen

It's really odd, but while there are people who are more or less knowledgeable on C3, there is no one person to whom we always look for final architectural approval. If there's something big, we'll have a CRC session and generate consensus. Often they'll ask me, because I've written every program that has ever been written. I try not to answer in specifics, but instead to raise issues and options.

I'm used to there being a KoF, I'm used to being KoF. But by golly, C3 doesn't have one, and it's one of the best projects I've ever been a part of. Fascinating. --RonJeffries

There is something I've been thinking about in relation to this page and BrutalSarcasm, but it is hard to articulate. Something like: it takes real authority to come into a situation and change it so that the authority is no longer needed. -- MichaelFeathers

Andy: I disagree that a big system means you can't have a (single) KoF. Certainly, when a system gets big enough, no one person can understand the whole system. But the 'flame' is more abstract than the whole system - it is an understanding of the style and philosophy that produced this system, and will move it on as the forces that shape its role in the business change. It is true, though, that when a system gets big enough you better be damn good at communicating the flame and sharing it around because there is no way you can understand every bit of development well enough to see whether it adheres to the style and philosophy.--Paul

A question for Ron: In the sense that C3 doesn't have a single lead architect it doesn't seem to have a KoF (as an aside : I don't think XP is the only way to spread the flame around. Good communication is critical and an architect who is a good communicator can succcessfully pass on the style and philosophy in a more traditional development setup. XP's advantage is that communication is promoted and enforced in the day-to-day working practices, it is not just a facet of the architect's personality and skill). But from what I know of C3 (only from what I've read on the Wiki) the process and development values are almost more important than the actual architecture of the system. Or, to put it another way, adhere to these good practices and the architecture will take care of itself. So ISTM that the flame for C3 is actually these XP practices and that you (and Kent at a distance) are actually the KoF because you are the one that really believes in XP, can successfully sell XP to others with your enthusiasm and commitment, can see the dodgy parts of XP and have ideas about how they might be improved, and probably loves XP a little too. Is this right?--Paul

Compliment gratefully accepted. The process works: architecture emerges from a good starting metaphor and solid refactoring. The architecture is communicated through all our pair programming, CRCing, and so on. Kent and I sell XP, but do not do or push the architecture. --RonJeffries

The idea that architecture is a resultant of process and cultural forces is one which I have a lot of time for. The C3 experience is the best example I know of - but I'm sure there are other development groups out there who generate architecture from a joint vision of what to do and how to do it, and who get by just fine without big initiatives and 500-page architecture documents. --DavidHarvey

There is a way of knowing whether a person is the ChiefArchitect of a project. Do MethodObject right in front of them. If they recoil in horror, chances are they are a keeper of the flame.

MethodObject is powerful, bold and empowering. It has wonderful shock value. It tears to the root of what it means to refactor, and it separates the planners from the problem-solvers. When you feel comfortable with people on your team doing MethodObject and then refactoring to something more useful, then you can know that they are empowered to do everything it takes to succeed.

-- MichaelFeathers

I see keeper of the flame as synonymous with one who ensures conceptual integrity, per FredBrooks MythicalManMonth.