IT and software development in general have been dominated by Software Architecture. It simplifies and understands the management of solutions within your company. As for the software developers working on the project, it is also helpful, whether it is a web app or a mobile app, that there is accurate and clear communication between the rest of the team members and the software developers.
What is Software Architecture?
The term “Software Architecture” refers to a set of system structures composed by elements (objects, threads, logicals and physicals, classes, components, etc.) which have properties that can be seen from an external vantage point, as well as their relationships with each other.
As part of the architecture, you should:
- Display the system’s structure but hide its implementation details.
- Implement all scenarios and use cases.
- Take into account the needs of several stakeholders.
- Ensure both quality and functionality.
Listed below are the Key Principles of Software Architecture for Better Design
Solid Principles
In addition to software development, the SOLID principles also apply to system architecture.
Let’s look at…
1. Single Responsibility Principle
It is recommended that a capability (such as a service, module, or API) have no more than one purpose. The users are better informed of the intended purpose when the responsibilities are narrow, leading to fewer errors.
2. Open-Closed Principle
Essentially, this principle suggests that extending a system behavior is preferable to changing it. A key component of an application’s longevity is its ability to adapt to new functionality with minimal changes to existing components, even though anticipating changes ahead of time is rarely a good idea (as it can lead to bloated designs).
3. Liskov Substitution Principle
Essentially, this refers to derived classes being interchangeable with their bases, but how this applies to Distributed Architecture is that two services interact effectively when they have a ‘contract’ that defines inputs/outputs, structures and constraints between them.
In other words: there should be no changes to the correctness of a system in the case of two distributed components with the same contract.
4. Interface Segregation Principle
Clients should have fine-grained interfaces/contracts so that calls aren’t dependent on functionality they aren’t using. This is in alignment with Single Responsibility: when we break apart interfaces, we promote composition through role separation, and decoupling by breaking down unneeded responsibilities between derivative modules.
5. Dependency Inversion Principle
There should be no dependency between high-level and low-level modules; they should both be abstraction-based. The same applies to abstractions and details, the latter should depend on the former. Thus, the concept of interface abstraction is applied to software components and layers at the higher and lower levels thereby removing the dependencies between them.
The Least Principles
The ‘Least’ principles are grouped together due to the naming convention:
-
The principle of Least Astonishment
The principle of least surprise (or least astonishment) states that solutions or approaches should not surprise anyone knowledgeable about a particular subject when they encounter them for the first time (the audience may differ e.g. end-users, developers, testers). A more practical definition is that the principle aims to reduce learners’ learning curves by leveraging their pre-existing knowledge, so anything with a high degree of predictability should be redesigned.
A domain model is a way of keeping track of all aspects of architecture from component naming services all the way through to visualizing user interfaces and design of the domain model.
-
The principle of Least Effort
(Also called Zipf’s Law)This principle emerges from a fundamental human characteristic: We tend to follow those paths that are as effortless as possible. In other words, if our designs follow a particular pattern, then the next developer will inevitably follow that pattern until they discover a significantly easier way to complete the task, in which case they will change! If they find an acceptable solution to a task, they do not need to make immediate changes.
Minimum effort means the least amount of effort.
Therefore, it is imperative to put in place the correct architecture from the get-go: setting high expectations and making sure no quality is compromised during the project’s lifespan and that it will be adhered to even if there are future changes.
One of the great advantages of this principle is its extrapolation: once we use it to create a framework, we create a foundation for future systems we create. In other words, we can create a template for managing the organization’s software systems that is successful and future-proof.
-
The Priciples of Economics
Taking advantage of a valuable opportunity and delaying taking action are two principles that have a common theme: the cost of delaying action.
-
The principle of Opportunity Cost
Whenever we make a choice, we attribute a certain value to that choice. Costs and benefits are two aspects of value. We sacrifice something to get something. That is what we call the opportunity cost of a choice. When it comes to economics, we want to choose the route that provides us with the greatest benefit while having the lowest cost.
In other words, if we have the choice between an internal system or a product created by a third party vendor but choose the latter, then we have an opportunity cost of the shiny new system our team could have built but didn’t.
An architect’s job is to assess different options and identify which one will add the most value to the project. An example is the dichotomy between creating a tactical solution with quick time to market and one that will be more costly now but will be able to be leveraged in future initiatives with the objective to minimize costs in the future.
Consider the following points:
When will the architectural assessment be completed? Coming up with just one solution is challenging enough, much less several!
- Do you have any plans for the next one to three years? Do you have any other projects in mind? Is there any synergy you can see?
- Do you have any technical debt that could be addressed?
- Using a tactical solution, how much additional technical debt will result?
- How will the proposed solution affect the most important quality attributes in your organization?
- What other stakeholders will influence the decision besides the architecture team? How about the business? The boss? Who’s in charge of technical design? Which stakeholders have what goals? What will you do to avoid conflicts?
-
The principle of Last Responsible Moment
In Lean Software Development, this concept (also called Cost of Delay) aims to delay important decisions and actions as long as possible. It is important to wait until you have a better understanding of your options before eliminating important alternatives.
Making decisions at the last minute rather than prematurely, delaying commitments until it becomes more costly not to make one than to do so.
In order to mitigate the risk of making a decision too late, the implementation of proof-of-concept (POCs), which are prototypes of alternative options, can be used to demonstrate what stakeholders are asking for.
-
Epilogu
Architecture principles provide us with a means of evaluating our decisions throughout the project, as well as ensuring that we are achieving the overall goals of both our project and our organization’s technology.
Do You Want Your Upcoming Project Follows the Key Principles of Software Architecture?
Conclusion
Generally speaking, the Key Principles of Software Architecture discussed above provide a very good reference point throughout software development, but you will always find exceptions to these principles. To choose a suitable version of software architecture principles, you need to consider the context in which software is being developed.
