Or why non-developers should care about good software design, even if they can’t see it.
For many years, the term "software architecture" has been the subject of heated debate in the developer world. Some regard the terms "architecture" and "architect" very highly while others feel there’s some excessive grandiosity to using them.
Regardless of terminology, most developers agree that architecture plays a vital role in their work, despite the actual definition of what software architecture is being elusive and a point of contention.
Now, I’m not going to throw my two cents on the definition of software architecture here, that’s besides the point I would like to make. What I would like to focus on today are the following three reasons for the value of investing in good architecture that I consider to be of utmost importance:
- Flexibility: Good software architecture applies constraints where necessary but remains malleable, therefore enabling your software to grow with time.
- Efficiency: Architecture that is modular allows adding new features quicker and cheaper.
- Communication: Working out software architecture brings everyone on the same page.
Combining all of these three items will differentiate a dev team from being standard to being a 10x team. Read on to find out why.
Flexibility
Since the term "software architecture" has the word "architecture" in it, you’d be tempted to think it’s somewhat similar to architecture related to buildings and mechanical systems. This is true to an extent, in that software architecture is concerned with the foundations and the inner design of a system.
However, there’s one crucial aspect that makes software architecture so different from its physical world counterpart. When building with atoms, the laws of physics and the properties of building materials are perfectly predictable. When building with bits on the other hand, we’re dealing with an ever-changing set of business requirements and an ever-evolving world of technologies and programming languages.
This inherent property of the software world is something that needs to be taken into account when architecting a system, which brings us to an important conclusion:
Good software architecture is flexible.
While a system’s architecture can be described as a set of constraints that facilitate its organization and delivery, it is crucial that it retains sufficient flexibility. This way, the solution can be adjusted to business or technology changes with the least required effort. What’s interesting (if not paradoxical) is that this architectural flexibility makes your system more robust.
Because of this, in the software world blueprints are less like static pieces of paper and more like an ever-changing city seen in stop motion.
This actually brings us on to the next point.
Efficiency
Technologies evolve indefinitely, but since that’s a property of software in general, the solution you’re paying for should evolve too. Software is never really “finished” because you always want to add improvements and new features, thus providing more value to your customers. You have to respond to user feedback and adjust the system so that it matches their needs and expectations. And you better do that quicker than your competitors.
Now that’s going to be a hell of an effort with a badly architected system. Of course, users don’t see your architecture, but they do feel the effects of value being delivered swiftly.
Good software architecture allows adding new features quicker and cheaper.
Since I mentioned costs you may be guessing that high-quality software architecture is somewhat of an investment. It’s true it may be expensive, but cheap architecture is going to cost you even more eventually. Same goes for the time aspect: while investing time in proper architecture may incur additional time in the interim, it will save you loads of time in the long run.
Why is that so? Even though there’s no one best approach to architecture, a common quality of good software design is modularity, or what’s known as the separation of concerns. Roughly, this means that your system is divided up into more manageable chunks.
From a developer perspective, smaller chunks are easier to code, to test, and to change over time. This is because we’re working within the limits of a module, so we don’t need to know or care about the code outside of it at that particular point in time. We can quickly find our way around the code and do the job without the risk of negatively affecting the rest of the system.
In contrast, poor separation of concerns leads to a situation where the solution becomes massive in terms of interdependent lines of code, and therefore much more complex and difficult to maintain. New features or changes in one place may require similar work elsewhere in the solution. What’s even worse is that these adjustments are likely to result in unpredictable bugs that need to be addressed. The result is a snowball effect of time and costs required to improve your system.
Moreover, proper modular architecture has another invaluable benefit.
Communication
Focusing on architecture requires close collaboration between developers and the different stakeholders of a project. While the stakeholders may not have a technical understanding, the abstractions within the software architecture serve to facilitate communication among stakeholders and developers, thus making it easier to discuss and negotiate the project. This is because the domain is reduced to a smaller problem space.
In other words then:
Software architecture brings everyone on the same page.
Different stakeholders may have different concerns about the solution in question, e.g. its usability, quality, the duration and cost of the project. Architecture takes into account all of these concerns, so that both the development process and the final product become as predictable as possible.
For the very same reason, software architecture encourages formulating a shared understanding of the solution’s design. The close collaboration between business and tech actors allows to precisely define all of the design requirements for a software product. This in turn makes it easier for the developers to meet these requirements, as well as provides means to measure the project’s progress.
Again, proper modularity is the key to success here. For example, a common way to structure software architecture is to have small modules limited to narrow functionalities. Due to reduction of the problem space, it’s so much less of a cognitive load for both business stakeholders and developers to reason about all the possible use cases, including exceptional paths in the process handled by the various modules.
Summing up, I believe some of the top reasons why you should care about software architecture are the following:
- Proper software architecture improves communication and eases formulating the solution requirements, resulting in smoother project delivery.
- Good software architecture allows you to add new features and make changes much quicker and cheaper.
- When done right, software architecture is flexible enough to make your solution resilient in the face of ever-evolving business requirements and an ever-changing technological landscape.
I hope these insights will encourage you to put the due diligence and attention to architecture in your next software projects so that you can make the most out of technology for your business.
Let me know if you have any questions or thoughts in the comments below.
