In the previous post I talked about software architecture and software architects in general. In this post, I get into some specifics along with recommendations if you find yourself in a similar situation. It is important to note that the advice that follows is for people who want to build good software in a good organization that supports your effort. If you feel (or find) that you don't have the support necessary to get your architecture adopted, you may want to read Terrance Ryan's book Driving Technical Change
Have an opinion
If I could give only one piece of advice to a software architect it would be to have an opinion. Wishy-washy architects who speak vaguely in buzzword driven platitudes are the worst because they are inherently un-fixable. You can fix "wrong", but you can't fix "unclear". Since there are so many possibilities with software the only way you can achieve clarity is through having an opinion and being able to describe/defend it. As an example, it was important to me that the system I designed be asynchronous from the beginning since I knew that we'd need to integrate with some slow external systems. The opinion I formed is:
When the user clicks Save, their part is done. The system should allow them to keep working and then notify them (if necessary) when the processing of their action is complete.
This led to a bunch of design decisions that wouldn't have been nearly as clear if I had a generic "the system needs to be fast" bullet point.
Be wrong early
You have your opinion and you start discussing it with others – your peers, your manager, your team, or whoever else will listen. Be prepared to find out that you're wrong. "Wrong" can come in a bunch of flavors: You've chosen a technology that's going to be difficult/impossible to get deployed, you've designed for a problem that doesn't exist, you failed to consider something that's critical. The "be prepared" part means listening to feedback and watching reactions to find out that something could be wrong even if you're not being told exactly what. It also means separating out general push-back from specific problems, especially from developers. I once found myself in a surprising discussion with a developer over the design of my auditing strategy because he was worried that the database administrators wouldn't handle the data growth well. Notice that that's a general fear that has less to do with the system (after all, auditing requires data growth by definition) and more to do with the environment. We ended up keeping the design after discussing the various ways in which we could address data growth both with and without database administrator support.
Don't ship PowerPoint
If you're an architect, there is a strong possibility that you'll need to put your thoughts and designs into a slide deck to present to others. This is a great exercise as long as you don't see it as your final deliverable. The architecture I found myself designing needed to support several business units and perform a wide range of functions. I had my opinions, I had my designs, but I didn't consider the architecture complete until I'd built at least a prototype. In this case, that actually meant building the first module and I can tell you that things changed substantially from the time the paper design was done to the time we completed that module. Even if you can't build an actual portion of the finished product, you should at least build a representative example of what you've designed and demonstrate that it exhibits the properties for which you've designed.
Know your environment
In the opening paragraph I noted that the advice was for people who wanted to build good software in a good organization. If you're reading this blog, you probably have an idea of what "good software" is (i.e. meets user needs, can be extended, etc.), but you may not know what I mean by "good organization". The cornerstone of a good organization is honesty and most of the organizational problems I've encountered stem from a lack of honesty – anywhere from people kidding themselves to folks outright lying. In the context of development and architecture, you'll know you're in a good place if your opinions are met with open discussion and debate. It's surprisingly satisfying to have someone show you that you're wrong and then watch your design improve as you hash out a better solution together. You'll know you're in the wrong place if your opinions are met with silence, unproductive bickering, or passive aggressive avoidance. If you find yourself in such a place, then once again check out Driving Technical Change
Comments are closed here.