Archimate

Application Interface ArchiMate

An application interface specifies how the functionality of a component can be accessed by other elements. An application interface exposes application services to the environment. The same application service may be exposed through different interfaces, and the same interface may expose multiple services.

In a sense, an application interface specifies a kind of contract that a component exposing this interface must fulfill. This may include parameters, protocols used, pre- and post-conditions, and data formats.

An application interface may be part of an application component through composition, which means that these interfaces are provided by that component, and can serve other application components. An application interface can be assigned to application services, which means that the interface exposes these services to the environment. The name of an application interface should preferably be a noun.

Properties:

Property Metamodel name Description
Short description ShortDescription
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Application Interaction : ArchiMate

An application interaction represents a unit of collective application behavior performed by (a collaboration of) two or more application components.

An application interaction describes the collective behavior that is performed by the components that participate in an application collaboration. This may, for example, include the communication pattern between these components. An application interaction can also specify the externally visible behavior needed to realize an application service. The details of the interaction between the application components involved in an application interaction can be expressed during the detailed application design using, for example, a UML interaction diagram.

An application collaboration may be assigned to an application interaction. An application interaction may realize an application service. Application services and technology services may serve an application interaction. An application interaction may access data objects. The name of an application interaction should clearly identify a series of application behaviors; e.g., “Client profile creation” or “Update customer records”.

Properties:

Property Metamodel name Description
Short description ShortDescription
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Application Function : ArchiMate

An application function represents automated behavior that can be performed by an application component.

An application function describes the internal behavior of an application component. If this behavior is exposed externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behavior is specified.

An application function may realize one or more application services. Application services of other application functions and technology services may serve an application function. An application function may access data objects. An application component may be assigned to an application function (which means that the application component performs the application function). The name of an application function should preferably be a verb ending with “ing”; e.g., “accounting”.

Properties:

Property Metamodel name Description
Short description ShortDescription  
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Application Collaboration : ArchiMate

An application collaboration represents an aggregate of two or more application components that work together to perform collective application behavior.

An application collaboration specifies which components cooperate to perform some task. The collaborative behavior, including, for example, the communication pattern of these components, is modeled by an application interaction. An application collaboration typically models a logical or temporary collaboration of application components, and does not exist as a separate entity in the enterprise.

Application collaboration is a specialization of component, and aggregates two or more (cooperating) application components. An application collaboration is an active structure element that may be assigned to one or more application interactions or other application internal behavior elements, which model the associated behavior. An application interface may serve an application collaboration, and an application collaboration may be composed of application interfaces. The name of an application collaboration should preferably be a noun.

Properties:

Property Metamodel name Description
Short description ShortDescription
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Aggregation ArchiMate

Aggregation:ArchiMate is a connector. It indicates that an element groups a number of other concepts.

The aggregation relationship has been inspired by the aggregation relationship in UML class diagrams. In contrast to the composition relationship, an object can be part of more than one aggregation.

An aggregation relationship is always allowed between two instances of the same element type.

In addition to this, the metamodel explicitly defines other source and target elements that may be connected by an aggregation relationship.

 

Properties:

Property Metamodel name Description
Short description ShortDescription  
Implements Implements Links to: All templates.
BreaksDownTo BreaksDownTo Links to: All templates.

Access ArchiMate

Access ArchiMate is one out of three ‘Dependency Relationships’ from the ArchiMate metamodel. IT represents a data dependency and is denoted by a dashed line.

Dependency relationships describe how elements support or are used by other elements. Three types of dependency relationship are distinguished:

  • The servingrelationship represents a control dependency, denoted by a solid line.
  • The accessrelationship represents a data dependency, denoted by a dashed line.
  • The influencerelationship is the weakest type of dependency, used to model how motivation elements are influenced by other elements.

Note that, although the notation of these relationships resembles the notation of the dependency relationship in UML, these relationships have distinct meanings in ArchiMate notation and (usually) point in the opposite direction. One advantage of this is that it yields models with directionality, where most of the arrows that represent such supporting, influencing, serving, or realizing dependencies point ‘upwards’ towards the client/user/business. Another reason for this direction, in particular for the serving relationship, is that it abstracts from the ‘caller’ or ‘initiator’, since a service may be delivered proactively or reactively. The direction of delivery is always the same, but the starting point for the interaction can be on either end. UML’s dependency is often used to denote the latter, showing that the caller depends on some operation that is called. However, for modelling this type of initiative, the ArchiMate language provides the triggering relationship, which can be interpreted as a dynamic (i.e., temporal) dependency. Similarly, the flow relationship is used to model how something (usually information) is transferred from one element to another, which is also a dynamic kind of dependency.

If you want to learn more about the ArchiMate language, you can find the specification here

System Software : ArchiMate

System software is a specialization of a node that is used to model the software environment in which artifacts run. This can be, for example, an operating system, a JEE application server, a database system, or a workflow engine. Also, system software can be used to represent, for example, communication middle-ware. Usually, system software is combined with a device representing the hardware environment to form a general node.

A device or system software can be assigned to other system software; e.g., to model different layers of software running on top of each other. System software can be assigned to artifacts, to model that these artifacts are deployed on that software. System software can realize other system software. A node can be composed of system software.

The name of system software should preferably be a noun referring to the type of execution environment; e.g., “JEE server”. System software may be composed of other system software; e.g., an operating system containing a database.

Business Process Cooperation Viewpoint : Archimate

Purpose: Designing, deciding

Concerns: Dependencies between business processes, consistency and completeness, responsibilities

Scope: Multiple layer/Multiple aspect

The business process cooperation viewpoint is used to show the relationships of one or more business processes with each other and/or with their environment. It can be used both 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 cooperation 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-viewpoint” of the business process cooperation viewpoint.

BusinessProcessCoopViewpoint.docx

Application Usage Viewpoint : Archimate

Purpose: Designing, deciding

Concerns: Consistency and completeness, reduction of complexity

Scope: Multiple layer/Multiple aspect

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.

Abstraction Level
Coherence

Layer
Business and application layers

Aspects
Behavior, active structure, passive structure

ApplicationUsageViewpoint_1