News

Big in Japan

A Japanese translation of our book was published on 2 December 2008 and has already received three five-star reviews on Amazon Japan.
Amazon Japan

Architectural Training

Rebecca Wirfs-Brock has developed a course, based in part on our book, which provides software architects with skills and knowledge that enable them to prepare, present, and explain their architectures to diverse stakeholders.
Wirfs-Brock Associates

Amazon Reviews

We now have fifteen five-star reviews on Amazon.com. Thanks to all who have provided such strong endorsements. We are really pleased that people are finding it so useful.
Reviews Page

Introduction to Perspectives

We use viewpoints (such as the Functional, Information, and Deployment viewpoints) to guide the process of capturing and representing the architecture as a set of views, with the development of each view being guided by the use of a specific viewpoint. When creating a view, your focus is on the issues, concerns, and solutions pertinent to that view. So, for an Information view, for example, you focus on things such as information structure, ownership, transactional integrity, data quality, and timeliness.

Many of the important concerns that are pertinent to one view are much less important when considering the others: Data ownership, for example, is not key to formulating the Concurrency view, nor is the development environment a major concern when considering the Functional view. (Of course, the decisions taken in one view can have a considerable impact on the others, and it is a big part of the architect's job to make sure that these implications are understood. However, the concerns addressed in different views are largely different.)

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. In fact, for any significant system, you usually must partition your analysis this way because trying to address the entire problem is too much to understand or describe in a single piece.

Quality Properties

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. Let's look at an example to understand why.

Example. Security is clearly a vital aspect of most architectures. It has always been important to be able to restrict access to data or functionality to appropriate classes of users, and in the age of the Internet, good external and internal security is even more important. If some of your systems are exposed to the wider world, they are vulnerable to attack, and the consequences of a breach can be disastrous for finances or public relations. (The large number of high-profile Internet security failures in Europe and North America during the early part of the millennium illustrates this clearly.)
In our experience, security is often not thought through properly early in the project lifecycle. Part of the reason for this is that security is hard-the means for achieving an appropriate level of security are complex and require sophisticated analysis. Also, it may be considered to be "someone else's problem" - the responsibility of a specialist security group rather than of the organization as a whole. You may be surprised, therefore, that we have not included a Security viewpoint in our catalog to go along with the others (Functional, Information, Deployment, and so forth).
We used to approach concerns like security just like that ourselves. We used a Security viewpoint and started to consider which classes of stakeholders have concerns in this area, what this viewpoint should consist of, and how a typical Security view might actually look.
However, experience taught us that security is an important factor that affects aspects of the architecture addressed by most if not all of the other viewpoints. Furthermore, which of the system's security qualities are significant depends on which viewpoint we are considering. Here are some examples.

From the Functional viewpoint, the system needs the ability to identify and authenticate its 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 resilient to attack.
From the Information viewpoint, the system must be able to control different classes of access to information (read, insert, update, delete). The system may need to apply these controls at varying levels of granularity (e.g., defining object-level security within a database).
From the Operational viewpoint, the system must be able to maintain and distribute secret information (e.g., keys and passwords) and must be up-to-date with the latest security updates and patches.
When we consider the system from the Development, Concurrency, and Deployment viewpoints, we'll probably also find aspects of the architecture that will be affected by security needs. So our overall criterion of "the system must be secure" actually breaks down across the viewpoints into a number of more specific criteria.

As the example shows, there is an inherent need to consider quality properties such as security in each architectural view. Considering them in isolation just doesn't make sense, so using a viewpoint to guide the creation of another view for each quality property doesn't make sense either.

Architectural Perspectives

Going back to our example, although security is clearly important, representing it in our conceptual model of software architecture as another viewpoint doesn't really work. A comprehensive security viewpoint would have to consider process security, information security, operational security, deployment security, and so on: In other words, it would affect exactly the aspects of the system that we have considered so far using our viewpoints.

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 have coined the term architectural perspective (which we shorten to perspective) to refer to it.

Definition. 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.

Although our use of the term perspective is new, many of the ideas behind it clearly aren't. The issues addressed by perspectives are often referred to as nonfunctional requirements of the architecture, although we prefer not to use this term.

With perspectives, we are 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 never 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.

Our Perspective Catalog

Part IV of our book defines several perspectives which form a set intended for application to the architectures of large-scale information systems. We list these below together with the quality that application of the perspective helps to achieve.

Accessibility The ability of the system to be used by people with disabilities

Availability and Resilience The 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 The ability of the system to be designed, built, deployed, and operated within known constraints around people, budget, time, and materials

Evolution The 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 The ability of the system to be independent from any particular language, country, or cultural group

Location The ability of the system to overcome problems brought about by the absolute location of its elements and the distances between them

Performance and Scalability The ability of the system to predictably execute within its mandated performance profile and to handle increased processing volumes

Regulation The ability of the system to conform to local and international laws, quasi-legal regulations, company policies, and other rules and standards

Security The ability of the system to reliably control, monitor, and audit who can perform what actions on what resources and to detect and recover from failures in security mechanisms

Usability The ease with which people who interact with the system can work effectively