I was recently watching Dan North’s latest presentation on InfoQ. Right near the start, he pops up a Dreyfus ladder, leading to expert programmer and then… novice architect. Now, I’m a fully paid up member of the school of “once you’ve mastered something, it’s time to go find something you suck at”. However, I was thinking about the various things we mean by architect. Looking back, I’ve been described as architect a few times and met many others described as such. But the roles didn’t have very much in common. Here’s a quick taxonomy of software architects
For some people, the architect is the guy who insists that everything is done on Oracle, regardless of context. Or writes documents that say things like “All IPC must go through SOAP”. This guy is the policeman of the company’s software infrastructure. Typically, you’ll come up with a design and he’ll have to “validate” it before you build it. Usually, you’ll find that this process and this role treats innovation as a defect. In general terms, the very existence of this job is a sign your employer doesn’t trust her developers.
I’ve been this guy. Luckily I had the opportunity to get this out of my system when I was 24. Apart from anything else, getting talented developers to toe the line is a value-destroying exercise.
The Numbers Guy
Then there’s the numbers guy. He’s actually contributing. What he’s doing is trying to figure out when things are going to break. Can you handle twice as much business as you currently do? Could you do what you’re currently doing faster? Is our pipe wide enough? And most importantly, what’s going to break first? How do we avoid this?
Sometime this guy’s actually a DBA. I’ve met a number of DBAs with deep and intimate knowledge of routers, disk access times and an uncanny ability to pull information (rather than data) out of PerfMon. Sometimes he’s a junior developer with a Rainman-like grasp of the latency figures coming out of Firebug.
If there’s a problem with this role it’s that shouldn’t really be a full time job. Everyone should care about this. A lot of the time you’ll see him gathering data. Data that should be there in plain sight, in the logs. In fact, some of his responsibility actually lies within the operations team. All in all, this is a good guy, and he’s doing valuable work. But when you decide to hire someone to own this, it’s a sign you have a problem elsewhere.
The System Expert
These days you’ve got a big important system that does a number of critical things. But five years ago, it was stuck together with gaffer tape and string by someone in a month. You’re lucky, and he’s still with the firm. Sometimes the expert didn’t build it, but he has supported it for three years, and knows its quirks pretty well.
At best, this guy’s your shaman: the guy who understands the history of the project and your organization. The guy who remembers “why we didn’t do it that way”. The guy who’s got a good idea of the quickest way to implement the feature your manager needs yesterday. He’s incredibly valuable.
The danger here is emotional attachment to the system in its current form. When this happens, you retard the progress of the project by failing to recognize that circumstances have changed. You’re offended when fundamental structures in the system are replaced. If you’re recognizing yourself here, it’s time to take a back seat, listen to some Sting and chill out.
The Great Developer
You’re a cracking developer, so they give you a fancy title. Make sure it comes with a raise. Recognition is nice, but you’re doing the same job as before.
The Go-to Guy
I like being this guy. A lot of the time, he doesn’t actually have architect in his title. He’s just the guy you go to when you can’t figure a bug out, or you need to talk something over, or you suspect there’s a better way of doing something than the one you’ve come up with.
You get to be this guy through three qualities: technical ability, accessibility and patience. The first is a given: if you’re just starting out, no-one wants your opinion (which is their loss, frankly.). Accessibility is necessary as well: you’ve got to have time for people. You’ve got to be genuinely glad to see them and make them welcome. Talk to them, not just fob them off with a link (URLs are for the end of the conversation, not the beginning). Finally, patience is key. Sometimes you’ve got to go back to the start of the problem and painstakingly work through every step to find the solution. Sometimes you’ve got to answer the same question five times in the same day.
The best bit about go-to guys are: you can have more than one. Even if someone else occupies this role, there’s nothing stopping you trying it too. You don’t need to know everything, you just need to be useful.
Apart from anything else, even the go-to guy needs someone to go to.
The Literal Architect
It’s worth remembering that we used to believe that building construction was a viable metaphor for software development. This guy still thinks it is. His job is to design the software down to the last detail, yours is to do the rather uninteresting task of actually building it. Usually in a development environment the architect doesn’t understand.
If you’re working in this organization, I’m sorry. I feel for you. You’ve probably also got a modified waterfall SDLC. You probably even know what SDLC stands for. If you’re really unlucky, you know what PRINCE2 means as well.
Ironically, this guy is the only one who really warrants the title architect. He does the thinking, you just lug bricks around. However, beautiful as the ivory tower shown is, it hasn’t changed in the last two hundred years. The requirements for your project have changed two hundred times in the last month. Architect is a nice title, but it’s the systems experts, the numbers guys, the great developers and the go-to guys who will make a system sing. And design? Well, everybody should be doing that.
Notes: The “numbers guy” is, of course, Al Capone. The Sting video is from the Nelson Mandela concert. The “ivory tower” is All Souls Church, a phenomenally beautiful building by John Nash. If you’re ever near Oxford Circus in London you should visit it. Nash also designed Buckingham Palace. an artist’s best known work isn’t necessarily his best.