Ruminations of idle rants and ramblings of a code monkey

What is a software architect?

Idle Babbling

I had this discussion with someone recently and it’s really gotten me to thinking. There is a reason that I don't use that term much to describe myself ... it is so undefined, overused and inappropriately used that, in many ways, it has lost much of its value as a title (to me at least). I cannot even begin to count how many folks I've come across that promote themselves as architects but that I certainly wouldn't call an architect. For some, it's because they don't have any technical depth but are really good at regurgitating marketing material and BS. And because they have no technical depth, they often come up with "architectures" that are very difficult to implement properly because they have no idea what it takes to actually make it happen in the real world. Unless, of course, you write marketing material. For others, they are good coders and, perhaps, could be considered a solution architect (or lead developer) ... but they don't have the vision to see outside of a narrow problem or the short term. For still others, it's a political play in the rough and tumble world of corporate politics. Finally, you have those that are super-smart and in love with building things as complex as possible, using (what they perceive to be) all the latest and greatest tools and toys. If there is a technology that they want to play with, they will make it fit into the project, regardless of whether it actually adds any real value.

Yes, there are some that I would truly consider software architects. They are a rare breed ... they have deep technical knowledge and skills; they can code in the trenches with some of the best developers. But they have something more. First, they understand deeply business priorities and can weight technology choices to meet those business priorities. It's often very hard to get developers to understand this and vocalize it; it was a challenge anytime I did an Architectural Design Session. Yes, they will look at the latest and greatest ... but only adopt it when it actually makes business sense to do so. They also understand that you need to balance priorities and have to make certain trade-offs based on those priorities - for example, sacrificing a little performance in return for higher productivity and quicker turn-around time. Or the other way; it depends on the business priorities. For example, the guys that build have very different priorities than the guys that do internal web apps and they will (well, should) make different decisions based on those priorities. Second, they have a "Big Picture" view. They know how the different moving pieces of any even moderately complex software system (should) fit together. I remember once, at an internal Microsoft training event on software architecture, a talk by the original architect of Microsoft Transaction Server (MTS) - which has morphed into different names over the years but is still a core part of Windows. He said that architecture is all about "HST" ... "hooking shit together". In the software world, it very much is. Third, they take the long-term, practical view of development ... not just what we need to do today, but where we are going tomorrow. This is always in flux, but it is a core piece of how they look at the world. Finally, they are also pragmatic ... what can be done within the constraints that we have and with the resources that we have? They know that all things are possible, given enough time, money and resources. It may take building a new operating system or web server or middleware piece from the ground up, but it would be possible. Just not very pragmatic. Unless, of course, that happens to be your business.

I have met folks that meet the above description but there are very, very few of them. I've met far more that fit into the first paragraph. And no, I will not name any names.