What is Software Architecture
I have been working as a Software Architect for several years now, but I still find myself unable to answer the question “what is software architecture?” However, I think I can point to some of the factors that can make the architectural work successful.
First: Architecture is about vision, communication and governance. The vision bit is relatively simple: Any company has huge inefficiencies in how it operates. I think the very nature of business is such that these inefficiencies have to exist. The architect(s) job is to find out how to reduce those efficiencies through standardization, technology and automation. That is the easy part. You have to verify continuously that your vision is more or less correct. Then you have to convince others of your vision. If your vision makes sense, that is also relatively easy.
Then comes the hard part: What should people do? The tricky part is to take a vision and then make it actionable, if you will – to transform it into something that people can relate to. At the end of the day, someone has to be able to say “no, we’re not complying with the architecture”. If there is no way of defining non-compliance, there is definately no way of defining compliance, and everything is just handwaving and empty noises.
This means that as an architect, you have to be extremely aware of communication issues. This is important at least at two levels: If you cannot communicate what you mean, there is no way anyone can follow your lead, even if they want to. Second, you have to be humble: Always remember that you are basically powerless. If the developers on your team doesn’t want to implement your idea, it will not be implementated. The architecture is not what you create – it is what ends up in the code: Code is king!
At the end of the day – your final job is not to force anyone to do something, but to describe how it is done. If you can collaborate with others so your description comes fast enough, who knows: You can even change things.
What frustrates me, then, is trying to understand how to do it. How do you attack technical issues in a productive way and how do you communicate and collaborate. But literature on architecture seems to be … well, dumb! Reading SEI: “Documenting Software Architecture”, the authors tell you how you should divide your documentation into views, how views consists of primary presentations, supporting documentation, view templates and whatnot. And almost all literature on architecture is like this: Obsessed with structure, and forgetting content and communication.
Your architecture will not succeed if you write nice, view-oriented architecture documents. As a matter of fact, I think they can be directly detrimental to your success. Are the developers going to read them? Can you really blame them?
The only thing I have found that works is to create a few “architectural cartoons” and bring them to people. Use the architecture documents (mainly the “cartoons”) as basis for two-way discussion about principles and implentation. Pair program with people and try to point out the essensial concepts in the code (and use the chance to learn what is really going on – remember Code is king). Describe what the future may look like, but let people take their time.
In the end: Architecture is slow as molasses. It takes forever to get where you want to go, so all you can do is to ensure that the small steps go more or less in the right direction. And when you get close to your goal, you probably find that it’s not right, after all, the code has changed the landscape. Code is king. I guess that makes those who work with code all the time kings, too. And, fellow architect, I think we have a lot to learn from court jesters.
Comments:
Thomas Flemming - Feb 6, 2006
A norwegian company had an ad in the newspapers where they said they were hiring architects. If you’re looking for a job as an architect (you know, drawing physical houses) it’s a bit annoying. They should at least have said software architects.