You’re a Software Architect, and then what?

Around 2009, I read an article or two telling all developers that they want to work towards becoming a software architect. Then each article went on to tell nothing substantial about what this means. It just sounded like you would be a developer with more pay and a cooler business card, I guess.

Last month, an old boss (and friend) asked me about resources for training a developer to be a software architect. After thinking about it a while, I realized that this is a hard one to pin-down. I still haven’t heard a good description for what a software architect does. It is actually more vague than the term “boss”. Because, with “boss”, at least there are some good jokes about what you do. Heh. Just kidding. But seriously, your boss is going to get some good mentoring from his/her boss. That helps. However, who is mentoring your Software Architect? What? Nobody? That’s what I was thinking too. Maybe (at best) your software architect is mentored by someone who has never been a software architect. It’s better than nothing.

Before I go any further, let’s consider the definition of “software architect”. Most public definitions go like this: Think of how an (building) architect blends art with engineering. His designs will be physically sound and aesthetically pleasing. So, you would think that a software architect should also find the harmony between design, form and function. Maybe they should strive to be an artist and a programmer.

Wrong-o. Artsy people don’t make good engineers and good engineers don’t make good artsy people. You can teach both to a person, but they are naturally going to fall into only one of those categories. Some people call this “left brain” thinking or “right brain” thinking. Maybe one out of ten thousand is going to be both. It also takes a lot of time and discipline to be good at either of these. Realistically, you will have more success by getting two separate people who are really good at (only) one of these and have them cooperate.

To identify what a software architect does, let’s start by thinking of how IT/software is a lot like the tool department at Sears. There are tools galore. Have you ever taken a few hours to walk around Sears and pick up every tool and ponder what each one is used-for and why somebody would pay hundreds of dollars for some of them? There must be some craftsmen who do this, otherwise Sears wouldn’t carry all of those tools. Somebody out there understands the use of these tools; how to use each one right and when should you choose a different tool. This level of understanding would certainly give a person some amazing abilities to accomplish great things. It has got to be better than being a guy who only has a hammer, “if it doesn’t fit, just use a bigger hammer”.

This is what a useful software architect does. (No, not the hammer guy. The other guy). When you need a new program made, your software architect will be familiar with so many approaches to design and which ones are going to be good for this project and which will be bad. A really good SWA will have tried each of the dev tools and design approaches. He will have experience with touching them, working with them. He will know their strengths and weaknesses. All of this will come from a personal interaction/experience with any/every technology. The experience is important because it means that the knowledge will be subjective. There are some things that you just can’t get from reading a book. You can only get them from trying it yourself. This is what a real top-shelf software architect does and is. He’s tried it. He knows.

Of course, the opposite of this mentality, is going to give you very few options. You have probably heard the saying, “If you only own a hammer, then everything will look like a nail”. Yeah, I’ve worked with that guy. Make that: several guys like that. When anyone like that, even tries to imply that they are some sort of software architect, it sort-of turns your stomach. Your batman mask does not make you batman. It is quite laughable, as long as it doesn’t affect you. Watch out for any knucklehead who claims to be a software architect, but only wields a hammer.

When you think about what I’ve said here, you might start to think that maybe a SWA is expected to know everything about everything. Yes, now you are catching-on. A software architect must have a desire and drive to know something about everything, with an eventual goal of knowing everything about everything (in I.T.). Naturally, that is an un-achievable goal. So start by seeking breadth-of-knowledge, rather than depth (ie. know a little about many different things, instead of knowing a few things really well).

Still, a Software Architect is not expected to be an expert on everything. In fact he is not expected to be an architect over everything. There are several other roles/titles in IT like this. Here are a few:

  • Information architect – thinks about how the information can be organized, stored, accessed, recovered/relocated/failed-over, shared, protected, etc. How would a specific design be better/worse/unusable in different circumstances.
  • System architect – A higher level of abstraction. He thinks about hardware, operating systems, networking, databases, firewalls, etc. Software and programming are just a few optional components.
  • Others {network architect, security architect, …}

I suppose a person could even do several of these things, simultaneously, but each one takes time, focus, commitment. Certainly, if you only dabble in each of these, then your understanding will be superficial and the value will be marginal (or worse). I would be wary of a person who claimed to be all of these things, or even several of them. It means that his depth of experience is going to be divided between each of these (extremely deep) topics.

One last thing to point out. A SWA is not expected to be the ultimate ninja who knows everything and does it himself. If he does, then he will not be able to maintain his SWA acumen for very long. No. When the SWA chooses the technology stack for a project, you should be able to rent different experts who have spent the time mastering a technology. The SWA doesn’t do that kind of work. He should be busy building models/examples of how these technologies interlock. He should be working with these experts to sift-through the possibilities and assign the heavy lifting where it is appropriate. The PM is then responsible for managing the activity of each of these rent-a-ninjas. He keeps them from running amok or working against each other and silo-ing. He rations-out the glue and scissors.

So, if you are thinking about becoming a software architect, I’d say: get in the habit of studying. Retire your favorite hammer and try a screwdriver and then a wrench. Try each technology, expand your experience domain, so you can speak intelligently and authoritatively about a broad spectrum of competing technologies. Talk with other SWAs, to see how their opinions are similar/different to yours (take notes). It is a lot of work, but only if you want to be good at it.

About Tim Golisch

I'm a geek. I do geeky things.
This entry was posted in Architecture, Career, Professionalism. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s