A few thoughts on the role of software architects

The word “architect” means different things to different people inthe context of software engineering.  And it varies wildly depending onthe kind of organization you’re in.  An architect at a medium sized ITshop might focus on connecting disparate business systems together at ahigh level, but without diving down into code.  An architect at astartup may be more like a tech lead, checking in code like mad, butalso keeping the rest of the team in check.  And a software architect atMicrosoft can play an even varied number of roles because the companyis so large and diversity of projects so great.

A colleague and mentor of mine who I respect greatly says that anarchitect is the guy (or gal) who is in charge of making those decisionswhich, if made incorrectly, could sink the project.

There is a lot to be said for this.  These decisions are those withthe broadest, deepest, and longest lasting impact.  The decisionsthemselves are often made by team members initially, but the architectis responsible for providing constant and rigorous technical oversight. Architects set the high level technical agenda, look ahead severalreleases, and keep the team on course.  They are ultimately to blame ifthe technical foundation is unsound and/or final solution fails to meetexpectations.  Their butt is on the line.

On one hand, an architect is the lead engineer with most at stake inthe project.  On the other hand, an architect is more like a member onthe project’s board of directors, providing high level guidance andmeddling as little as possible (but as much as is necessary) in theday-to-day details.

An architect’s success is measured by what he or she ships tocustomers, and not by the amazing ideas that were ultimately neverrealized.  This necessarily means an architect’s success is deeplyrooted in the team’s culture, work ethic, and ability.  He or she needsto work through others to get things done.

There have been some great architects throughout the course ofcomputer science, but who may not have been labeled as such.  LinusTorvalds is the architect of Linux, and David Cutler the architect ofWindows NT.  John Backus was arguably the architect of FORTRAN, NiklausWirth the architect of Pascal, Bjarne Stroustrup the architect of C++,James Gosling the architect of Java, and Anders Hejlsberg the architectof C#.  Bill Gates was the architect of Microsoft BASIC, and CharlesSimonyi the architect of the initial versions of Microsoft Office (Wordand Excel).  In each case, you can see that the end result is veryreflective of one person’s value system and ideas, but took a lot morethan just that person to be successful.  Each of these people learned tolet go of their project just enough that it could achieve the scalethat it was meant to achieve, but not so much that the project veeredoff course.  Some projects have multiple architects, but the successfulones usually have one who is really in charge.

Already you can see some subjective opinion being thrown into themix, and some of it is apt to be controversial.  Although notcomprehensive, I’ve put together seven guiding principles that Ipersonally aspire to.  I’ve certainly not mastered them all, but havealways looked up those people around me who seem to have.  Why seven? No reason, really.  Over the past few years, I’ve tried to spend as muchtime as possible learning from successful architects, and these standout in my mind as being the key common attributes that appear to becommon among them.

0. Inspire and empower people to do their best work.

Architects ultimately succeed or fail based on the quality of peopleon their team.  Knowing how to inspire and empower these people, so thatthey can do their best work, is therefore one of the most importantskills an architect needs in order to be successful.

You can’t do it all yourself.  This can be frustrating at times, andat times you might think that you can (particularly in times offrustration).  I’ve personally hacked together 1,000s of lines of codethat I’m incredibly proud of in a weekend, and that would have takenweeks or months to get done if I had to instead explain the idea tosomebody else and wait for them to write those same 1,000s of lines ofcode.  And the 1,000s of lines they write of course wouldn’t end upbeing the same as the ones you’d have written.  And they may decide thatthey don’t like the design after all, start discussing it withcolleagues, stage a mutiny, and ultimately overthrow what once seemedlike a great idea.  This is a tough pill to swallow.  But it’s a sadfact of life that you need to learn to be comfortable with.

The same thing would have happened if you were the one to implementthe idea, of course; the difference is that somebody else needs to beempowered to take the kernel of an idea, and run with it.  That entailsreshaping it as necessary to make it realistic and successful.

