Software Architect or Handyman

Businesses need both but they don’t often realize this. First, let’s define a software architect. Later, I’ll share the qualities that I think make for a good software architect.

The software architect

Wikipedia

http://en.wikipedia.org/wiki/Software_architect
“Software architect is a computer programmer or computer manager or expert who makes high-level design choices and dictates technical standards, including software coding standards, tools, and platforms.”

Not so fast, Wikipedia. Agreed, a software architect “is” a programmer but he may not be a manager and need not dictate standards and tools.

In fact, an architect should have vast understanding of an array of technologies and approaches but might work with the existing technologies. There are many right ways to do things.

Microsoft

http://msdn.microsoft.com/en-us/library/ee658098.aspx
Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman definition is:
“Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and behavioral elements into larger subsystems; and an architectural style that guides this organization. Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.”

Honestly I got lost by the end of this and have little to no idea what the heck they are saying.

Martin Fowler

“The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are multiple architectures in a system; what is architecturally significant can change over a system’s lifetime; and, in the end, architecture boils down to whatever the important stuff is.”

Clear as mud…

Now what?

So I guess all we’ve proved is there can be many opinions about the definition of a software architect.
And that’s okay.

So now that we’ve agreed not to agree about the definition of a software architect, let’s just consider my opinion on what it takes to be a software architect and leave the discussion of “what” a software architect is, to people much smarter than me.

The software handyman

The reason for this blog is all to often companies hire a handyman to build their house and skip the architect all together.

This is a problem. Far to many projects fail to be delivered or when delivered fail when under load. All this could be avoided if an architect were involved.

The same reason you wouldn’t use a handyman to build your house without the blue prints of an architect is the same reason you need a Software Architect for your enterprise applications.

Any Software Handyman can become an architect with work. It’s something they must desire and dedicate years toward. Not every Software Handyman wants to. Maybe are happy to support existing applications and write code for new applications according to a specification. We need these guys. They are the unsung heroes of IT.

What it takes…

So, maybe I can’t give you one definition of an architect. Generalized terms and descriptions offer little to the concrete world we programmers live in.

So, dispensing with the BS titles and ego boosting descriptions I’ll simply say what I think an architect must be.

Be experienced

Sounds obvious right. Well it’s not. A programmer supporting an application for 15 years might be experienced but is not Software Architect material based on that experience alone.

A Software Architect must be experienced in a variety of environments with many technologies accompanied with both successes and failures. A diversity of solutions might include client-server, n-tier, distributed computing, and enterprise application integration (EAI) solutions. Failure experiences are as important as successful experiences.

Anyone who does anything significant is going to have failure. I wouldn’t trust anyone who didn’t.

Know surrounding practices

Surrounding practices are all those “things” that bump up against software architecture but are not specifically architectural tasks.

Examples include project management, process methodologies, networking, and testing. If we had a brainstorming session we could easily come up with a dozen more.

Be a communicator

The only thing worse than having no architect is having an Architect who cannot communicate or is a curmudgeon. Instead of not having an architect which leaves room for improvement you have someone in place nobody wants to follow and who could be difficult to remove.

Like the Project Manager an Architect must be able to communicate ideas and listen to his programmers. As much can be learned from other programmers as personal research.

I’ve seen grouchy old men who can’t keep up with the young wiper snappers and it’s imply uninspiring. Don’t be a curmudgeon! Programming is supposed to be fun. Don’t beat your programmers up with “Standards”, encourage them with “Guidelines”.

Study, study, study

An architect shouldn’t have to study anymore. Right? I wish!

At the rate of change technology is taking the architect job is no longer as easy as it once might have been. Today an architect must be a perpetual student, always learning, and always testing out new approaches and techniques.

Whatever technology you are using today is outdated in two years. When reading technology specific blogs and listening podcasts I check the dates. I skip anything over 6 months old and anything over 3 months old I view with skepticism.

The Architect job is a hard hard job and if you don’t want to do the work then that’s OK. Don’t take the job.

I imagine this is the one topic that will piss other architects off the most. We like to feel like we have arrived and all we need to do now is attend meetings, give our blessing and deliver edicts. How nice that would be.

Nope, we have to work our tukisses off more than anyone else because not only must we understand the technology but we must be able to place it into an enterprise context and teach it. When teaching we must know the technology many times more than if we simply wanted to use it.

Be a coder

Yep, not only should an architect have written several man years of code he’d better still be writing code.

As stated earlier, technology is changing at a rapid pace. An architect who is not writing code is quickly outdated and will have his lunch eaten by the next young programmer who “is” excited about technology. He won’t have the experience an architect should have but he will be able to code circles around a non-coding architect.

So pick a project, select a set of project requirements, humble yourself if needed, and get coding. It’s the only way to stay in this game.

Read/write articles, blogs, podcasts… oh my!

There is so much information published every day the even focusing on a narrow subject you can not hope to read everything available or even keep up.

It doesn’t matter. Today’s good architect reads every article and blog he can, has a list of podcasts. When enough time isn’t available cherry picking the most important podcasts is necessary.

Subscribing to news letters is an excellent way to stay on top of the best articles without having to search for them. When you discover a programmer author you respect then find his home page, contribute comments to his articles because this will make you a more critical thinker and you’ll, in time become a thought leader.

You should probably blog once a week because that forces you to continue learning and share what you have learned with the rest of us.

Be a teacher, mentor, thought leader, and be opinionated

This is the fruit of your labor which will multiple when it comes into contact with other programmers and applications.

Be a teacher to all and a mentor to those you see potential in. Chances are someone was a mentor to you. You could change a life. In this industry we do change lives.

Be an opinionated thought leader. We can never know it all and if we try to know something we risk being wrong. There is nothing more uninspiring than an architect who never has a solid opinion and even less inspiring is an architect who never changes or updates his opinion.

So be a though leader and come to some conclusions. When more information is available change those conclusions. Don’t keep it a secret out of fear someone might think you are wrong. Share it and have a bit of confidence.

If you aren’t making mistakes then you aren’t doing anything.

Feedback welcome

Being opinionated means I will sometimes be wrong but I’ve given myself the opportunity to get a few things right. I’m bothered by my “handyman” metaphor because it doesn’t give the deserved credit to the everyday coder. I might completely change that.

If you have feedback, I’m open to learning. You can leave a comment or just email me. I’m not looking to build some large readership base and boost my ego. I simply want to be better tomorrow than I am today.

Thank you. Bob