Short answer, of course it matters! It is in fact crucial, and not just for us geeks. Software houses seem to agree, and a strong indication is that ‘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 (do they even know they have “stakes” on it?) and how ‘honest’ the developed software application is to its envisioned architecture.
Here would be a good place for a definition of software architecture, but which one to choose from the numerous that are out there? For me 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 “things that are hard to change” and everything between (or beyond).
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. And 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.
Let’s back up a bit and discuss about 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, it presents it to management, they don’t understand much but they agree as long as it will be realized in their preferred timeframe and then the architecture is presented to the development team. Software is developed aiming to realize 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 really something that matters. And in the long run be both what will make a software application a success and a force for economy of resources when maintaining the application.
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 code monkeys (or artists/scientists/Gods in our own perspective!).
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.
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 a good software architecture description can be proved 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 it always happens. The developers that are currently present may 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. 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 or that the architecture is evolved during development.
Communicating with non-tech stakeholders:
How to 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 having a glitch when putting things on the “bag” of an e-commerce shop might be an acceptable choice, but 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 as a unit the architecture, not only some diagrams! These decisions must be agreed and communicated to the developers.
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 the reversibility, which is desired of course, since requirements seem to change, assumptions could be proved to be wrong and decisions sometimes are not that great. 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" is pretty good advice. However, technologies to a certain extent shape the architecture. For example the different nature of NoSQL databases compared to relational, have effect in the architecture of the application. Isn't the selection of the database model closely related to the nature of the application? And is it not this choice affecting the architecture? And how these decisions will be made? During the crucial process of defining the architecture. So delay the selections of tools, sure, but the selection is very much part of the architecture. Even for the business the selection of technologies plays a big role. Try convincing a car or plane manufacturer to use things other than Excel sheets to hold their data and you will understand what I mean!
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 need 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.
