Working Page for the Views & Viewpoints Working Group – All Materials are DRAFT.
Description
The Open Group have developed the ArchiMate enterprise architecture modelling language to provide a uniform representation for diagrams that describe enterprise architectures, primarily in the domain of information-intensive organizations. It offers an integrated architectural approach that describes and visualizes the different architecture domains and their underlying relations and dependencies. It is very clearly targeted at the Enterprise level, both IT and business and offers limited support for development projects.
The evolution of the standard is closely linked to the developments of the TOGAF standard and the emerging results from The Open Group forums and work groups active in this area. As a consequence, the ArchiMate standard does not provide its own set of defined terms, but rather follows those provided by the TOGAF standard
In support of TOGAF, Archimate 2.1 defines 18 standard viewpoints to cover the business and enterprise architecture, focused on different sets of stakeholders, these are aligned with the ISO42010 standard definition of viewpoints. These are structured to pride a viewpoint to cover 3 aspects of each area: active structure, behaviour, and passive structure, these have been inspired by natural language, where a sentence has a subject (active structure), a verb (behaviour), and an object (passive structure). It also splits the external view and internal view on systems. When looking at the behavioural aspect, these views reflect the principles of service orientation.
The Viewpoints
The set of viewpoints provided in ArchiMate is comprehensive, and most enterprises will not use all of them comprehensively. The viewpoints are outlined in Table 1, below, full descriptions are available on the Open Group website [1]:
| Viewpoint | Definition |
|---|---|
| Introductory | This is used to explain the essence of an architecture model at a high level, using a simpiler more intuitive notation. Another use of this basic, less formal viewpoint is that it tries to avoid the impression that the architectural design is already fixed, an idea that may easily arise when using a more formal, highly structured or detailed visualization. It uses elements of the notation from other views to show multiple aspects of the system from business roles to infrastructure. The key thing is to bring out what is important for understanding. |
| Organization | The Organization viewpoint focuses on the (internal) organization of a company, a department, a network of companies, or of another organizational entity. It is possible to present models in this viewpoint as nested block diagrams, but also in a more traditional way, such as organizational charts. The Organization viewpoint is very useful in identifying competencies, authority, and responsibilities in an organization. |
| Actor Co-operation | The Actor Co-operation viewpoint focuses on the relationships of actors with each other and their environment. A common example of this is the “context diagram”, which puts an organization into its environment, consisting of external parties such as customers, suppliers, and other business partners. It is very useful in determining external dependencies and collaborations and shows the value chain or network in which the actor operates.
Another important use of the Actor Co-operation viewpoint is in showing how a number of co-operating business actors and/or application components together realize a business process. Hence, in this view, both business actors or roles and application components may occur. |
| Business Function | The Business Function viewpoint shows the main business functions of an organization and their relationships in terms of the flows of information, value, or goods between them. Business functions are used to represent the most stable aspects of a company in terms of the primary activities it performs, regardless of organizational changes or technological developments. Therefore, the business function architecture of companies that operate in the same market often exhibit close similarities. The business function viewpoint thus provides high-level insight in the general operations of the company, and can be used to identify necessary competencies, or to structure an organization according to its main activities. |
| Business Process | The Business Process viewpoint is used to show the high-level structure and composition of one or more business processes. Next to the processes themselves, this viewpoint contains other directly related concepts, such as: • The services that a business process offers to the outside world, showing how a process contributes to the realization of the company’s products • The assignment of business processes to roles, which gives insight into the responsibilities of the associated actors • The information used by the business process Each of these can be regarded as a “sub-view” of the business process view. |
| Business Process Co-operation | The Business Process Co-operation viewpoint is used to show the relationships of one or more business processes with each other and/or with their environment. It can both be used to create a high-level design of business processes within their context and to provide an operational manager responsible for one or more such processes with insight into their dependencies. Important aspects of business process co-operation are: • Causal relationships between the main business processes of the enterprise • Mapping of business processes onto business functions • Realization of services by business processes • Use of shared data Each of these can be regarded as a “sub-view” of the business process co-operation view. |
| Product | The Product viewpoint depicts the value that these products offer to the customers or other external parties involved and shows the composition of one or more products in terms of the constituting (business or application) services, and the associated contract(s) or other agreements. It may also be used to show the interfaces (channels) through which this product is offered, and the events associated with the product. A Product viewpoint is typically used in product development to design a product by composing existing services or by identifying which new services have to be created for this product, given the value a customer expects from it. It may then serve as input for business process architects and others that need to design the processes and ICT realizing these products. |
| Application Behaviour | The Application Behavior viewpoint describes the internal behavior of an application; e.g., as it realizes one or more application services. This viewpoint is useful in designing the main behavior of applications, or in identifying functional overlap between different applications. |
| Application Co-operation | The Application Co-operation viewpoint describes the relationships between applications components in terms of the information flows between them, or in terms of the services they offer and use. This viewpoint is typically used to create an overview of the application landscape of an organization. This viewpoint is also used to express the (internal) co-operation or orchestration of services that together support the execution of a business process. |
| Application Structure | The Application Structure viewpoint shows the structure of one or more applications or components. This viewpoint is useful in designing or understanding the main structure of applications or components and the associated data; e.g., to break down the structure of the system under construction, or to identify legacy application components that are suitable for migration/integration. |
| Application Usage | The Application Usage viewpoint describes how applications are used to support one or more business processes, and how they are used by other applications. It can be used in designing an application by identifying the services needed by business processes and other applications, or in designing business processes by describing the services that are available. Furthermore, since it identifies the dependencies of business processes upon applications, it may be useful to operational managers responsible for these processes. |
| Infrastructure | The Infrastructure viewpoint contains the software and hardware infrastructure elements supporting the application layer, such as physical devices, networks, or system software (e.g., operating systems, databases, and middleware). |
| Infrastructure Usage | The Infrastructure Usage viewpoint shows how applications are supported by the software and hardware infrastructure: the infrastructure services are delivered by the devices; system software and networks are provided to the applications. This viewpoint plays an important role in the analysis of performance and scalability, since it relates the physical infrastructure to the logical world of applications. It is very useful in determining the performance and quality requirements on the infrastructure based on the demands of the various applications that use it. |
| Implementation and Deployment | The Implementation and Deployment viewpoint shows how one or more applications are realized on the infrastructure. This comprises the mapping of (logical) applications and components onto (physical) artifacts, such as Enterprise Java Beans, and the mapping of the information used by these applications and components onto the underlying storage infrastructure; e.g., database tables or other files. Deployment views play an important role in the analysis of performance and scalability, since they relate the physical infrastructure to the logical world of applications. In security and risk analysis, deployment views are used to identify, for example, critical dependencies and risks. |
| Information Structure | The Information Structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying infrastructure; e.g., by means of a database schema. |
| Service Realization | The Service Realization viewpoint is used to show how one or more business services are realized by the underlying processes (and sometimes by application components). Thus, it forms the bridge between the business products viewpoint and the business process view. It provides a “view from the outside” on one or more business processes. |
| Layered | The Layered viewpoint pictures several layers and aspects of an enterprise architecture in one diagram. There are two categories of layers, namely dedicated layers and service layers. The layers are the result of the use of the “grouping” relationship for a natural partitioning of the entire set of objects and relationships that belong to a model. The infrastructure, the application, the process, and the actors/roles layers belong to the first category. The structural principle behind a fully layered viewpoint is that each dedicated layer exposes, by means of the “realization” relationship, a layer of services, which are further on “used by” the next dedicated layer. Thus, we can easily separate the internal structure and organization of a dedicated layer from its externally observable behavior expressed as the service layer that the dedicated layer realizes. The order, number, or nature of these layers are not fixed, but in general a (more or less) complete and natural layering of an ArchiMate model should contain the succession of layers depicted in the example given below. However, this example is by no means intended to be prescriptive. The main goal of the Layered viewpoint is to provide overview in one diagram. Furthermore, this viewpoint can be used as support for impact of change analysis and performance analysis or for extending the service portfolio. |
Archimate also has the concept of a Landscape Map, this is a matrix that represents a three-dimensional co-ordinate system that represents architectural relationships. The dimensions of the landscape maps can be freely chosen from the architecture that is being modeled. In practice, often dimensions are chosen from different architectural domains; for instance, business functions, application components, and products. Note that a landscape map uses the ArchiMate concepts, but not the standard notation of these concepts.
In most cases, the vertical axis represents behavior like business processes or functions; the horizontal axis represents “cases” for which those functions or processes must be executed, such as different products, services market segments, or scenarios; the third dimension represented by the cells of the matrix is used for assigning resources like information systems, infrastructure, or human resources. The value of cells can be visualized by means of colored rectangles with text labels. Obviously, landscape maps are a more powerful and expressive representation of relationships than traditional cross tables. They provide a practical manner for the generation and publication of overview tables for managers, process, and system owners. Furthermore, architects may use landscape maps as a resource allocation instrument and as an analysis tool for the detection of patterns and changes in this allocation.
Applicability
This is intended to be used by large organisation with an EA function, it is not to be intended for small organizations, although experienced practitioners will be able to scale its usage appropriately.
General Advice
There are a lot of viewpoints defined here, in order to ensure that focus is maintained on the right areas which will deliver value, make sure you do the following:
- Think carefully about the views you are going to produce and how they fit together
- This is a comprehensive EA set of views several of which deliver minimal value to development projects, make sure they don’t get swamped by information that is not useful
- Understand what can sensibly be maintained going forward, only produce these models.
It is also valuable to define your approach at the beginning of the activity and decide if you are taking a wide view: “Lets capture all our assets” or a focused view: “Lets model a single business process for beginning to end”
TOGAF
Although primarily intend for Enterprise Architecture, TOGAF is used by some organisations for software projects, here the concept of Domain is sometimes used in a similar way to viewspoints, although this is not the correct use of Domains, as they are defined as being the commonly accepted subsets of an overall enterprise architecture. The following are defined in TOGAF:
- The Business Architecture defines the business strategy, governance, organization, and key business processes.
- The Data Architecture describes the structure of an organization’s logical and physical data assets and data management resources.
- The Application Architecture provides a blueprint for the individual applications to be deployed, their interactions, and their relationships to the core business processes of the organization.
- The Technology Architecture describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services. This includes IT infrastructure, middleware, networks, communications, processing, standards, etc.
However, this is not what is intended within TOGAF, it is fully aligned with the ISO 42010 concepts and suggests that there should be a standard set of viewpoints to apply to a project.
References
[1] http://pubs.opengroup.org/architecture/archimate2-doc/chap08.html retrieved 08/06/2016.
