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