Concerns: Added-value of business processes, consistency and completeness, responsibilities
Purpose: Designing, deciding
Scope: Multiple layer/Multiple aspect
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.
Concerns: Consistency, reduction of complexity, impact of change, flexibility
Purpose: Designing, deciding, informing
Scope: Multiple layer/Multiple aspect
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 technology, application, process, and actor/role 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 “serving” 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 an 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.
All core elements and all relationships are permitted in this viewpoint.
Purpose: The purpose of an Application Architecture Diagram is to show the structure of an Information System and its relations to other Information Systems.
Core concerns: The Application Architecture Diagram is used to document the application/systems layer. It can show information flows and system dependencies between Information Systems as well as depict system components and system areas.
The above picture shows an example of an Application Architecture Diagram depicting an overview of the Information Systems related to BEO. The information systems are connected by arrows that symbolize system dependencies.
Other functionalities: Application Architecture Diagrams can be analyzed in QualiWare via the toolbar for Application Portfolio Management. The Application Portfolio Management tools offers analysis for redundant functionalities, performance matrix generation, system heat map generation, asset lifecycle view (se below picture), lifecycle dependencies, and capabilities delivered by multiple information systems.
The above picture shows the Asset Lifecycle of the Information System ‘BEO’ and the Information Systems related to it is shown. The information depicted is pulled from the Information Systems’ metadata.
Relation to other templates: The elements depicted in the Application Architecture Diagram can be described in further detail in another Application Architecture Diagram, or in related diagrams such as a Data Flow Diagram.
The above picture shows an example of a more detailed view of an information system. In this Application Architecture Diagram the System Components are visible.
For documentation of a physical or hardware layer, the Infrastructure Diagram template can be used.
Properties and metadata: The Application Architecture Diagram can for example retain the following information:
The above picture shows the properties dialogue window for the Application Architecture Diagram where you can view and edit the diagram’s properties.