Defining the Architecture

Architecture is about everything. This is just one of the reasons that it is especially difficult to define, not to mention describe. The term itself means different things to different people. For some, it is the set of middleware that the application uses. For others, it is much richer and describes all the significant decisions made in the process of developing the application.

The best way to approach the topic of architecture is to think about how it is going to be used and who its audience is. The architect or the architecture team has the sole responsibility of defining and communicating the system's architecture. The architecture's key role is to define the set of constraints placed on the design and implementation teams when they transform the requirements and analysis models into the executable system. These constraints contain all the significant design decisions and the rationale behind them.

An architecture description is either a single document or a set of documents and artifacts that describe the architecture. Because it contains key decisions for nearly every technological aspect of the system, an architecture needs to be communicated at various levels of abstraction and from many viewpoints.

My first introduction to visualizing architectures through views was in Philippe Kruchten's landmark paper "The 4 + 1 View Model of Architecture."[1] In this paper, architecture is described through a series of views: the logical view, the implementation view, the process view, and the deployment view. The one view that ties them all together is the use case view, which binds the other views of the architecture to the original reason for the system. In a way, the architecture represents the rationale for the decisions made in the other four views. If something in any of the views can't point to something in the use case view as justification, its existence in the architecture should be questioned.

[1] Philippe Kruchten, "The 4 + 1 View Model of Architecture," IEEE Computer 12 (6), November 1995, pp. 4250.

The four views mentioned in the original article are not the only views allowed. Other views are included in the description as necessary. In Internet-based applications, the security view and the user experience view are commonly included.[2]

[2] The user experience view in this case is focused on the architectural aspects of the interface, specifically as they relate to browser-supported HTML, issues general to the Internet, and other related concerns rather than on the content, which is expressed in the use case view.

More recently, IBM has put forth an Architecture Description Standard (ADS),[3] which defines two major aspects: functional and operational. The IBM ADS leverages UML to help express these two aspects of the architecture. This standard is intended to support harvesting and reuse of reference architectures.

[3] R. Youngs, D. Redmond-Pyle, P. Spaas, and E. Kahan, IBM Systems Journal 38, Nov. 1999. "A Standard for Architecture Description," available at http://www.research.ibm.com/journal/sj/381/youngs.html.

This book adopts the approach of defining multiple viewpoints. Viewpoints are a collection of views that share a set of concerns. Viewpoints provide the context and the meaning for each view. A view is a projection, or subset, of the system's models. A view addresses a stakeholder's or a worker's related concerns about the system. For example, the requirements viewpoint is concerned with representing the context that the system is being placed in and its principal risks. The design viewpoint, on the other hand, is concerned with the system's structuresubsystemsand interactions of its elements.

Each view is essentially a subset of the artifacts created in the development process. For example, the requirements viewpoint contains the domain view, the functional requirements viewuse case modeland the nonfunctional requirements view. If this sounds familiar, don't be surprised. These views are essentially the categories of the principal artifacts for the requirements set and the requirements workflow.

In fact, if you look at all the viewpoints and their views, you will see a representative sample of nearly every artifact in the process. Architecture is about everything, after all! The one key differentiator is that all the content in this architecture description is "architecturally significant." Defining an architecture, then, becomes an activity of identifying what is architecturally significant and expressing it in the proper context and viewpoint. An architecturally significant requirement is a system requirement that has a profound impact on the development of the rest of the system. For example, the decision to limit the number of data collection fields on any page to no more than 15 is not an architecturally significant requirement. The decision to support international character sets on pages, however, is. This requirement affects not only the analysis process but also design, test, deployment, and so on.

Most documented software architectures I have seen have been focused on the selection of the vendor's middleware, the subsystem structure, and their principal interfaces, and that type of description was just fine. Some of the better architectures include design goals, success criteria, and the reasoning behind the architectural decisions. Another property of a good architectural description is prioritization. At some point during the process, direct application of the architecture might be ambiguous. With the architectural decisions prioritized, addressing the issue in an unbiased way would be easier. Even so, when a member of the development team catches an ambiguity in the architecture description, it needs to be brought to the attention of the architect.