Role Basic Concepts Developing Views in the ADM Taxonomy of Views Views, Tools, and Languages Conclusions
Architecture views are representations of the overall architecture that are meaningful to one or more stakeholders in the system. The architect chooses and develops a set of views that will enable the architecture to be communicated to, and understood by, all the stakeholders, and enable them to verify that the system will address their concerns.
An architecture is usually represented by means of one or more architecture models that together provide a coherent description of the system's architecture. A single, comprehensive model is often too complex to be understood and communicated in its most detailed form, showing all the relationships between the various business and technical components. As with the architecture of a building, it is normally necessary to develop multiple views of the architecture of an information system, to enable the architecture to be communicated to, and understood by, the different stakeholders in the system.
For example, just as a building architect might create wiring diagrams, floor plans and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials), so an IT architect might create physical and security views of an IT system for the stakeholders who have concerns related to these aspects.
An important recent development in IT architecture practice has been the emergence of standards for architecture description, principally through the adoption by ANSI and the IEEE of ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems. One of the aims of this standard is to promote a more consistent, systematic approach to the creation of views.
TOGAF predates ANSI/IEEE Std 1471-2000. At the present time, it encourages but does not mandate the use of ANSI/IEEE Std 1471-2000.
Organizations that have incorporated, or plan to incorporate, ANSI/IEEE Std 1471-2000 into their IT architecture practice should find that none of the key concepts in TOGAF is incompatible with this standard, although some of the terminology used is not completely consistent with it.
In TOGAF Version 7 we endeavor to strike a balance between promoting the concepts and terminology of ANSI/IEEE Std 1471-2000 - ensuring that our usage of terms defined by ANSI/IEEE Std 1471-2000 is consistent with the standard - and retaining other commonly accepted terminology that is familiar to the majority of the TOGAF readership.
An example of common terminology retained in TOGAF is the use of the terms "Business Architecture", "Technical Architecture", etc. These terms reflect common usage, but are at variance with ANSI/IEEE Std 1471-2000 (in which "architecture" is a property of a thing, not a thing in its own right). This situation will be reviewed in future Versions of TOGAF. The process of gradual convergence between TOGAF and relevant standards for architecture description will continue as ANSI/IEEE Std 1471-2000 gains increased acceptance within the industry.
More general information about ANSI/IEEE Std 1471-2000 can be obtained from the IEEE Architecture Working Group.
It is arguable that the term "architecture" in this document should be replaced with the term "view", in accordance with ANSI/IEEE Std 1471-2000 recommended practice. There are practical problems with this.
Firstly, there is common usage. Typically an overall enterprise architecture comprising all the above "architectures" will not be undertaken as a single project. Rather each "architecture" - and in some cases, subsets of them - will be undertaken as individual projects. The ultimate deliverable of such a project is commonly referred to as an "... architecture" (for example, a "business architecture"). Within such an "architecture" there will very likely be views, in the true ANSI/IEEE Std 1471-2000 sense.
Secondly, such individual projects - leading to a "Business Architecture", or an "Applications Architecture", etc. - are often undertaken without any intent to develop all four "architectures" and integrate them into an overall enterprise architecture. (Or at least, there may be a long-term strategic goal to develop all four, but the initial development may intended as a free-standing "architecture" and not a View of some larger entity.)
In summary, therefore, choice of terminology will depend largely on the extent to which the organization concerned regards each of the above as a part of a larger "enterprise architecture".
For the present, TOGAF retains the terminology of “Business Architecture”, Technical Architecture”, etc., since the terminology associated with ANSI/IEEE Std 1471-2000 recommended practice is still relatively new to the industry and not yet in widespread use. This situation will be reviewed in future Versions of TOGAF.
The following concepts are central to the topic of views. These concepts have been adapted from more formal definitions contained in ANSI/IEEE Std 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems.
A system is a collection of components organized to accomplish a specific function or set of functions.
The architecture of a system is the system's fundamental organization, embodied in its components, their relationships to each other and to the environment, and the principles guiding its design and evolution.
An architecture description is a collection of artifacts that document an architecture. In TOGAF, architecture views are the key artifacts in an architecture description.
Stakeholders are people who have key roles in, or concerns about, the system: for example, as users, developers, or managers. Different stakeholders with different roles in the system will have different concerns. Stakeholders can be individuals, teams, or organizations (or classes thereof).
Concerns are the key interests that are crucially important to the stakeholders in the system, and determine the acceptability of the system. Concerns may pertain to any aspect of the system' s functioning, development, or operation, including considerations such as performance, reliability, security, distribution, and evolvability.
A view is a representation of a whole system from the perspective of a related set of concerns.
In capturing or representing the design of a system architecture, the architect will typically create one or more architecture models, possibly using different tools. A view will comprise selected parts of one or more models, chosen so as to demonstrate to a particular stakeholder or group of stakeholders that their concerns are being adequately addressed in the design of the system architecture.
A viewpoint defines the perspective from which a view is taken. More specifically, a viewpoint defines: how to construct and use a view (by means of an appropriate schema or template); the information that should appear in the view; the modelling techniques for expressing and analysing the information; and a rationale for these choices (e.g., by describing the purpose and intended audience of the view).
In summary, then, architecture views are representations of the overall architecture in terms meaningful to stakeholders. They enable the architecture to be communicated to and understood by the stakeholders, so they can verify that the system will address their concerns.
Note: The terms 'concern' and 'requirement' are not synonymous. A concern is an area of interest. So, system reliability might be a concern/area of interest for some stakeholders. The reason why architects should identify concerns and associate them with viewpoints, is to insure that those concerns will be addressed in some fashion by the models of the architecture. For example, if the only viewpoint selected by an architect is a structural viewpoint, then reliability concerns are almost certainly not being addressed, since they cannot be represented in a structural model. Within that concern, stakeholders may have many distinct requirements: different classes of users may have very different reliability requirements for different capabilities of the system.
Concerns are the root of the process of decomposition into requirements. Concerns are represented in the architecture by these requirements. Requirements should be SMART (e.g., specific metrics).
For many architectures, a useful viewpoint is that of Business Domains, which can be illustrated by an example from The Open Group itself.
The viewpoint is specified as follows:
| Viewpoint element | Description |
| Stakeholders: | Management Board, Chief Information Officer |
| Concerns: | Show the top-level relationships between geographical sites and business functions. |
| Modeling technique: | Nested boxes diagram. Blue = locations; brown = business functions. Semantics of nesting = functions performed in the locations. |
The corresponding view of The Open Group (in 2001) is shown in Figure 1.
Figure 1: Example View - The Open Group Business Domains in 2001
The choice of which particular architecture views to develop is one of the key decisions that the architect has to make.
The architect has a responsibility for ensuring the completeness (fitness-for-purpose) of the architecture, in terms of adequately addressing all the pertinent concerns of its stakeholders; and the integrity of the architecture, in terms of connecting all the various views to each other, satisfactorily reconciling the conflicting concerns of different stakeholders, and showing the trade-offs made in so doing (as between security and performance, for example).
The choice has to be constrained by considerations of practicality, and by the principle of fitness-for-purpose (i.e., the architecture should be developed only to the point at which it is fit for purpose, and not reiterated ad infinitum as an academic exercise).
As explained in Part II, Architecture Development Method, the development of architecture views is an iterative process. The typical progression is from business to technology, using a technique such as Business Scenarios to properly identify all pertinent concerns; and from high level overview to lower level detail, continually referring back to the concerns and requirements of the stakeholders throughout the process.
Moreover, each of these progressions has to be made for two distinct environments: the existing environment (referred to as the baseline in the ADM) and the target environment. The architect must develop pertinent business and technical architecture views of both the existing system and the target system. This provides the context for the gap analysis at the end of Phase C of the ADM, which establishes which elements of the current system must be carried forward and which must be removed or replaced.
This whole process is explained in Part II, Architecture Development Method, under Target Architecture Development.
As mentioned above, at the present time TOGAF encourages but does not mandate the use of ANSI/IEEE Std 1471-2000. The following description therefore covers both the situation where ANSI/IEEE Std 1471-2000 has been adopted and where it has not.
IEEE 1471-2000 itself does not require any specific process for developing viewpoints or creating views from them. Where ANSI/IEEE Std 1471-2000 has been adopted and become well-established practice within an organization, it will often be possible to create the required views for a particular architecture by following these steps:
This approach can be expected to bring the following benefits:
However, situations can always arise in which a view is needed for which no appropriate viewpoint has been pre-defined. This is also the situation, of course, when an organization has not yet incorporated ANSI/IEEE Std 1471-2000 into its architecture practice and established a library of viewpoints.
In each case, the architect may choose to develop a new viewpoint that will cover the outstanding need, and then generate a view from it. (This is the ANSI/IEEE Std 1471-2000 recommended practice.) Alternatively, a more pragmatic approach can be equally successful: the architect can create an ad hoc view for a specific system and later consider whether a generalised form of the implicit viewpoint should be defined explicitly and saved in a library, so that it can be reused. (This is one way of establishing a library of viewpoints initially.)
Whatever the context, the architect should be aware that every view has a viewpoint, at least implicitly, and that defining the viewpoint in a systematic way (as recommended by ANSI/IEEE Std 1471-2000) will help in assessing its effectiveness (i.e., does the viewpoint cover the relevant stakeholder concerns?).
TOGAF's core taxonomy of architecture views defines the minimum set of views that should be considered in the development of an architecture.
Since in ANSI/IEEE Std 1471-2000 every view has an associated viewpoint that defines it, this taxonomy may also be regarded as a taxonomy of viewpoints by those organizations that have adopted ANSI/IEEE Std 1471-2000.
The minimum set of stakeholders for a system that should be considered in the development of architecture viewpoints and views is:
The architecture views, and corresponding viewpoints, that may be created to support each of these stakeholders fall into the following categories. (As mentioned above, this taxonomy may be regarded as a taxonomy of viewpoints by those organizations that have adopted ANSI/IEEE Std 1471-2000.)
Business Architecture Views, which address the concerns of the users of the system, and describe the flows of business information between people and business processes
Technical Architecture Views, which address the concerns of technicians responsible for developing, acquiring, and operating the system, and in turn comprise:
Engineering Views, addessing the concerns of System and Software Engineers responsible for developing and integrating various components of the system.
Operations Views, addessing the concerns of systems administrators and systems managers
Acquirers Views, addressing the concerns of procurement personnel responsible for acquiring the commercial-off-the-shelf (COTS) software and hardware to be included in the system
Examples of specific views in each category are tabulated below, and explained in detail in the following subsection.
| To address the concerns of ... | |||
| Users | System and Software Engineers | Operators, Administrators & Managers | Acquirers |
| ... the following views may be developed: | |||
Business |
Technical Architecture Views |
||
| Engineering Views | Operations Views | Acquirers Views | |
o People View o Process View o Function View o Business information View o Usability View o Performance View |
o Security View o Software Engineering View o Data View o System Engineering View o Communications Engineering View |
o Security View o Software View o Data View o Computing/Hardware View o Communications View |
o Building Blocks Cost View o Standards View |
Table 1: Example Taxonomy of Architecture Views
The Architect may or may not need to develop separate views for engineers and for operations personnel. Engineering views provide information needed by engineering staff to design and implement the hardware and software system. Operations Views provide information needed by Operations staff in order to operate and administer the implemented system.
A more detailed description of each view, and guidelines for developing it, can be obtained by following the relevant hyperlink in the following.
1. Business Architecture Views address the concerns of Users, and focuses on the functional aspects of the system from the perspective of the users of the system - that is, on what the new system is intended to do, including performance, functionality, and useability. These can be built up from an analysis of the existing environment and of the requirements and constraints affecting the new system.
2. Engineering Views address the concerns of the System and Software Engineers of the system, and focus on how the system is implemented from the prespective of different types of engineers (security, software, data, computing components, communications), and how that affects its properties. Systems and software engineers are typically concerned with modifiability, reusability and availability of other services:
3. Operations Views address the concerns of the Operations, Administration, and Management of the system, and concentrate more on the details of location, type and power of the equipment and software in order to manage the health and availability of the system. They cover issues such as initial deployment, upgrading, availability, security, performance, asset management, fault and event management of system components, from the management perspective of the following subject matters.
4. Acquirers Views address the needs of an acquirer or procurer, providing appropriate guidance for purchasing components that "fit" the architecture. Acquirers' views of the architecture are primarily concerned with costs, and standards that must be adhered to; for example:
These views typically depict building blocks of the architecture that can be purchased, and the standards that the building blocks must adhere to in order for the building block to be most useful.
Architects also have concerns of their own which basically define the fitness for purpose of an effort. Architects must understand completeness, where completeness includes considering all relevant views, the relationships between those views, and dealing with the conflicts that arise from those different views. Architects also must deal with viability of the architecture: if the architecture is not capable of being implemented, then its value is in doubt.
The need for architecture views, and the process of developing them following the Architecture Development Method, are explained above. This subsection describes the relationships between architecture views, the tools used to develop and analyse them, and a standard language enabling interoperability between the tools.
In order to achieve the goals of completeness and integrity in an architecture, architecture views are usually developed, visualized, communicated, and managed using a tool.
In the current state of the market, different tools normally have to be used to develop and analyse different views of the architecture. It is highly desirable that an architecture description be encoded in a standard language, to enable a standard approach to the description of architecture semantics and their reuse among different tools.
A viewpoint is also normally developed, visualized, communicated, and managed using a tool, and it is also highly desirable that standard viewpoints (i.e., templates, or schemas) be developed, so that different tools that deal in the same views can interoperate, the fundamental elements of an architecture can be reused, and the architecture description can be shared among tools.
The Architecture Description Markup Language (ADML) is a language for encoding architecture descriptions, which The Open Group has adopted as a Technical Standard.
To illustrate the concepts of views and viewpoints, consider the example of a very simple airport system with two different stakeholders, the pilot and the air traffic controller.
The pilot has one view of the system, and the air traffic controller has another. Neither view represents the whole system, because the perspective of each stakeholder constrains (and reduces) how each sees the overall system.
The view of the pilot comprises some elements not viewed by the controller, such as passengers and fuel, while the view of the controller comprises some elements not viewed by the pilot, such as other planes. There are also elements shared between the views, such as the communication model between the pilot and the controller, and the vital information about the plane itself.
A viewpoint is a model (or description) of the information contained in a view. In our example, one viewpoint is the description of how the pilot sees the system, and the other viewpoint is how the controller sees the system.
Pilots describe the system from their perspective, using a model of their position and vector toward or away from the runway. All pilots use this model, and the model has a specific language that is used to capture information and populate the model.
Controllers describe the system differently, using a model of the airspace and the locations and vectors of aircraft within the airspace. Again, all controllers use a common language derived from the common model in order to capture and communicate information pertinent to their viewpoint.
Fortunately, when controllers talk with pilots, they use a common communication language! (In other words, the models representing their individual viewpoints partially intersect.) Part of this common language is about location and vectors of aircraft, and is essential to safety.
So in essence each viewpoint is an abstract model of how all the stakeholders of a particular type - all pilots, or all controllers - view the airport system.
Tools exist to assist stakeholders, especially when they are interacting with complex models such as the model of an airspace, or the model of air flight.
The interface to the human user of a tool is typically close to the model and language associated with the viewpoint. The unique tools of the pilot are fuel, altitude, speed, and location indicators. The main tool of the controller is radar. The common tool is a radio.
To summarise from the above example, we can see that a view can subset the system through the perspective of the stakeholder, such as the pilot versus the controller. This subset can be described by an abstract model called a viewpoint, such as an air flight versus an air space model. This description of the view is documented in a partially specialized language, such as "pilot-speak" versus "controller-speak". Tools are used to assist the stakeholders, and they interface with each other in terms of the language derived from the viewpoint ("pilot-speak" versus "controller-speak").
When stakeholders use common tools, such as the radio contact between pilot and controller, a common language is essential.
Now let us map this example to information systems architecture. Consider two stakeholders in a new small computing system: the users, and the developers.
The users of the system have a view of the system, and the developers of the system have a different view. Neither view represents the whole system, because each perspective reduces how each sees the system.
The view of the user is comprised of all the ways in which s/he interacts with the system, not seeing any details such as applications or database management systems.
The view of the developer is one of productivity and tools, and doesn't include things such as actual live data and connections with consumers.
However, there are things that are shared, such as descriptions of the processes that are enabled by this system and / or communications protocols set up for users to communicate problems directly to development.
In this example, one viewpoint is the description of how the user sees the system, and the other viewpoint is how the developer sees the system. Users describe the system from their perspective, using a model of availability, response time, and access to information. All users of the system use this model, and the model has a specific language.
Developers describe the system differently than users, using a model of software connected to hardware distributed over a network, etc. However, there are many types of developers (database, security, …) of the system, and they do not have a common language derived from the model.
Tools exist for both users and developers. Tools such as on-line help are there specifically for users, and attempt to use the language of the user. Many different tools exist for different types of developers, but they suffer from the lack of a common language that is required to bring the system together. It is difficult, if not impossible, in the current state of the tools market to have one tool interoperate with another tool.
When stakeholders need to communicate there is a need for a common model and language.
The Architecture Description Markup Language (ADML) is a standard that provides a common language to bridge some of the communications problems between tools. Based on XML, ADML provides a common language for architecture description, upon which other languages can be based for specialization, so that architecture information can be shared amongst tools.
ADML is based on the Acme language and model developed at CMU. In ANSI/IEEE Std 1471-2000 terms, ADML provides a viewpoint language (a model and a language for defining the information with which to populate the model) for describing architectures in terms of the following entities:
Components and connectors may be typed, and all of the entities may have attributes of varying kinds. The existence of attributes for each of the entities enables the description of further behavioral characteristics and/or constraints, such as performance capabilities or standards compliance.
Due to the general applicability of ADML and the need for sharing of architecture constructs, in the following subsections which provide guidance on developing particular views, the use of ADML is recommended frequently as a mechanism to document views and viewpoints.
This Version of TOGAF takes a significant step forward in dealing with views in a structured manner, but this is by no means a complete treatise on views.
In general, TOGAF embraces the concepts and definitions presented in ANSI/IEEE Std 1471-2000, specifically the concepts that help guide the development of a view and make the view actionable. These concepts can be summarized as:
In the following subsections TOGAF presents some recommended views, some or all of which may be appropriate in a particular architecture development. This is not intended as an exhaustive set of views, but simply as a starting point. Those described may be supplemented by additional views as required. These TOGAF subsections on views should be considered as guides for the development and treatment of a view, not as a full definition of a view.
Each subsection describes the stakeholders related to the view, their concerns, and the entities modeled and the language used to depict the view (the viewpoint). The viewpoint provides architecture concepts from the different perspectives, including components, interfaces, and allocation of services critical to the view. The viewpoint language, analytical methods and modeling methods associated with views are typically applied with the use of appropriate tools.
Copyright © The Open Group, 1998, 1999, 2000, 2001