Every architecture decision involves trade-offs. When you’re making decisions, you have to weigh which characteristics may benefit and which characteristics may end up suffering because of the decision. Let’s talk more about these characteristics, as you may use these in your decision making and will also need to think about them when tackling an architecture kata.
Nonfunctional Requirements? Qualities? -ilities?
Let’s talk about the terms before we talk about the examples.
You may hear the term “nonfunctional requirements”, “architecture characteristics”, or “quality attributes” when talking about these architectural qualities. Some people do not prefer using “nonfunctional requirements” because the term “nonfunctional” has a negative connotation. Some people will also use the term “-ilities” when talking about these attributes; however, not all attributes end in “-ility”.
Whatever term you choose, know that we are talking about characteristics of software architecture that are considered when making architecture decisions. I will not be covering an exhaustive list of these characteristics. However, I will be covering some of the many characteristics that architects think about in their decisions.
What Makes an Architecture Characteristic
How do you know if something is considered an architecture characteristic? Mark Richards and Neal Ford talk about this in Fundamentals of Software Architecture. The key points are:
- Does the characteristic apply to a nondomain aspect of the design?
- Does the characteristic influence some structural aspect of the design?
- Is the characteristic critical or important for the application to be successful?
Categorizing the Architecture Characteristics
There are many ways these attributes - including internal to the system versus externally visible to the end-users and stakeholders, utility versus fitness, ISO-25010, the Architecture Tradeoff Analysis Method way, FURPS, and with categories like how they appear in Software Architecture in Practice.
Characteristics that Work Well Together
These are some pairs of characteristics that may work well together.
- Scalability and Modularity: Modular architectures facilitate scalability by allowing components to be added or removed easily, enabling the system to scale horizontally or vertically as needed.
- Flexibility and Extensibility: Flexible architectures accommodate changes in requirements or technology without requiring significant redesign. Extensible architectures allow for the addition of new features or functionality with minimal impact on existing code.
- Performance and Efficiency: Architectures designed for performance typically prioritize efficient use of resources, such as memory and CPU, to achieve optimal system throughput and response times.
- Reliability and Fault Tolerance: Reliable architectures ensure that the system behaves predictably under normal conditions, while fault-tolerant architectures handle failures gracefully, maintaining system availability and data integrity.
- Security and Maintainability: Secure architectures implement measures to protect against threats and vulnerabilities, while maintainable architectures are designed for ease of maintenance and updates without compromising security.
Characteristics that May Conflict
These are some pairs that may conflict with each other during considerations.
- Performance and Security: Improving performance often involves optimizations that may introduce security vulnerabilities, such as reducing encryption overhead or relaxing access controls to speed up data access.
- Flexibility and Performance: Highly flexible architectures may introduce overhead that negatively impacts performance, such as dynamic runtime configuration or excessive abstraction layers.
- Scalability and Data Consistency: Achieving strong data consistency across distributed systems can be challenging and may limit scalability, as maintaining consistency often requires coordination and synchronization overhead.
- Simplicity and Extensibility: Simple architectures are easier to understand and maintain but may lack the extensibility needed to accommodate future requirements without significant redesign.
- Reliability and Cost: Architectures designed for high reliability often require redundant hardware or software components, which can increase costs and complexity.
Conclusion
Every software architecture decision is a trade-off. When you have to make a decision, you have to find out what’s important for the business. You need to look at where they are today and where they may be headed. Understand the priorities of the quality attributes at stake. Make sure to document your decision and indicate the beneficial quality attributes as well as the ones that are negatively impacted. Document your trade-offs.
If you are looking to practice your software architecture analysis skills, we are running an Architecture Kata on May 29. Participate in a kata with us!