One definition I like the most so far is that software architecture represents a set of structures that we need in order to reason about the system of software elements as a whole, the relations among them and the properties of both.
It gives the answer to the question: “What diagrams are the standard for documenting software architecture”, and the answer is “Depends on what you want to reason about the system”. Do you want to reason about the components of the system or about the deployment units or about high-availability or about security or connectivity? The list of things you can reason about is big. Reasoning about all of them will significantly slow you down (to the point that your business lost its opportunity) where not reasoning at all about them will most probably doom the project to fail from the very beginning. So the short answer to the title question would probably be: “Always reason only about the important aspects of the architecture that are essential for the current needs of the business it supports”.
How to Find Which Structure or Aspects to Reason About?
The person that drives this reasoning is the Software Architect. He/she carries out a complex role that combines skills from different areas, not only limited to the technical domain.
It’s a common mistake from less experienced architects to base their architecture mainly on current trends and past experience. For example, if an architect has just transferred from a project, where he/she successfully designed a microservice-based architecture, it’s very likely that he/she will apply this approach again for their next project even if it is not the optimal solution for it. Or an architect just read about a new architectural approach and is keen to try it in the next project no matter what.
Instead of rushing to design, the first task of an architect should be identifying the stakeholders of the software system. Everyone that has a stake in the success of the system is a stakeholder: the customer, the end-users, the product owner, the marketing team, the developers. All of them have different concerns about the system they care about the most.
In order for an Architect to start reasoning about the system, he/she needs to engage the stakeholders in discussions as early as possible, make them sit together and synchronize on business goals in the first place. The business goals will set the main objectives of the system. And these main objectives will result in a prioritized list of quality attributes.
Defining Quality Attributes of the System
When you design a trading system most probably two of the most important business goals will be performance and reliability. The brokers and your algorithms will need real-time data, while you will require 99.9999% availability. If you chose a highly layered architecture this will increase portability or modifiability but it will most probably add performance loss, as well, due to the introduction of too many communication layers. And even though it’s always good for your system to be modifiable, you cannot compromise with the performance as any microsecond gained is critical. So as an architect, you will need to make a tradeoff between these attributes.
For instance, If you are designing a bank software, handling user transactions, then the security attribute will be the top priority and you can probably trade off performance for it – you can allow a transaction to take a couple of seconds more in order to do all the security checks and verifications needed.
Other important types of quality attributes are:
- Interoperability – related to the exchange of information between modules or systems. It is important when achieving a business goal requires interaction between several systems.
- Testability – relates to the ease with which software can be made to show its defects through testing. It requires additional care to maintain it – 30 to 50% of the cost goes there but the benefits are well known.
- Usability – deals with how easy it is for a user to accomplish a specific task.
- Scalability, maintainability, supportability … the list continues.
When there is a first version of the Architecture, techniques exist to validate if the identified quality attributes are covered. One such technique is called ATAM – Architecture Tradeoff Analysis Method. It was developed a decade ago by the Software Engineering Institute at Carnegie Mellon University. It also helps to further clarify the quality attributes and increases their visibility to the stakeholders.
Conclusion
- Know who your stakeholders are and what are the business goals. Always align your architecture with them.
- Maintain a list of well-defined quality attributes’ requirements.
- Evaluate your architecture’s ability to deliver these quality attributes before being implemented.
- Document your architecture using views that show how the most important quality attributes will be achieved. Use these views to reason about changes and make sure the attributes are preserved.
- Use well-known architectural patterns to achieve quality attributes. Don’t reinvent the wheel.
