97 Things Every Software Architect Should Know

August 22, 2008

It looks like the Architect Commandments have shown their face again – and this time, they’re in good company! I caught wind today of a really interesting project that is the brainchild of Richard Monson-Haefel called “97 Things Every Software Architect Should Know”. He’s gathering a list of the top 97 “axioms” that software architects should take to heart. So far, he’s only picked out about half that, and he’s asking for more. I had a look at the axioms, and realized immediately that the Architect Commandments would be right at home on that list. So far, I’ve registered two of my favorites (“Challenge assumptions” and “Empower developers”), and they were accepted for his book!

Now’s you’re chance to contribute, too. Click on the link above, and get involved, or just check out what people have contributed so far.


Dave Packard’s take on the Architecture Commandments

August 18, 2008

I just ran across this classic set of rules to management by Dave Packard, of HP fame: Dave Packard’s 11 Simple Rules. Succinct and well-written, I think they relate well to two of my Architect Commandments: “Empower developers” and “Show the way”. I guess the underlying message is that, no matter who you are, you are part of a team. Negativity hurts you as much as it hurts the other person. To grow tomatoes, you need to give them water and sunlight. Or something like that.

Architect Commandments

August 5, 2008

I created a list of “Architect Commandments” for my small team of software architects here at Sakonnet. I thought it would be an exercise in ridiculousness, much like the lofty company vision statements and company values that every CEO creates and then ignores. But I did it anyway in the hopes that this would create some sort of team spirit for my newly founded group, and maybe give the new architects a common sense of what we were trying to achieve.

Much to my surprise, I found we not only succeeded in those goals, but we have on many occasions directly cited these commandments as a reminder of our purpose. We have made several decisions based on these commandments, and I have used them to guide my team through some difficult issues. Who’d a thunk?

So, here are the commandments that we are using:

  1. Put business value first – this should be a given, and should be obvious. But as techies, we have a tendency to look at our own navel (or at the latest high-tech navel) too often and forget what our end goal is. Decisions should be made based on business value, not based on what we think is cool or elegant or neat-o.
  2. Challenge assumptions – I can’t emphasize enough how important this is. At the bottom of my team’s wiki page is Wethern’s Law of Suspended Judgment: “Assumption is the mother of all screw-ups”. I have been in countless design sessions where we come to a decision based on some insistence that this or that MUST be dealt with (“we HAVE to add 10,000 lines of code to guarantee the user gets real-time updates!”) or really is a PROBLEM (“if we don’t denormalize these tables, that query will take forever!”), only to find out later that our decision was based on really flimsy assumptions (“actually, none of our users use that screen…” “hmm… actually, denormalizing the table only improved performance by 1%…”). As I get older, I’m getting better at figuring out just what the sometimes unspoken assumptions are, and at bringing them out into the open so they can be verified. It helps to actually TRACK the reason you made decisions in the first place, so you can revisit the decision when the situation changes. And it helps to make this commandment explicit so that everyone understands you’re not just trying to be a pain in the neck when you ask “are you absolutely sure about that?”
  3. Empower developers – the developers are the ones doing the real work, and who have the sometimes arduous task of turning your lofty ideas into a virtual reality (if you have the virtue of implementing your own designs, then this commandment applies to you, too). As an architect, your designs need to take into consideration the “implementability” and maintainability of the solution. In my opinion, the responsibilities of an architect should go beyond this to include consideration for the entire work environment of the developers. If there are bottlenecks or roadblocks, remove them. If there are useful tools that can help them work better or faster, introduce them. And lastly, developers are not “resources” that “implement”, they are intelligent, creative and capable. So the architect needs to empower them to express their own ideas and contribute on equal footing, rather than pulling rank to stifle them (see also “Show the way”, below).
  4. Be at the forefront – technology is constantly changing. Every day, we see revolutionary ideas and passing fads, new ideas, and old ideas rehashed. It can be a lot of work to try and keep up. No one person can do it, but generally a good team of developers together can keep their eye on the bouncing balls. An architect needs to always be on top of these new technologies to see where they can be used, and to discuss them with developers (and potential clients). This can also be a double-edged sword. Too much new technology can be a distraction. While the tendency is to want to always try out new technologies, if you change your platform too often, you’ll end up with an inconsistent and untested heap of software. So, the architect should not only be aware of what’s out there, but should go to the effort to filter out the noise and find what is truly useful.
  5. Be decisive – sometimes (actually, very often) it can be worse not to make a decision at all than to make the wrong decision. If you have ever found yourself in a situation where everyone’s twiddling their thumbs while you chew your nails to the last nub worrying about whether you should call your package “com.foo.service” or “com.foo.services”, then you know what I’m talking about. I call these the “Magic 8-Ball” decisions, based on something Scott Ambler once said about using a Magic 8-Ball to make all the decisions on a project (he found that the project was just as successful as any other). Even with the big decisions, there comes a time when you just have to put your foot down and move on. (As a corollary to this, I sometimes say that the role of an architect is to make all the stupid decisions so that the developers don’t have to. That’s what standardization is all about – make the pointless decisions once, only once, and let people get on with their business)
  6. Show the way – this is my least favorite commandment in terms of its effectiveness of communicating what I really mean. What I want to say here is that the role of an architect is to be a leader, but more in the pied piper sense of the term. Generally, a software architect has neither the power nor the morale to just declare rules out of the blue that they expect developers to follow. Instead, the architect must be more like a partner to the developers, or a consultant, and should discuss and negotiate with them best practices, design patterns and so forth. In my experience, there is still a need for the occasional “tough love” approach, but only after everyone’s already on the same page about what standards should be followed. Only then can the architect play the role of the drill sergeant.

I have found these commandments to be much more useful than I had imagined when we first created them. They help capture the many aspects of what a software architect is all about, and at times help us to keep on track. They are also still evolving, and I’ll post any changes as they come. If you have any to add, let me know!