Short answer, of course it matters! It is crucial, in fact, and not just for us developers. Software houses seem to agree: ‘software architects’ and related job titles are paid handsomely. What I doubt is how the software architecture is communicated, if it is considered important from all the involved stakeholders and how true the developed software application is to its envisioned architecture.
What is software architecture?
This would be a good place to define software architecture, but which definition to choose from? All of them are probably correct from the perspective and the context they were produced. From IEEE’s “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” to Mr. Martin Fowler’s “the important stuff” concerning “internal quality”.
For the point I want to get across, the one that seems to fit the best is that a software architecture provides a common enough understanding of the system and allows us to reason about it, decide on the trade-offs and keep us on the right track while developing.
I said common enough, because as Mr. Fowler has mentioned “software diagrams are an imperfect representation of a shared understanding between stakeholders”. Imperfect yes, but good enough. In fact for different stakeholders, different diagrams or more accurately, different abstractions, of the software architecture must be used for reasoning based on this common understanding.
How are software architectures defined?
Let’s back up a bit and discuss how I believe most software architectures are defined and used in practice at different companies*. The software architect has a vision of how the application should be and presents it to management. They don’t understand much but they agree a- s long as it will be realised in their preferred timeframe. Then the architecture is presented to the development team. Software is developed aiming to realise this architecture. A year later the codebase looks nothing like the architecture, the architect probably already left and the architecture found its best use in the least sexy slide of the marketing team for the project. Sounds familiar?
It does not have to be like that. With some discipline, good communication and to be honest – a bit more time up-front, software architecture can be something that really matters. And in the long run it can be both what will make a software application a success and a force for economy of resources when maintaining the application.
Finding a definition
So how to go about defining the software architecture? And who should be involved? My concern is how the architecture will be represented and how it will be communicated to different groups. And it is not only the resulted architecture that matters, but the process of generating the software architecture. Dwight D. Eisenhower said “plans are useless but planning is indispensable”. In software, architecture is certainly not useless but its process is equally important, if not more. It brings together the assumptions, expectations and agreed trade-offs of all stakeholders in a software product from the business to the nitty-gritty coders (or artists/scientists/Gods in our own perspective!).
Different levels of abstraction
The best approach in my opinion, is to produce different abstraction levels** of the architecture which will be mapped to the interests and technical depth of the involved stakeholders. This will serve the purpose of the architecture which is to give a common understanding between the stakeholders, about which they can reason.
The process and outcome of a software architecture helps us figure out what Martin Fowler’s “the important stuff” is, to communicate the important stuff and build software with it in mind.
I will attempt to show the value of the architecture (and the process of its definition) by providing a few examples. Let’s consider different scenarios where good software architecture can be golden.
A new developer joins the dev team
Lots of legacy code, many decisions and trade-offs were made (shortcuts were taken) while developing, as always happens. The developers that are currently present may have never touched parts of the codebase. How are we going to help the new dev get on board? How long will it take to become productive? With a good description of the architecture, it is (relatively) easy. A few UML sequence diagrams for the main control flows of the application, a picture with the layers of the application and mapping of the “diagram shapes” to the part of the code (e.g., packages) will help with understanding how the application works, where to search in the codebase and even what scenarios to run for a given issue. Of course it is extremely important to make sure that the code is sticking to the architecture. It is also important that the architecture is involved during development.
Communicating with non-tech stakeholders
How can we discuss the development decisions with not-so technical people? How to decide on the trade-offs? Mr. Bob Martin says that the architecture of an application should “scream what the application does”. And I see the merit in it. The decisions that shaped the architecture show what is important for the application. For example an application with a bug when putting things on the “bag” of an e-commerce shop might be an acceptable choice. However having a glitch while helping a space vehicle to land? Not so much. Use cases, pictures, UML diagrams, metaphors are invaluable tools during the architecture discussions and decisions – for me they are the architecture, not simply some diagrams! These decisions must be agreed and communicated.
Selecting tools and frameworks
This is a tricky one. Mr. Martin advocates that we should separate the architecture from the technologies and tools. It has to do with how easy it is to change decisions make, which is desired of course. Requirements do change, assumptions can be proven wrong and poor decisions can be made. Selecting tools and frameworks often makes things less reversible, or costly to reverse, which in turn may increase the complexity of the system. So when Mr. Martin says “the purpose of a good architecture is to delay decisions, because then you can make decisions with more information” – it is pretty good advice.
However, technologies shape the architecture to a certain extent. For example the different nature of NoSQL databases compared to relational databases have an effect in the architecture of the application. Isn’t the selection of the database model closely related to the nature of the application? This choice affects the architecture, along with how these decisions will be made. So to delay the selections of tools is possible, but the selection is very much part of the architecture. Even from the business perspective, the selection of technologies plays a big role. Try convincing a car or aircraft manufacturer to use things other than Excel sheets to hold their data. You will understand what I mean!
The important stuff
Here is another definition for software architecture: Mr. Fowler stated that “Architecture is about the important stuff. Whatever that is.” As I understand it, in its essence is a statement about communication. The important stuff needs to be communicated between involved parties. From business and sales all the way to devs and ops, architecture in different abstraction levels, shapes, and forms gets people to discuss, decide and implement what is expected by all stakeholders. It is figuring out what are the important stuff, communicating the important stuff and building while having in mind the important stuff. And when it is done like this, the architecture really matters.
* Based on what I see and read in different blogs, books and portals
** Defining a software architecture on different abstraction levels is a concept proposed by few people and one of them (most recent to my memory) is Mr. Simon Brown. I rather enjoyed one of his presentations I viewed in youtube Software Architecture vs. Code in GOTO conference.