It is how different parts/pieces (and even dimensions like hardware, software, applications, data, operational/system, legal and others) are entangled, tied, together as a a software system to reach a business goal.
It is formed by a group of decisions that define the structure of the application and are difficult to change later in terms of effort, time, and cost.
Those decisions are strategic and have a long-term impact.
Basically, things that you drag on over time and that are difficult to change later, unless with great effort, either in terms of cost or time.
Let’s give some examples:
If I choose to implement a certain feature as a function rather than a class, that’s a decision that doesn’t affect the structure of the application. I can refactor it without major issues. However, if I decide to make an application more scalable to handle many more users, I won’t just need to do a small refactor, but I’ll have to change several parts of the application and, if necessary, even other related applications to make it possible. So in this case the scalability of the system is an architectural concern.
Here’s another example: if I choose to use one library over another for certain functionalities, say for string manipulation, that change doesn’t require a huge effort in terms of time and cost. But if I decide to make a system or software extremely secure, because I’m working on a top secret military or financial project, and so security is the most important attribute of the software, that will require much greater effort in terms of cost and time to change, if it was not designed for it. So in this case security is an architectural concern.
Designing the right architecture for an application isn’t simple. It requires a lot of tradeoffs.
In fact, most decisions are compromises. Someone once said that the first law of software architecture is: “Everything in software architecture is a trade-off.”
You need to weigh the pros and cons of every decision and take those decisions that best satisfy the architectural attributes that was defined as the primary or as the most important for the application that you’re building.
For this reason, it is essential to first define which architectural attributes are most important for the software being developed.
Is data integrity more important than scalability? Is security more important, or is availability the most important for the business goal? Is maintainability more important than configurability? How important is performance? How important is consistency?
So, for example: If scalability is the most important attribute for the software I’m building, I’ll need to make decisions that maximize that attribute. So I will choose the tech stack, or the pieces of software, or hardware, that make maximize the scalability or that makes me be able to that without effort.
This means you may compromise other attributes of your system, or they won’t be optimized.
For example, if security is the primary architectural attribute of the software I’m developing, there will be trade-offs with performance; performance may degrade or not be fully optimized.
In the end, the right architecture for software is a set of decisions that maximize the architectural attributes to achieve the business goals. The right architecture enables the business to succeed (by having an impact on people’s lives) and to make money (either directly, by making it easy to add new features, or by minimizing the cost of maintaining it).
There is no architecture that is always the best in every case, for every domain (any type of business), and in every circumstance.
It all depends.
So how do I design the right architecture?
You should always start with a primary analysis of the business requirements, to identify which architectural attributes (security, scalabilty, availability, performance, maintenance, etc..) best satisfy those business needs (maybe using the utility tree tecnique or workshops with different stakeholders on the project, etc..). Than you must know that you can’t have it all, so you take the 3 to 7 most important ones based on how they are critical for the business and how hard they are to implement.
Once those 3 to 7 attributes are identified, start working on them:
1) write down (on a board, on a paper, on your hand, wherever you want) the pro and cons of all available options that are on the table to implement the solution and
2) choose all the components (technology stack, libraries, additional software, external systems, third part systems, etc.) and choose the structure of the application code that best fulfill the architectural attributes, and consequently, the business objectives.
These are tips that can help you towards the right architecture for your project.
What you should never do is start by writing code without an architecture, accumulating technical debt upon technical debt, with a huge cognitive load, only to end up scrapping the software because it has become unmanageable, and the cost to “fix” or restore it has become enormous.
Leave a Reply