Figure 67 gives an overview of the Application Layer elements and their relationships. Whenever applicable, inspiration has been drawn from the analogy with the Business Layer.
Figure 67: Application Layer Metamodel
Note: This figure does not show all permitted relationships: every element in the language can have composition, aggregation, and specialization relationships with elements of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 5.6.
The Application Layer is typically used to model the information systems architectures of the enterprise, including the application architecture that, as defined by the TOGAF framework [4], describes the structure and interaction of the applications.
The main active structure element for the Application Layer is the application component. This element is used to model any structural entity in the Application Layer: not just (re-usable) software components that can be part of one or more applications, but also complete software applications, sub-applications, or information systems. Although very similar to the UML component, the ArchiMate application component element strictly models the structural aspect of an application; its behavior is modeled by an explicit relationship to the behavior element.
Also in the application architecture, the inter-relationships of components are an essential ingredient. Therefore, we also introduce the element of application collaboration here, defined as a collective of application components which perform application interactions. The element is very similar to the collaboration as defined in the UML standard [7], [8].
In the purely structural sense, an application interface is the (logical) channel through which the services of a component can be accessed. In a broader sense (as used in, among others, the UML definition), an application interface defines some elementary behavioral characteristics: it defines the set of operations and events that are provided by the component, or those that are required from the environment. Thus, it is used to describe the functionality of a component. The application interface element can be used to model both application-to-application interfaces, which offer internal application services, and application-to business interfaces (and/or user interfaces), which offer external application services.
An application component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces.
An application component is a self-contained unit. As such, it is independently deployable, re-usable, and replaceable. An application component performs one or more application functions. It encapsulates its contents: its functionality is only accessible through a set of application interfaces. Cooperating application components are connected via application collaborations.
An application component may be assigned to one or more application functions. An application component has one or more application interfaces, which expose its functionality. Application interfaces of other application components may serve an application component. The name of an application component should preferably be a noun.
The application component element is used to model entire applications (i.e., deployed and operational IT systems, as defined by the TOGAF framework [4]) and individual parts of such applications, at all relevant levels of detail.
Figure 68: Application Component Notation
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.
Figure 69: Application Collaboration Notation
An application interface represents a point of access where application services are made available to a user, another application component, or a node.
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.
Figure 70: Application Interface Notation
The Online Travel Insurance Sales application collaboration aggregates two application components: Quotation and Purchase. The application collaboration provides an application interface Web Services Interface that serves another application component Travel Website.
Example 26: Application Active Structure Elements
Behavior in the Application Layer is described in a way that is very similar to Business Layer behavior. Also here, a distinction is made between the external behavior of application components in terms of application services, and the internal behavior of these components; i.e., application functions that realize these services.
An application service is an externally visible unit of behavior, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service element provides a way to explicitly describe the functionality that components share with each other and the functionality that they make available to the environment. The concept fits well within service-oriented application architecture. The functionality that an interactive computer program provides through a user interface is also modeled using an application service, exposed by an application-to-business interface representing the user interface. Internal application services are exposed through an application-to-application interface.
An application function describes the internal behavior of a component needed to realize one or more application services. In analogy with the Business Layer, an application process models an ordering of application behavior, as a counterpart of a business process. Note that the internal behavior of a component should in most cases not be modeled in too much detail in an architectural description, because for the description of this behavior we may soon be confronted with detailed design issues.
An application interaction is the behavior of a collaboration of two or more application components. An application interaction is external behavior from the perspective of each of the participating components, but the behavior is internal to the collaboration as a whole.
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”.
Figure 71: Application Function Notation
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”.
Figure 72: Application Interaction Notation
An application process represents a sequence of application behaviors that achieves a specific outcome.
An application process describes the internal behavior performed by an application component that is required to realize a set of services. For a (human or automated) consumer the services are relevant and the required behavior is merely a black box, hence the designation “internal”.
An application process may realize application services. Other application services may serve (be used by) an application process. An application process may access data objects. An application component may be assigned to an application process (which means that this component performs the process). The name of an application process should clearly identify a series of application behaviors; e.g., “Claims adjudication process”, or “General ledger update job”.
Figure 73: Application Process Notation
An application event is an application behavior element that denotes a state change.
Application functions and other application behavior may be triggered or interrupted by an application event. Also, application behavior may raise events that trigger other application behavior. Unlike processes, functions, and interactions, an event is instantaneous; it does not have duration. Events may originate from the environment of the organization (e.g., from an external application), but also internal events may occur generated by, for example, other applications within the organization.
An application event may have a time attribute that denotes the moment or moments at which the event happens. For example, this can be used to model time schedules; e.g., an event that triggers a daily batch process.
An application event may trigger or be triggered (raised) by an application function, process, or interaction. An application event may access a data object and may be composed of other application events. The name of an application event should preferably be a verb in the perfect tense; e.g., “claim received”.
Figure 74: Application Event Notation
An application service represents an explicitly defined exposed application behavior.
An application service exposes the functionality of components to their environment. This functionality is accessed through one or more application interfaces. An application service is realized by one or more application functions that are performed by the component. It may require, use, and produce data objects.
An application service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users. It has a purpose, which states this utility to the environment. This means, for example, that if this environment includes business processes, application services should have business relevance.
A purpose may be associated with an application service. An application service may serve business processes, business functions, business interactions, or application functions. An application function may realize an application service. An application interface may be assigned to an application service. An application service may access data objects. The name of an application service should preferably be a verb ending with “ing”; e.g., “transaction processing”. Also, a name explicitly containing the word “service” may be used.
Figure 75: Application Service Notation
The Purchase Travel Insurance application interaction is composed of two application functions: Prepare Quotation, realizing an application service Get Quotation, and Finalize Purchase, realizing an application service Purchase Quoted Insurance. This application interaction models the cooperative behavior of the Quotation and Purchase application components, modeled as the application collaboration Online Travel Insurance Sales in Example 26. An application event Request for a Quotation triggers an application process Obtain Travel Insurance, which is served by the two aforementioned application services.
Example 27: Application Behavior Elements
The passive counterpart of the application component in the Application Layer is called a data object. This element is used in the same way as data objects (or object types) in well-known data modeling approaches, most notably the “class” concept in UML class diagrams. A data object can be seen as a representation of a business object, as a counterpart of the representation element in the Business Layer. The ArchiMate language does not define a specific layer for information; however, elements such as business objects and data objects are used to represent the information entities and also the logical data components that realize the business objects.
A data object represents data structured for automated processing.
A data object should be a self-contained piece of information with a clear meaning to the business, not just to the application level. Typical examples of data objects are a customer record, a client database, or an insurance claim.
As explained in Section 3.6, the ArchiMate language in general focuses on the modeling of types, not instances, since this is the most relevant at the Enterprise Architecture level of description. Hence a data object typically models an object type (cf. a UML class) of which multiple instances may exist in operational applications. An important exception is when a data object is used to model a data collection such as a database, of which only one instance exists.
An application function or process can operate on data objects. A data object may be communicated via interactions and used or produced by application services. A data object can be accessed by an application function, application interaction, or application service. A data object may realize a business object, and may be realized by an artifact. A data object may have association, specialization, aggregation, or composition relationships with other data objects. The name of a data object should preferably be a noun.
Figure 76: Data Object Notation
An Online Insurance Quotation data object is composed of three other data objects: Quoted Price, Terms and Conditions, and Certificate of Authenticity. Auto Insurance Quotation and Travel Insurance Quotation are two specializations of the Online Insurance Quotation data object. Travel Insurance Quotation contains an additional data object Purchased Itinerary.
Example 28: Application Passive Structure Elements
Table 7 gives an overview of the Application Layer elements, with their definitions.
Table 7: Application Layer Element
|
Element |
Definition |
Notation |
|
Application component |
An encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces. |
|
|
Application collaboration |
An aggregate of two or more application components that work together to perform collective application behavior. |
|
|
Application interface |
A point of access where application services are made available to a user, another application component, or a node. |
|
|
Application function |
Automated behavior that can be performed by an application component. |
|
|
Application interaction |
A unit of collective application behavior performed by (a collaboration of) two or more application components. |
|
|
Application process |
A sequence of application behaviors that achieves a specific outcome. |
|
|
Application event |
An application behavior element that denotes a state change. |
|
|
Application service |
An explicitly defined exposed application behavior. |
|
|
Data object |
Data structured for automated processing. |
|
Downloads of the ArchiMate documentation are available under license from the Download link within the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate documentation entirely for internal purposes. A book is also available from The Open Group Bookstore as document C179.
