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 in which 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 in 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 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, 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 with the aim 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. Sound 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 really be something that matters. And in the long run it can both make a software application a success and a force for an economy of resources when maintaining the application.
So how are we to go about defining what software architecture is? 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 so. It brings together the assumptions, expectations, and agreed upon 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:
There's lots of legacy code and many decisions and trade-offs were made (and shortcuts were taken) while developing, as always happens. The developers that are currently present may never have 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 should you discuss the development decisions with not so technical people? How will you 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 that has 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, and metaphors are invaluable tools during the architecture discussion and decision-making process - for me, they are, as a uni,t the architecture, not only some diagrams! These decisions must be agreed upon 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 reversibility, which is desirable since requirements seem to change, assumptions can be proven 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, technology, to a certain extent, shapes the architecture. For example, the different nature of NoSQL databases compared to relational can affect 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 that affects the architecture? And how will these decisions be made during the crucial process of defining the architecture? So you can delay the selection 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 of software architecture: Mr. Fowler stated that “Architecture is about the important stuff. Whatever that is.” As I understand it, in its essence this is a statement about communication, the important stuff that 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 the important stuff is, communicating the important stuff, and building while having the important stuff in mind. 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 on Youtube, Software Architecture vs. Code, at the GOTO conference.