What is the purpose of architecture in software development? Where does the role of the architect stop and the developer begin? In an uncertain domain (and who doesn’t work in one of those these days) what is the value in spending time upfront designing a grand architecture?
Before attempting to answer these questions, let’s go back to the beginning. The earliest reference to what makes good architecture goes back to Roman times. Vitruvius believed in the three principles of firmitas, utilitas and venustas. Here are common translations.
firmitas – firmness, durability, strength, truth, constancy, stability, endurance
utilitas – useful, utility, expediency, advantage
venustas – loveliness, comeliness, charm, grace, beauty, elegance, attractiveness
How does this translate for modern software architecture?
Do not mistake the concept of firmitas with rigid, fixed, unchanging or constant. A good architecture is strong and robust. A great architecture survives the ever changing environment in which it finds itself. For traditional architects, that means ability to adapt to changing regulations, fashion and use of the building. In software change arguably comes faster. New technologies, rapidly evolving customer needs and changes to overall business focus.
The firmitas principle raises a simple question. What is the Software Architecture? What is it that can remain unchanged when everything is changing around it? Architecture isn’t the code or the implementation details. Those need to change too often. Architecture then becomes about the boundaries. There is a nice analogy of walls, doors, stairs etc. with the contracts that exist in a service-orientated architecture. Allowing rooms to be easily closed for redecorated without impacting other areas of the building is important.
firmitas also means a great architecture needs to be honest. It can’t just look good on paper. It is firmly grounded in reality. The only true test of the firmitas principle is how well the architecture lasts in the long-term.
An architecture needs to be useful. The second principle looks to ensure your architecture delivers value. Useful to the people using the finished product. Be it software or a building. Also useful to the builders/developers. It is clear with a traditional architecture needs to be useful for the people using the building. With Software it is not so straight forward.
Who is it that the Software architecture needs to be useful for? One aspect of utilitas is about delivering competitive advantage to the organisation paying the bills. However it can be argued the users of the software should be unaware of a software architecture. There is of course the design of the user experience but I assume that is outside the scope of Software Architecture. So that really leaves the developers who work with the software day to day.
The utilitas principle changes the relationship between architect and developer. Rather than the architect being the design authority, instead their focus becomes one of attending to the needs of the developer. Their architecture may well be beautiful and be able to stand the test of time, but if it provides no utility to the developers who must work with it day to day it is worthless.
Having used the first two principles to narrow down the focus of Software Architecture to defining the boundaries and in so doing making the lives of the developers easier. Finally we come to the aesthetics of the solution. While the need to focus on the charm of a building is clear, perhaps it is too easy to ignore this aspect when considering the virtual world of software.
Given we’re asking developers to spend most of their working lives working within these architectures, it is only fair I believe to ensure they feel like nice places to work. The effect of an ugly, repulsive architecture on a team is clear. Fear and loathing lead to low morale. So while beauty is in the eye of the beholder, in our case the developers again become the judge of the aesthetic qualities of the chosen Software Architecture.
Reference
http://en.wikipedia.org/wiki/Architecture
http://www.britannica.com/EBchecked/topic/32876/architecture/31866/Firmitas
http://flowchainsensei.wordpress.com/2013/10/12/the-antimatter-principle/
gothandy 