Quality Attributes
Note
Software architecture aims to combine software design patterns and principles in order to define the software’s elements, their properties, and how the elements interact with each other. This suggests that these elements alone can determine the capabilities and the quality of software architecture. However, as design patterns address only a specific problem and not all business needs, this is not the case. Modern systems need to be able to focus on a wide range of problems, not just technical issues.
Individual design patterns and principles are concerned primarily with functional software issues, while software architecture considers functional and non-functional requirements. Software architecture must address the big picture. Architecture sets guidelines for design patterns and principles in order to ensure conceptual integrity and consistency throughout.
Software architecture does not have inherent qualities that make it “good architecture” or “bad architecture.” Instead, software architecture is designed to address a set of requirements. Requirements are used to address a problem or need. Further, different architectures are meant to be used in different environments and contexts. This means that an architecture isn’t bad in some cases, but rather just be incorrect for the context it is being used in.
Most systems use a combination of architectural designs. The requirements for modern systems are complex, and there may not be a clear-cut software architecture that can address all of them. This is particularly true for non-functional requirements, which are not always clear or explicitly presented by clients and stakeholders. Non-functional requirements can also vary between different stakeholder groups. For example, an end user may not care about testability, while a development group will.
Software architecture should address the concerns of all stakeholders, however. Prioritize system requirements and don’t be afraid to make compromises in order to find a good balance between system qualities.
If system architectures are not measured as inherently good or bad, there must be a way to determine if the architectural design is capable of meeting system requirements. This quality of a system is determined by quality attributes. Quality attributes are measurable properties of a system used to gauge a system’s design, run-time performance, and usability.
For an attribute to be measurable, there needs to be an objective means of quantifying it. For example, system availability can be measured by the system’s uptime in some unit of time.
This section presents industry consensus for quality attributes. However, these can be added or removed from your evaluation of a system, based on specific needs. As always, context is important in evaluating what is best for your system architecture.
This specialization has emphasized maintainability, reusability, and flexibility when designing and implementing systems. These attributes will be covered, as well as other important attributes from a developer’s perspective.
In addition to qualities to account for from a developer perspective, it is also necessary to take into consideration qualities from a user’s perspective.
As software is not inherently good or bad, it is very important to create or choose an appropriate architectural design for your systems. The system architecture will ultimately determine how functionality is implemented, how subsystems communicate with each other, and how end users will interact with the system.
Software architecture is also important, as it makes maintaining, supporting, and updating the system throughout its life cycle much easier. If the qualities of a system are poor, then it will be difficult to support changing needs.
A high-quality system does not need to be “complex.” An overly complex system makes it difficult and time consuming to produce. It is good practice to try to minimize complexity in the design. If a simpler architecture can satisfy all the system requirements and achieve a high-quality design while needing less time and less money, it makes sense to go with that.
It is important to have detailed and up-to-date documentation of a system. In fact, this is part of a high-quality system. This helps record and share an architectural vision. The documentation keeps a design cohesive, should the architect or any of the developers leave the team.
Creating a high-quality system architecture should be methodical and use a set of rules or guidelines for the design process. Although every company will have some specific design rules or system structure rules, some should be common sense.
