Software Architecture Concepts: Architectural Perspectives
In the introductory article, we have already described some key concepts about software architecture. Now it’s time to dive in and learn about a concept called perspectives, which is a very important notion for a software architect to understand.
Even though views and viewpoints are powerful, the need for specifying quality properties remain. On this matter, architectural perspectives come in handy. Instead of defining yet another viewpoint to describe the quality properties of a product, we define something “orthogonal” to viewpoints — perspectives (coined by the Software Systems Architecture authors, Nick Rozanski & Eoin Woods):
An architectural perspective is a collection of architectural activities, tactics, and guidelines that are used to ensure that a system exhibits a particular set of related quality properties that require consideration across a number of the system’s architectural views.
Although perspectives are often referred to as cross-cutting concerns or nonfunctional requirements, it is preferable to not use the latter term.
Architectural tactics may have a goal of achieving satisfactory system performance by defining different processing priorities for different parts of the system’s workload. The concept of tactic should not be mistaken for design pattern. Tactic is a thing more general and less constraining.
A perspective provides a framework. You never work with perspectives in isolation but use them with each view of your architecture. That is, you apply a perspective to a view.
According to Rozanski and Woods, the following are the most important perspectives for large information systems:
- Performance and Scalability
- Availability and Resilience
Applying perspectives as early as possible to the design of the architecture is often preferable. The aforementioned book defines the perspectives in the following standard manner:
- Applicability. Which views are most likely to be affected by the perspective?
- Concerns. What are the quality properties that the perspective addresses?
- Activities. Which steps are there for applying the perspective to the views? — identifying quality properties, analyzing views against them, making decisions to improve the views.
- Architectural tactics. What are the most important tactics for achieving its quality properties?
- Problems and pitfalls. What are the most common things that can go wrong and how to avoid them?
- Checklists. What is the list of questions that will help you to make sure that you have addressed everything above?
- Further reading. What are the sources for further information?
Although it could be the case that all the perspectives are applied to all the views, usually, due to time and resource constraints, only some perspectives are applied to some views. An example table for applying perspectives is as follows:
Insights, Improvements, Artifacts
Applying perspectives can lead to insights, improvements, or artifacts.
Applying a perspective almost always leads to the creation of some sort of a model, which demonstrates whether the architecture meets its required quality properties or if it is deficient in some areas.
If insights tell you that some quality properties are unmet, then the architecture needs improvements. You may need to change the existing model in a view, or create additional models, or perhaps both.
Some outcomes are going to be discarded, while others, which we call artifacts, should be preserved, as they keep important architectural information. Artifacts are usually captured as documents, models, or implementations.
Although perspectives are essential, there could arise some pitfalls along the way. For example, there can be conflicts between solutions suggested by different perspectives. Therefore, choosing perspectives wisely is a software architect’s main responsibility.