What is Software Architecture?
The ability to view architecture from many different perspectives is a critical skill for an architect working in a software development company. Each perspective alone might not be enough, but when combined, they create a broader picture. The standpoints included in this category are principles, standards, patterns and anti-patterns, rules of thumb and empirical practices that are crucial for decision making in a particular direction and evaluating the success of the project.
5 Principles of Software Architecture that everyone should know
A Software development company must follow a set of principles known as SOLID when working on Object-Oriented Programming System (OOPS) projects. Robert C. Martin introduced these five principles in his paper Design Principles and Design Patterns. They are essential to object-oriented design and architecture. The SOLID principles aim to make software design more understandable, boost scalability, and facilitate maintenance.
These are the underlying principles of SOLID:
S- Single Responsibility Principle: Every module or class should only have responsibility for a single functionality. As outlined in the original principle, responsibility is a “reason to change,” and each class should have only one such reason.
O- Open-Closed Principle: Basically, the open-closed principle states that all software entities should be open to enhancements and extensions without having to be modified or altered. The concept of polymorphism in OOPS is similar to this.
L- Liskov Substitution Principle: Defining each derived class as a replacement for its base class is stated in this principle. The following example is given to make this concept understandable. An object of type A may be substituted for an object of type B if A is a subclass of B. In other words, it means that the software program’s objects can be replaced with examples of subtypes without interfering with the code.
I- Interface Segregation Principle: Keeping this principle in mind is one of the most important things you can do to increase efficiency. According to it, existing interfaces should not be augmented by the addition of new methods. Each interface should cater to a particular client, and each class must implement several interfaces.
D- Dependency Inversion Principle: According to this principle, high-level modules should never rely on low-level modules. Each module should be independent of the other. Also, abstractions should not rely on details, but details should be based on abstractions. Following this principle, one can introduce an interface abstraction to avoid dependencies between high-level and low-level modules.
Architecture a system is also guided by SOLID principles. SOLID combines all five principles to provide a scalable, adaptable, testable, and reusable software solution to the software development company.
2. The ‘Least’ Principles
To manage various aspects of software development projects, the software development company uses these principles to focus on least or minimalism philosophy. “Least” principles include the following:
The Principle of Least Astonishment: According to this principle, when a sufficiently knowledgeable person encounters a solution or approach for the first time (the audience may vary, for example, end-users, programmers, testers, etc.), it should not surprise them. The principle, also known as the principle of least surprise, aims to reduce the learning curve used by users when using a module by leveraging existing knowledge. Hence, anything with a high level of unpredictability is a good candidate for re-design. Each element of the architecture is subject to it: from naming services to visualizations of user interfaces to the domain model.
The Principle of Least Effort: This principle, commonly called Zipf’s Law, was developed to reflect basic human behavior: People tend to follow as effortless paths as possible. In other words, if a software development company follows a certain pattern in their design, the developers assigned to the project will follow the same pattern unless there is a significantly easier way to accomplish the task. Or, to take this a step further, once the current solution is satisfactory, it does not need to be improved immediately. Thus, putting the right architecture in place from the start is essential: it sets high expectations and ensures there will not be any quality compromises throughout the project’s lifecycle. One of the greatest benefits of this principle is that it can be applied to multiple systems: once we create the right design, we can build an architectural framework that serves as the basis for the next system we build. By establishing a future-proof template, we can guarantee success for the software systems of the software development company.
3. The Principles of ‘Economics’
Making the most of an opportunity and delaying making decisions are two principles that share a common theme under the principles of Economics.
The principle of Opportunity Cost: We place a value on every choice we make. Costs and benefits are two perspectives on value. A choice’s opportunity cost is the sacrifice we make to obtain it. The best economical choice is the one that will benefit us the most but with the lowest cost. This is the essence of architecture: evaluating options against each other and deciding which one will add the most value to the project. It is a very common dichotomy to decide whether to create a tactical solution with a shorter time to market or a more strategic solution, which is more expensive today but can be leveraged in future projects, enabling the cost to be minimized later on.
The following points are considered in the software development company:
What is the time available for the analysis/evaluation of the architectural design? Imagine coming up with multiple solutions! Finding even one solution is hard enough.
Where are the products going in the next year or two? What projects are in the works? Is there any potential for synergy?
Identify the system quality attributes in your organization that is most important and describes how the proposed solution will compromise them.
What other stakeholders will affect the decision, other than the architecture team? Which stakeholders have the most important objectives? What are your plans to resolve conflicting needs?
The Cost of Delay Principle or the Last Responsible Moment: According to this principle, no major decision or action should be delayed until it is absolutely necessary in the software development company. Using this principle, developers can understand all the main alternatives and broaden their perspectives on making decisions. Some claim that this principle can result in risks. You can still follow this principle by demonstrating to stakeholders the advantages of delaying a decision and the benefits of another option by building proof of concepts (PoCs).
4. Crosscutting Concerns
In your application, cross-cutting concerns are key areas of design that aren’t specific to one layer. In the software development company, these key points are always kept in mind by the developers to ensure the success of the software.
Instrumentation and Logging: All business-critical and system-critical events should be measured, and sufficient details should be recorded in the system to recreate events without adding sensitive information.
Authentication: The method by which users can authenticate themselves and pass their authenticated identities to a protected system must be defined.
Authorization: Establish a division of authority within each layer, as well as across trust boundaries.
Exception management: An exception handling system focuses on two aspects: catching exceptions at functional, physical, and logical boundaries. The second component is preventing users from seeing sensitive information.
Communication: Use proper protocols to protect sensitive data from crossing the network and minimize network calls.
5. Don’t repeat yourself (DRY)
A concept should not be specified in more than one place within an application. In this case, errors will be a frequent occurrence. One instance of this behaviour is likely to fail to be updated, which will cause erratic behaviour. Eventually, this behaviour will have to change due to a change in requirements.
Resource: Wikipedia, itechnolabs
The Tech Platform