I’m not suggesting architects don’t write code (quite the opposite:see #3 below), but you can’t write it all (except for very smallprojects).  If you buy the argument that an architect is just theleading senior engineer on the project, then by definition the architectis probably qualified to write quality code quickly.  But what aboutthe code they don’t write?  Other people on the team need to write it,and the architect needs to have enough time (where he or she isn’thacking code) to inspire those people to write the right code.  Thistakes energy and effort.  You need to paint a compelling picture of thefuture, but with enough open-endedness such that the team can flex theircreative muscles and fill in the details.

This is the only way to scale.  And architects need to scale to achieve broad impact.

Architects should also welcome all ideas with open arms.  You want tofoster an open and energetic environment on your team, whereintellectual debate is the norm.  All ideas are fair game.

That’s not to say all ideas are good ones, and ultimately the badones need to die a quick and painless death before going too far, but anarchitect who won’t even entertain new ideas from the team (typicallybecause of NIH syndrome (i.e., Not Invented Here)) often drive away thebest engineers.  Great engineers hate to be told what to do.  They don’twant to feel like they are walking in the shadows of somebody else. They want to use the skills that make them so great, which involvesinventing bigger, badder, and more impactful designs.  And you want themto use these skills too, because that’s why you hired them: theseskills are crucial to the success of your project.  Part of your role asthe team’s architect is to recognize who on the team has the mostpotential, and to arrange for them to have as much leeway and creativefreedom as possible.  You don’t want to end up with a bunch of lackeyswhose job is to “just implement” your ideas, because you’ll get what youpaid for.

It’s a true sign of success when the culture you impart unto yourteam allows them to invent things in the spirit of your own designprinciples, but without you needing to do it yourself.  Jim Gray, forexample, inspired countless people to do great things.  Does he getcredit for each of those ideas?  Of course not.  But was he indirectlyresponsible for them to some degree, and do they all have a little JimGray in them?  Absolutely.  Being an architect on a team is similar; notevery idea has to be your own.  In fact, it’s far more powerful if fewof them are.

1. Oversight, but not dictatorship.

That brings me to technical oversight.  Because an architect istypically not a manager for his or her project (although in some caseshe or she may be), arms-length influence needs to be used to get thingsdone.  In fact, the architect may have very little to say over specificproject management, scheduling, and budget decisions, but is typicallyon the senior leadership team for the project.  So when I talk about“leeway” above, I’m talking about the degree to which an architectmonitors and attempts to meddle with the progress of the team.  Whileit’s tempting for an architect to set the ship sailing to sea, and thenturn around to work on the next big thing, this almost never works.  Theinitial vision and idea is far from a shipping solution, and softwareengineering only gets interesting once you actually try to buildsomething.  Ideas are cheap.  The architect needs to help the team workthrough the ramifications of certain technical decisions that were madeup front, and help with the continual course correction.

Because an architect’s butt is ultimately on the line, he or sheneeds to work as fast as possible to correct problems when somethinggoes wrong.  This implies the architect is involved enough to noticewhen something goes wrong, hopefully well in advance of anybody elseseeing it.  I’ve seen many models that work, ranging from the architectbeing the approver for all major design decisions, to the architectsimply reviewing all major design decisions after-the-fact, to thearchitect delegating this responsibility to trusted advisers.  Forexample, Linus Torvalds for the longest time required that all checkinsto the Linux code base be reviewed by him.  Anders Hejlsberg stilleffectively approves each C# language design change.  In my opinion, thecloser to each major decision the architect can afford to be, thebetter.

Left to its own devices, the team would veer off course in no time. That’s not because of malicious intent, but rather because of the sheerdiversity of software engineers.  This diversity is present on manylevels: in skill level, taste (which is hard to measure: more on that in#2 below), motivation, work ethic, interpretation of the vision,personal beliefs and experience, and so on.  An architect acts as alow-pass signal filter, smoothing out any irregularities that deviatetoo far from the core design principles.

In Tony Hoare’s ACM Turing Award paper of 1981, The Emperor’s OldClothes, he explains the risk of not providing this kind ofarchitectural oversight:

“’You know what went wrong?’ he shouted - he always shouted – ‘Youlet your programmers do things which you yourself do not understand.’ Istared in astonishment. He was obviously out of touch with present dayrealities. How could one person ever understand the whole of a modernsoftware product like the Elliott 503 Mark II software system? Irealized later that he was absolutely right; he had diagnosed the truecause of the problem and he had planted the seed of its later solution.”

Sadly, this responsibility often entails being “the bad guy”. Sometimes you need to mercilessly kill an idea because it would putcertain parts of the project at risk.  Other times you need to letsomewhat bad (but not too impactful) ideas go.  There’s a tradeoff here,because each time you kill an idea you’re going to leave somebodyfeeling burned.  And you may waste peoples’ time, depending on how muchtime has already been invested in that idea.  Some battles are best leftunfought.  There is an art to be learned here: if you can get thosewith the idea to firmly believe that there has to be a better way, youcan avoid being seen as the bad guy.  “Sit back and wait” can work insome cases, but it can backfire too.

The deep involvement in the technical design details unfortunatelymeans that the architect can become the bottleneck if he or she is notcareful.  This can slow the team down.  Some slowdown can admittedly be agood thing, because it has the effect of forcing more thoughtfulness ineach and every decision.  But as the team grows, the granularity ofdecision oversight necessarily has to change to ensure the team isempowered to make progress.  In order for this to work, you need to havetrusted individuals who are involved at a finer granularity and willuse the same principles and values.  This takes trust and time.

2. Taste is a hard thing to measure, but is invaluable.

Software engineers like to measure.  Many people try to make designdecisions based on quantitative data, even though they know thatengineering is more of an art than a science.  But there is one commontrait that, as far as I can tell, is impossible to measure, and yetcommon to all of the great software architects I know: good taste.  Andbecause it’s impossible to measure, those who lack it have a hard timeunderstanding the difference between a design with good taste and onewith bad taste.

There is a certain elegance and beauty to the designs created byarchitects with good taste.  When you see it from a distance, you knowit, but when viewed under a microscope—the kind of microscope used whendebating the finer points with other engineers on the team—it is muchharder to detect.  Often it’s incredibly difficult to articulate whysome particular design has good taste, which makes it even harder tojustify.  Eventually people are willing to trust your judgment becausethey begin to see it too.

In fact, good taste is perhaps one of the most important skills anarchitect needs to have.  Bad taste leads to clunky designs that nobodylikes to use.  Steve Jobs knows this.  And yet taste is probably themost difficult skill for an architect to develop, and one of the subtlerones that few people recognize as being necessary.  Many managers thinkthat throwing more engineers at a design problem will solve it, when inreality often all that is necessary is one person with very good tasteand an eye for detail.

I’m not certain where taste comes from: an innate skill?  Perhaps,but not exclusively.  In my best estimation, good taste can be learnedfrom paying close attention to the right things, taking a step back andviewing designs from afar often enough, being learned in what kinds ofsoftware has been built and was successful in the past, and having atrue love of the code.  That last part sounds cheesy, but is true enoughto reemphasize: if you don’t feel a certain passion for your code andproject, it’s a lot easier to let bad taste run rampant, because yourcare level isn’t as intense as it needs to be.

3. Write code and get your hands dirty.

The best architects realize that code is king.  It rules all else. At the end of the day, Visio diagrams, high level vision documents,whiteboard works of art, design documents, emails, functionalspecifications, and so on, are all a means to an end, not the enditself.  The code is your product, and if you don’t understand the code,you don’t understand the state of the project.  And if you don’tunderstand that, you’re not in a position to know what’s working well,what isn’t working, and you can’t possibly have the deep understandingnecessary to influence the engineers on the team.  You’ve lost control.

The worst architects couldn’t code themselves out of a cardboardbox.  If you’re not writing actual product code, you’re not anarchitect: you’re an ivory tower has-been, and probably doing moredamage than you are helping matters.  Do your team a favor and move intomanagement as quickly as possible.

Writing code also has the benefit of ensuring that you maintaincredibility with the team.  It’s easy to dictate crazy and grandioseideas, but if you’re the one who has to implement such a grandiose idea,you’re apt to be more sympathetic with and mindful of the otherengineers of the team.  You need to keep yourself grounded and writingreal product code will help to ensure your technical decision makingcarefully considers the implementability and down-to-Earth ramificationsof your decisions.

Moreover, you need to be a programming expert.  People need torespect your abilities, and you want your team to look up to you.  Youwant them to come and ask for your advice because they want it, andenjoy it, and not force them to deal with you simply because of yourposition on the team.  All of the great architects I’ve worked with haveinspired me to grow simply because they know so damn much, and because Ilearn something new every time I interact with them.  If they didn’twrite code and understand the nitty gritty technical esoterica, thisrelationship would have been a shallow one.

4. The power of the dyad: know your weaknesses.

Architects need to play a dual role in understanding both businessand technical needs and strategy.  The degree of business savvinessvaries greatly among architects, although the best architects I knowhave a unique ability to understand both sides of the coin.  But at theend of the day, they are first and foremost technology wonks, and thebusiness angle is more of a curious hobby.  In music, two notes soundingtogether form dyad, while three or more form a chord.  The bestarchitects I know realize their relative weakness on the business end ofthings and partner up with another senior leader with complementaryskills, to fill in the gaps: this forms a harmonic interval.  A dyad.

The partnership needn’t entirely be “business” vs. “technical”,although in commercial software that’s more often than not the twoopposing forces.  For example, my impression of the development ofScheme is that Guy Steele played the role of the architect while GeraldSussman was the more business-oriented advisor, looking at how Schememight be used to advance the broader research agenda but not necessarilymeddling in the technical design details of the project.

If an architect is 80% technology and 20% business, partnering withsomebody who is 20% technology and 80% business can be a killercombination.  This allows you to bounce ideas off one another, and toget a certain level of objective feedback from a different perspective. If you’ve got a great technical idea, and bounce it off anothertechno-nerd, you might spend hours or days debating technical detailsthat ultimately boil down to a matter of taste.  But if you take thatsame idea and bounce it off your business partner, he or she is likelyto provide more pertinent feedback: does it make sense from a businessperspective, will customers need it, will it open up new product orrevenue opportunities, are there more pressing matters to focus the teamon, etc.  These are things that, being a technology guy (or gal),wouldn’t immediately come to mind.  But remember: it’s all about thecustomer.

5. It's for the customer, not you.

The best engineers often succeed because they focus on scratching apersonal itch.  That’s what Linus Torvalds, Bjarne Stroustrup, andcountless others did.  This is why Donald Knuth created TeX.  The ideafor a new technology thus begins as a very personal and selfish act. “Build something you’d use yourself, and the customers will come” is acommon (cliché) idiom.  Although there is certainly truth to this, it’strue only because the very fact that it is bothersome to the foundingengineer is likely indicative that it’s bothersome to a broader set ofpeople.  It’s an example, where an example is just one element in a setthat is used to demonstrate some common attribute among all elements inthat set.  Those people are your customers.

As a technology matures, it’s important to realize—particularly whenbuilding commercial software—that actual human beings will want to usethe technology.  It’s important to understand and respect their needs. It’s important to, at some point, realize that you’re not, in fact,building a system entirely for your own personal use.  Not realizingthis point can blind you and make you neglect the need to partner withsomebody who understands the business angle of things.  It can also leadto a feeling of needing to develop the perfect idealized solution andnever ship to customers.  Hey, when there are endless technical problemsto work on, who would want to ship anyway?  By its very definition,shipping software means that you’ve solved all of the major technicalproblems within a certain scope.  What fun is that?

The fun is that you’re able to make an impact on your customers’lives, hopefully for the better.  Your initial technical vision has cometo fruition, and you can move on.  You get to prove your ideas byhaving real human beings to use the end product.  If you never get tothat state, then you’ve done some possibly interesting research—which ishopefully documented and used by somebody someday in the future toactually impact people by delivering a system based on those ideas—butyou haven’t architected a product.  You’re a researcher, not anarchitect.

6. Admit when you're wrong, fall on your sword, and then fix it.

You are going to be wrong sometimes.  Trying to do big and boldthings necessarily involves some risk.  Being an architect requires acareful balance between sticking to your guns—your guiding principlesand technical vision—and realizing when things aren’t working out andcourse correcting before it’s too late.  It’s hard to tell when thingsare beginning to go off course, but when they’ve already gone off courseit’s usually obvious.  A common telltale sign that things are introuble is when the team no longer believes in the vision.  This maytranslate into attrition (often of your best engineers first), or justhallway grumblings.  Listen carefully.  If you’re not involved in thedesign decisions, writing code, and actually playing a significant rolein your team’s daily lives, then you’re apt to miss this.  As thearchitect, you are responsible for responding as quickly as possible tosuch situations before the shit hits the fan.

Some architects can fall into the trap of using dogma overintellect.  Firm principles are of course something I’ve stressedthroughout this article.  But you need to be honest with yourself andadmit when things are not going well.  An architect who stands at thehelm of a sinking ship, proclaiming that the ship stay its coursebecause the brave new world lies ahead, will only drown (alone) when theship finally goes underwater.  Although this architect can then goaround blaming his team for the failure (“if they had only seen thevision and stuck around, we would have succeeded”), the project will belong gone by then.  It’s harder, but more noble, to recognize theproblems proactively and do your best to fix them.

For example, Tony Hoare describes in the same ACM Turing Award papermentioned above, how he felt responsible for the failure of the Elliot503 Mark II project:

“There was no escape: The entire Elliott 503 Mark II software projecthad to be abandoned, and with it, over thirty man-years of programmingeffort, equivalent to nearly one man’s active working life, and I wasresponsible, both as designer and as manager, for wasting it.”

It can be particularly disturbing to realize that a large number ofpeople have been going off in the wrong direction on your watch.  Yes,you wasted their time.  But you have to learn what went wrong,internalize it, and commit to never making the same mistake twice.  Youowe it to them to respond promptly.  Everybody on the team will havelearned and grown from the circumstances, and if you’re lucky thesituation is salvageable.  Sometimes it won’t be.  But in any case youwill gain the respect of many around you by making the right decision;particularly if you’re the only person with the broad technicalresponsibility, understanding, and insight necessary to make such adecision, people will feel relieved when you make it.  And if you don’tmake it, people will curse you for it.

In conclusion

I’m sure there are many other laundry lists of skills people mightcome up with that are necessary to be an effective architect, but theseare a few of the things I see and respect in the people I look up to. I’ve named some of these people throughout this article.  The mostcommon trait is that they have done great things and left their mark onthe industry.  Being an architect, in the end, is all about helpingothers to succeed.  If you’re a really good architect, you’ll inspirepeople and rub off on them.  You’ll gain a certain level of respect thatis unmistakable and priceless.  And that, in my opinion, is far morefulfilling than anything you could accomplish on your own working in avacuum.