- Identifying and Engaging Your Stakeholders
- Creating Views Using Viewpoints
- Viewpoints
- Applying Perspectives to Views
- Putting It All Together
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Applying Perspectives to Views
Although the views, when combined, form a representation of the whole architecture, we can consider them largely independent of one another—a disjoint partition of the whole architectural analysis. For any significant system you usually have to partition your analysis this way, because trying to address the entire problem is too much to understand or describe in one go. However, many architectural decisions address concerns that are common to many or all views. These concerns are normally driven by the need for the system to exhibit a certain quality property rather than to provide a particular function. In our experience, trying to address these aspects of an architecture by using viewpoints doesn't work well. Consider security, as an example:
- Most systems need the ability to identify and authenticate users (internal and external, human and mechanical). Security processes should be effective but unobtrusive, and any external processes exposed to the outside world need to be resistant to attack.
- The system must be able to control different classes of access to information and may need to apply these controls at varying levels of granularity (for example, defining object-level security within a database).
- The system must be able to maintain and distribute secret information (such as keys and passwords) and must be up to date with the latest security updates and patches.
These security considerations need to be considered in the Functional view, Information view, and Operational view of the system, respectively. Rather than defining another viewpoint and creating another view, we need some way to modify and enhance our existing views to ensure that our architecture exhibits the desired quality properties. We therefore need something in our conceptual model that can be considered "orthogonal" to viewpoints, and we've coined the term architectural perspective (which we shorten to perspective) to refer to it. An architectural perspective is a collection of 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.
With perspectives, we're trying to systematize what a good architect does anyway—understand the quality properties that are required; assess and review the architectural models to ensure that the architecture exhibits the required properties; identify, prototype, test, and select architectural tactics to address cases when the architecture is lacking; and so on.
A perspective provides a framework to guide and formalize this process. This means that you don't work with perspectives in isolation, but instead use them with each view to analyze and validate the qualities of your architecture and to drive further architectural decision-making. We describe this as applying the perspective to the view, as shown in Figure 2.
)
Figure 2 Applying perspectives.
Why Perspectives Are Important
Applying a perspective helps you in three crucial ways.
First of all, applying a perspective almost always leads to the creation of something that provides an insight into the system's ability to meet a required quality property. Such a model demonstrates either that the architecture meets its required quality properties or (more likely in the early stages of architecture definition) that it' deficient in some way. These insights normally drive further architectural design activity and are usefully recorded in their own right as rationales for significant design decisions.
Second, applying the perspective often tells you that the architecture will not meet one of its quality properties, and helps you to identify the required architectural improvements. In this case, you may need to change an existing model in the view, create additional models to further develop the content of the view, or perhaps do both of these.
Finally, some of the models and other deliverables created as a result of applying a perspective will be of only passing interest and will probably be discarded once the insight or improvement they reveal is understood. However, other outputs of applying a perspective are of significant, lasting value and supply important architectural information. These outputs, which we term artifacts, are a valuable outcome of applying a perspective and should be preserved. Artifacts are typically captured as documents, models, or implementations, which are referenced from the AD as supporting information.
Perspective Catalog
A perspective catalog defines a number of perspectives, which the following table briefly describes. The perspective catalog aims to identify all of the quality properties that may be important to a modern information system. Some will be more relevant than others, depending on the goals of the system, the context in which it's being built, and the concerns and priorities of the stakeholders.
|
Perspective |
Concerns |
|
Accessibility |
Ability of the system to be used by people with disabilities |
|
Availability and Resilience |
Ability of the system to be fully or partly operational as and when required and to effectively handle failures that could affect system availability |
|
Development Resource |
Ability of the system to be designed, built, deployed, and operated within known constraints around people, budget, time, and materials |
|
Evolution |
Ability of the system to be flexible in the face of the inevitable change that all systems experience after deployment, balanced against the costs of providing such flexibility |
|
Internationalization |
Ability of the system to be independent from any particular language, country, or cultural group |
|
Location |
Ability of the system to overcome problems brought about by the absolute location of the system's elements and the distances between them |
|
Performance and Scalability |
Ability of the system to execute predictably within its mandated performance profile and to handle increased processing volumes |
|
Regulation |
Ability of the system to conform to local and international laws, quasi-legal regulations, company policies, and other rules and standards |
|
Security |
Ability of the system to reliably control, monitor, and audit who can perform what actions on which resources and to detect and recover from failures in security mechanisms |
|
Usability |
Ease with which people who interact with the system can work effectively |