Architect Commandments

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!

Advertisements

10 Responses to Architect Commandments

  1. Domingos says:

    Great rules, this is the kind of thing that makes this company a great place to work.

  2. […] So, what to do? Should I make an about face and start enforcing standards on all code at all times? I still think developers should be allowed to think for themselves. If they are coming to a different conclusion than I would, it could be a matter of opinion. I also think it’s a matter of culture. If developers aren’t being inspired to do these things for themselves, then maybe there’s more I could do to change that. What was that commandment again? Oh, right. “Show the way”. […]

  3. […] 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 […]

  4. […] Things Every Software Architect Should Know It looks like the Architect Commandments have shown their face again – and this time, they’re in good company! I caught wind today of […]

  5. […] This used to be just the architects, but since I want more contribution from the developers (“Empower developers!”), I recently added all developers to the mailing list. So far, no ones complained about the […]

  6. […] I promise from now on to be more on top of things (“Be at the forefront”, after all). I finally got my “unread RSS entries” count down from 2000+ to a mere 50 […]

  7. […] that this is one of the reasons why your are tending towards a big up-front design, remember the commandment: Empower developers. If you don’t trust your own team, you should figure out why and fix it, […]

  8. […] te ayuda a no perder el rumbo de tus tareas y decisiones. Os adelanto un pequeño resumen de sus seis mandamientos como arquitecto de […]

  9. […] regular company cross-pollination could do for the software and IT industry as a whole. If these assumptions are […]

  10. […] High présente dans Architect Commandments les six qualités essentielles d’un architecte : 1) Se concentrer sur la valeur métier : […]

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: