2 Years ago today, I wrote about centralized architecture groups in organizations.  A few months after I wrote that post, I was commissioned to write a whitepaper about enterprise architecture by a local boutique consulting firm.  The idea of software architects has been on my mind a lot lately.  While I've been selling myself as a Big Swinging Developer for the past several years, I recently found myself in an architect role accidentally.  I'll go into some specifics in the next post, but first I want to throw out some of my thoughts on software architecture in general and software architects in particular.

WTF is Software Architecture?

It's one of those terms that seems to mean something different every time you hear it.  In the realm of consulting it often translates to "the most expensive PowerPoint slides you've ever seen".  My personal definition is:

"software architecture is the collection of hard-to-change decisions about a system" 

Decisions like whether to use an ORM, or an Enterprise Service Bus, or how security is going to be handled.  These aren't impossible-to-change decisions, but if you've ever been on a project where something of this magnitude was either overlooked or chosen poorly, you know that this kind of mistake threatens to sink a system.

What Does an Architect Really Do?

That depends on two things: The individual and the organization.  The problem with the title "Software Architect" is that there isn't a strong connotation of what will be delivered.  A "Software Developer" better deliver software.  A "Graphic Designer" better deliver designs.  A "Software Architect", however, has no corresponding delivery requirements.  This is left largely to the individual and it's then often left to the organization to decide whether or not to tolerate what they do all day value the role.

In the past 5 years, I've been fortunate enough to work with the full spectrum of architects and the full spectrum of organizational attitude.  My favorite type of architect is one who has a good grasp of how software fits into an organization, the technical ability to address the challenges, and feels a responsibility for the success of the developers who will be implementing the vision.  Former colleague Mike was a great example of this.  He know his stuff, had strong opinions on the things that were important to him, and always provided a reference implementation to show that his design was practical.  My least favorite type of architect is one who generates nothing but documents (PowerPoint being a favorite), dictates "how things should be", and then blames the developers when the vision turns out to be impossible or useless or both. 

But architects don't exist without an environment in which to practice, which is why organizations are almost as accountable for architect quality as the individuals.  The quality of the environment is more easily determined by what it won't tolerate than by what it encourages.  Sure, you want a place that encourages quality work and personal accountability, but that's not enough.  What separates the good from the bad is that the bad organizations will tolerate (or even value) the Big Talkers who spend days preparing for a presentation without ever once vetting the practicality of what they're proposing.  You probably know who I'm talking about, the folks who will show you super-complicated diagrams of their Service Oriented Architecture but can't answer a single question about how to version or end-of-life any of the listed services.  Casting things into "good" and "bad" is a little simplistic, though.  There are really 3 types of environments:

The Consciously Good Organization

These are the folks who have their act together.  Somewhere along the way, they've committed to creating first-rate systems.  If you find yourself in an environment like this, they'll likely have a really good architect who you can learn a lot from.  If you're brought into to be an architect in this type of organization, you are being brought in explicitly for the role and you'll have a good idea of what it means to succeed.  There is money to be made in a consciously good organization since they tend to pay for quality, but note that the competition for the role will be fierce and you'll have to be really good to land the gig.

The Cluelessly Bad Organization

These are folks who want to be good, but don't know how.  Or maybe they don't even know that they want to be good, but they have a feeling that things could be better and are receptive to ideas on how to improve.  Honestly, this is my favorite type of environment.  There is a lot of money to be made in these types of organizations because they are often leaving so much of it on the table with bad systems.  Not only is the money good, but the work will be very pure in that you'll spend much of your time showing them how things can be better and then implementing it.  If you are correct in your analysis and solid in your implementation then your work will easily pay for itself and you can continue until you've built them into a sustainable technology powerhouse.

The Delusionally Bad Organization

This is the danger zone, because these folks think they're good but they aren't.  Remember when I mentioned that you can more easily determine the quality of the organization by what they tolerate?  This is where that little nugget comes in handy.  The delusionally bad organization does some things well (and will point them out as evidence that they're "good"), but they tolerate mediocrity to the point where the good stuff almost doesn't matter.  The way you can tell the delusional from the clueless is that the delusional will actually know a lot about what it means to design and build first-rate systems . . . but then they won't do it.  Instead of building good stuff, everything turns into a messy collection of compromises that's explained away by factors beyond their control.  The good news is that there's money to be made in this type of environment because they will, in fact, need help.  The bad news is that they will make you earn every freakin' penny of it.  The work isn't really the work, the work will be trying to get things done in an environment that thinks it's okay even while things are crumbling around them.  You'll suggest a way of doing something, get told that it's not necessary, and then see the negative effects of not having it . . . all before lunch.

Is an Architect Role Right For You?

As you might imagine, the job of software architect isn't for everyone.  One of the best programmers I know has no desire to be an architect even though he certainly has the technical qualifications.  So how do you know if the position is right for you?  I think that before even attempting the role, you need the following:

• Wide technical experience with some pockets of depth – you should be able to build everything yourself, even though you won't.
• Network operations or sysadmin experience.
• Defensible opinions on how software should be built.
• The ability to convey complex ideas in simple language.
• Ideas about how software and technology can make organizations more successful.

Have I missed any big ones?  If so, leave a message in the comments below!