In this series of posts, I will introduce you to the most popular software architecture types. But before we delve into the most common variants, let us talk about software architecture itself.
What is software architecture?
It is tough to write simply for such a complex topic as software architecture but let me try my best.
A software system is made up of individual elements. Elements could be databases, application servers, message brokers, load balancers, etc.
Each element has its properties and characteristics. Between these elements, there are relationships.
The way we structure these elements and their relationships, we call software architecture.
By defining such a structure, we aim to gain some benefits. Quality attributes define and describe these benefits, and it is essential to remember that they are not business logic related.
Software architecture is the skeleton of your application. Once you start implementation, it is tough to change it, so the right decision for architecture is crucial in the early phase of the project.
Quality attributes
Though quality attributes are not functionality requirements, they mainly arise from the functional requirements.
By defining requirements for a software product, the business aims to enhance some competitive advantages.
In the best-case scenario, quality attributes gathering should come from those competitive advantages.
A simple example. Back in the days, I worked in a company that wanted to develop a new retail system. The business analysis showed that most of our main competitor’s customers do not like their system because it was always online. The user couldn’t even check product stocks in case of an internet outage.
For our new product to be competitive in the market, we had to aim for a competitive advantage. Our system had to work offline during internet outages and sync all recorded operations when the internet is back.
We, developers, translated that requirement into the availability quality attribute.
Sometimes quality attributes don’t come from requirements. Some quality attributes are enforced by constraints. Constraints could be different, from the dev team’s experience level to government regulations.
And last but not least, quality attributes should be measurable and testable.
Some of the most popular quality attributes:
Availability
It defines to what level the system is available to perform its tasks. Availability expands on the notion of reliability. Systems with high availability tend to be resilient to faults and errors (well, to most of them). High availability systems implement methods for fault detection and recovery.
Modifiability
Modifiability defines how well a system can adapt to changes. Technologies change, business requirements change. High modifiability software should be able to embrace new changes by reducing change costs and risks.
Interoperability
No system can live in total isolation. Interoperability quality attribute measures to what degree a software system can “communicate” with other software systems. Systems with high interoperability tend to have very well defined interfaces and implement widely accepted standards and communication protocols.
Security
The security of a system could be viewed from three different angles.
Confidentiality – is the data well secured from users who don’t have the right to access it.
Availability – is the data available when needed.
Integrity – is the data well secured, so tampering and deletion are not possible.
Performance
Well, performance is all about time. This quality attribute aims to put an upper execution time limit to the system’s tasks (no matter if the user or internal mechanisms initiate them).
Testability
Testability defines to what degree a system can be tested. How well business and technical requirements can be simulated, observed, and analyzed. High testability systems provide a high level of isolation and abstraction of its modules.
Usability
Usability is about how easy it is for the user to perform tasks in the system.
Sound simple but believe me, usability is a real pain. Usability is even bigger pain when we talk about systems with very complex business logic and processes.
Every user comes with his own previous experience and opinions. That’s why usability is often based on compromises for the greater good 😊.
For more comprehensive list you can check this.
What is the difference between software architecture and software design?
While software architecture aims to define the structure and relationships of the different system elements (considering all the present constraints), the software design focuses on their specific implementation.
If a software architecture specifies that we will have microservices with async internal communication, the software design will define how this will be implemented.
Do we use RabitMQ or Mass Transit, or something other? What is the format of our messages? How will the data models reflect the bounded context we have defined? The software design answers all these questions.
Architecting for performance (example)
Let us see how a quality attribute requirement affects system architecture.
We have a potential client who wants a very fast (performance quality attribute) reporting system.
The client should make decisions fast so that the reporting system’s speed is a competitive advantage for his business.
Currently, the client has two different systems. He queries them when he needs some data (using their operational databases, which degrade performance additionally) and combines the extracted data in an ugly excel report.
Back in the days, that approach worked perfectly for him, but now, this is becoming a bottleneck when his business is much bigger.
Our company “Drink beer and code Ltd.” receives invite to solve the problem.
After a complete analysis of the case, the developers come with the solution. According to the research, they think that a report’s average execution time could be lowered to 1500 ms (yeah…).
At this stage, dev team will not change current systems. Either way, they work well to meet the customer’s needs, and he doesn’t want to change them.
The Dev team plans to deploy a new SQL Server. The server will have a new analytics database and two replicated copies of the other systems’ operational databases.
Operational database replication is event-based.
A worker service extracts the data from the replicated databases, transforms it appropriately for the analytics database, and loads it into the analytics database.
The analytics database design is structured and optimized for the format of the needed reports. Querying the database will be very fast.
Finally, we have a reporting application reading the data over the analytics database and visualizing it in beautiful tables and charts.
Summary
Even with that oversimplistic example, we can see that we have introduced new elements and relationships between them to meet the desired quality attribute metric.
We also faced the constraint that the old systems enforced over our technical decision.
But in the end, we achieved the desired performance and that enhanced our client’s competitive advantage.
