Now that I’ve been out of the architect hot-seat for a while, here are some collected thoughts on how to make it a more productive role. I’ll start with a couple of things management needs to do to enable an architect to do their job.

Gimme Some Power
What do you call an architect who has no actual power to make sure developers do The Right Thing? A lame duck – one who can be and often will be ignored by exactly those developers who are most likely to do The Wrong Thing in the first place. If you want someone to be responsible for the technical success of a project, that person must have some means other than mere persuasion to ensure that success (because some of the people writing the code don’t respond to persuasion). In essence, the architect must be able to reject any code checkin. The relationship between the architect and the release engineer should be one of the closest in the organization, with each in their own way determining what does and does not go into the product. Only when there are real consequences (e.g. missed deadlines) to checking in something that works now but will break tomorrow will most developers pay attention.
Rein in the Managers
It’s part of a manager’s job to keep an eye on schedules, and also to play advocate for developers. For both reasons, managers will often try to force a questionable code change through despite an architect’s objections. This can’t be allowed to become the norm. That doesn’t mean that the architect should run rough-shod over managers either, but any director/VP who allows managers to get their way every time has just hamstrung their architect. Similarly, developers usually go to their manager first when they need a higher-level technical decision, often with some urgency. It’s generally almost impossible to reverse such decisions after the fact, so if they’re often made without consulting the architect responsible for the “big picture” the project very rapidly turns into another Tower of Babel with components and their developers all working at cross-purposes. Managers must be constantly on the lookout for this, and make sure that the right people – not just the architect – are consulted for any change affecting more than one component.

Now, what can the architect himself (or herself, but I’m a guy) do? Here are some ideas.

Articulate a Vision
The first part of this is simply to have a coherent vision of how the product should work, presently and going forward. The second part, obviously, is to document that vision…but a document’s not enough. The third and most important part is to communicate that vision. Whatever you can do to make sure everybody knows and understands how the parts all fit together is probably worth it. That might mean giving a lunchtime talk about the architecture once a month. It might mean a stream of emails announcing changes, or a blog or a wiki. It might mean setting up a schedule to talk to every single developer on a regular basis to make sure they understand the parts that they need to. If people don’t know the vision they won’t follow it, and that will end up being more of a pain than keeping it in front of people.
In any non-trivial project there will be a hundred things you think need to be cleaned up. You’ll also be spending way too much of your time in meetings, reviewing other people’s specs and codes, facilitating communication (see above) and so on. If you try to do too much at once you’ll just thrash. The only way to survive is by aggressively keeping track of the few technical areas that most immediately need your attention, and putting off the rest until later. Think of the warts you’re ignoring as a form of job security.
Maintain Perspective
There are two kinds of useless architects: the head-in-the-clouds dreamers who haven’t written code for years and don’t really understand how the product works, and the down-in-the-dirt types who have become too tied down with direct work on one or two components that they’re no longer any better able than any other developer to see the big picture. Somehow you have to walk a line between those two extremes – near the front lines but not stuck in a foxhole. You need to find ways to get involved in actually working on what you’re building, and then find ways to get uninvolved so you can move on, and then repeat the process ad infinitum. This not only builds perspective but also builds trust; people need to feel like you understand their piece of the system, and sometimes they won’t believe that you do unless they’ve actually seen you do something productive with it.