Figure 26 gives an overview of the application layer concepts and their relationships. Many of the concepts have been inspired by the UML 2.0 standard [7], [10], as this is the dominant language and the de facto standard for describing software applications. Whenever applicable, we draw inspiration from the analogy with the business and application layer.
Figure 26: Application Layer Metamodel
Note: This figure does not show all permitted relationships: every concept in the language can have composition, aggregation, and specialization relationships with concepts of the same type; furthermore, there are indirect relationships that can be derived as explained in Section 7.5.
The main active structure concept for the application layer is the application component. This concept 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 2.0 component, our component concept strictly models the structural aspect of an application: its behavior is modeled by an explicit relationship to the behavioral concepts.
Also in application architecture, the inter-relationships of components are an essential ingredient. Therefore, we also introduce the concept of application collaboration here, defined as a collective of application components which perform application interactions. The concept is very similar to the collaboration as defined in the UML 2.0 standard [7], [10].
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 2.0 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. A distinction may be made between a provided interface and a required interface. The application interface concept 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 is defined as a modular, deployable, and replaceable part of a software system that encapsulates its behavior and data and exposes these through a set of interfaces.
An application component is a self-contained unit of functionality. 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. Co-operating application components are connected via application collaborations.
An application component may be assigned to one or more application functions, business processes, or business functions. An application component has one or more application interfaces, which expose its functionality. Application interfaces of other application components may be used by an application component. The name of an application component should preferably be a noun.
Figure 27: Application Component Notation
Example
In the model below, a financial application is depicted as an application component consisting of two subcomponents for accounting and billing, each of which offers an application service to the environment. These services are accessible through a shared accounting & billing application interface, which is part of the financial application.
Example 17: Application Component
An application collaboration is defined as an aggregate of two or more application components that work together to perform collective behavior.
An application collaboration specifies which components co-operate 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.
An application collaboration is a specialization of a component, and aggregates two or more (co-operating) application components. An application collaboration is an active structure element that may be assigned to one or more application interactions or business interactions, which model the associated behavior. An application interface may be used by 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 28: Application Collaboration Notation
Example
In the model below, two components collaborate in transaction administration: an Accounting component and a Billing component. This collaboration performs the application interaction Administrate transactions.
Example 18: Application Collaboration
An application interface is defined as a point of access where an application service is made available to a user or another application component.
An application interface specifies how the functionality of a component can be accessed by other components (provided interface), or which functionality the component requires from its environment (required interface). An application interface exposes an application service to the environment. The same application service may be exposed through different interfaces.
In a sense, an application interface specifies a kind of contract that a component realizing 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 (not shown in the standard notation), which means that these interfaces are provided or required by that component, and can be used by other application components. An application interface can be assigned to application services or business services, which means that the interface exposes these services to the environment. The name of an application interface should preferably be a noun.
Figure 29: Application Interface Notation
Example
In the model below, an Accounting component is shown that provides an application interface for Transaction data exchange, and a Billing component that requires such an interface.
Example 19: Application Interface
Behavior at the application layer can be described in a way that is very similar to business layer behavior. Also here, we make a distinction 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 functionality, provided by one or more components, exposed through well-defined interfaces, and meaningful to the environment. The service concept 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 the current developments in the area of web services. 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, a separate “application flow” concept is conceivable as the 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 is defined as a behavior element that groups 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 infrastructure services may be used by 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 30: Application Function Notation
Example
In the model below, the internal behavior of the Financial application component is modeled as an application function consisting of two sub-functions. These application functions realize the application services that are made available to the users of the application.
Example 20: Application Function
An application interaction is defined as a behavior element that describes the behavior of an application collaboration.
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, e.g., 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 infrastructure services may be used by an application interaction. An application interaction may access data objects. The name of an application interaction should preferably be a verb.
Figure 31: Application Interaction Notation
Example
In the model below, an Accounting component and a Billing component of a financial system co-operate to compose an administrate transactions interaction. This is modeled as an application interaction assigned to the collaboration between the two components.
Example 21: Application Interaction
An application service is defined as a service that exposes automated 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 functionality 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 be used by 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 32: Application Service Notation
Example
In the model below, a Transaction processing (application-to-application) service is realized by the Accounting application function, and is accessible by other components through a Transaction processing application programming interface (API). This service is used by the Billing application function performed by the Billing component.
The Billing application function offers an (application-to-business) function Bill creation, which can be used to support business processes, and is accessible to business roles through a Billing screen as an application-to-business interface.
Example 22: Application Service
Also at the application layer, we distinguish the passive counterpart of the component, which we call a data object. This concept 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 concept in the business layer. The ArchiMate language does not define a specific layer for information; however, concepts 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 is defined as a passive element suitable for automated processing.
An application function operates on a data object. A data object may be communicated via interactions and used or produced by application services. It 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.
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 33: Data Object Notation
Example
In the model below, two application functions co-operate via an application service, in which a data object holding Transaction data is exchanged.
Example 23: Data Object
Table 2 gives an overview of the concepts at the application layer, with their definitions.
Table 2: Application Layer Concepts
|
Concept |
Definition |
Notation |
|
Application component |
A modular, deployable, and replaceable part of a software system that encapsulates its behavior and data and exposes these through a set of interfaces. |
|
|
Application collaboration |
An aggregate of two or more application components that work together to perform collective behavior. |
|
|
Application interface |
A point of access where an application service is made available to a user or another application component. |
|
|
Application function |
A behavior element that groups automated behavior that can be performed by an application component. |
|
|
Application interaction |
A behavior element that describes the behavior of an application collaboration. |
|
|
Application service |
A service that exposes automated behavior. |
|
|
Data object |
A passive element suitable for automated processing. |
|
Downloads of the ArchiMate documentation, are available under license from the ArchiMate information web site. The license is free to any organization wishing to use ArchiMate entirely for internal purposes (for example, to develop an information system architecture for use within that organization). A book is also available (in hardcopy and pdf) from The Open Group Bookstore as document C13L.
