Archimate Foundation

Introduction to ArchiMate® 3

• ArchiMate® is a visual Enterprise Architecture modeling language.

• It provides entities, relationships, and iconography for representing architecture descriptions.

• It includes concepts for specifying inter-related architectures and viewpoints for stakeholders.

• The ecosystem supports an XML exchange format for model and diagram exchange between tools.

• ArchiMate® differentiates between model elements and their notation for stakeholder-oriented depictions.

• It uses service-orientation to relate Business, Application, and Technology Layers.

Objectives of ArchiMate®

• The goal of ArchiMate® is to be an "umbrella" language that bridges the gap and creates integrated models with other modeling languages.

• It allows drilling down from Enterprise Architecture level to detailed models and vice versa.

• ArchiMate separates language concepts from notation, unlike UML or BPMN™.

• Different stakeholders require different notations for understanding architecture models.

The ArchiMate® Full Framework

• ArchiMate® Core Framework includes:

  • Layers: Business, Application, and Technology (including Physical elements)

  • Aspects: Active structure, Behavior, and Passive structure

• ArchiMate® Full Framework consists of:

  • ArchiMate® Core Framework

  • Strategy layer

  • Implementation & Migration layer

  • Motivation aspect

Top Level Language Structure

• Model

  • Concept

    • Element

      • Behavior Element

      • Structure Element

      • Motivation Element

      • Composite Element

    • Relationship

    • Connector

Enterprise Architecture and TOGAF

• ArchiMate complements the TOGAF framework by providing a vendor-independent set of concepts and a graphical representation.

• It helps create a consistent, integrated model that can be depicted in TOGAF views.

• The structure of the ArchiMate core language corresponds with the three main architectures in the TOGAF ADM.

• Strategy, motivation, implementation, and migration elements map onto the remainder of the ADM.

Layering in ArchiMate®

• A layer is an abstraction level in the ArchiMate framework for modeling an enterprise.

• The three core layers are:

  • The Business Layer

  • The Application Layer

  • The Technology Layer

• The general structure within core layers is similar, using the same types of concepts and relationships with differing granularity.

• In alignment with service-orientation, the most important relationship between layers is "serving" and "realization".

Abstraction in the ArchiMate® Language

• Distinction between external and internal views is common in system development.

• Distinction between behavior and active structure allows focus on what the system must do and how it does it.

• Distinction between conceptual, logical, and physical originates in data modeling.

ArchiMate® Views and Viewpoints

• ArchiMate® View definition:

  • A view is a part of an Architecture Description that addresses a set of related concerns and is tailored for specific stakeholders.

• ArchiMate® Viewpoints definition:

  • A viewpoint prescribes the concepts, models, analysis techniques, and visualizations provided by the view.

Definitions

• ArchiMate Core Framework:

  • A reference structure used to classify elements of the ArchiMate core language, consisting of three layers and three aspects.

• ArchiMate Core Language:

  • The central part of the ArchiMate language that defines the concepts to model Enterprise Architectures, including concepts from Business, Application, and Technology layers.

• Architecture View:

  • A representation of a system from the perspective of a related set of concerns.

• Architecture Viewpoint:

  • A specification of the conventions for a particular kind of architecture view.

• Aspect:

  • Classification of elements based on layer-independent characteristics related to stakeholder concerns (e.g., Active, Behavior, Passive).

• Attribute:

  • A property associated with an ArchiMate language element or relationship.

• Concept:

  • An element, a relationship, or a relationship connector.

• Conformance:

  • Fulfillment of specified requirements.

• Conforming Implementation:

  • An implementation satisfying the conformance requirements defined by the conformance clause of the standard.

• Core Element:

  • A structure or behavior element in one of the core layers of the ArchiMate language.

• Composite Element:

  • An element consisting of other elements from multiple aspects or layers of the language.

• Element:

  • Basic unit in the ArchiMate metamodel for defining and describing constituent parts of Enterprise Architectures.

• Layer:

  • An abstraction of the ArchiMate framework at which an enterprise can be modeled.

• Model:

  • A collection of concepts in the context of the ArchiMate language structure.

• Relationship:

  • A connection between a source and target concept, classified as structural, dependency, dynamic, or other.

• Relationship Connector:

  • A concept that connects two or more relationships of the same type.

Application Layer

• One of the three layers of the ArchiMate Core framework.

• Depicts application services that support the business and the applications that realize them.

Application Layer – Core Elements

• Includes Passive Structure Elements, Behavior Elements, and Active Structure Elements.

Application Component

• Represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable.

• Encapsulates behavior and data, exposes services, and makes them available through interfaces.

• A self-contained unit, independently deployable, reusable, and replaceable.

• An internal active structure element capable of performing behavior.

Application Collaboration

• Models a logical or temporary collaboration of application components and does not exist as a separate entity in the enterprise.

• Represents an aggregate of two or more application components that work together to perform collective application behavior.

• An internal active structure element that may be assigned to one or more application interactions or other application internal behavior elements.

Application Interface

• Specifies how the functionality of a component can be accessed by other elements.

• Exposes Application Services to the environment and specifies how the functionality of a component can be accessed by other elements.

• Represents a point of access where application services are made available to a user, another application component, or a node.

• The same application service may be exposed through different interfaces, and the same interface may expose multiple services.

• An external active structure element.

Example – Application Active Structure Elements

• 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”.

Application Process

• Represents a sequence of application behaviors that achieves a specific result.

• Describes the internal behavior performed by an application component that is required to realize a set of services.

• An application component may be assigned to an application process.

• An application process may access data objects.

• It’s an internal behavior element.

Application Function

• Represents automated behavior that can be performed by an application component.

• Describes the internal behavior of an application component.

• If this behavior is exposed externally, this is done through one or more services.

• Abstracts from the way it is implemented. Only the necessary behavior is specified.

• An application component may be assigned to an application function.

• An application function may access data objects.

• It’s an internal behavior element.

Application Interaction

• Represents a unit of collective application behavior performed by (a collaboration of) two or more application components.

• Specifies the joint behavior needed to realize an application service.

• An application collaboration of two or more individual application components may be assigned to an application interaction.

• An application interaction may realize application services.

• An application interaction may access data objects.

• It’s an internal behavior element.

Application Service

• Represents an explicitly defined exposed application behavior.

• Exposes the functionality of components to their environment.

• This functionality is accessed through one or more application interfaces and is realized by one or more application functions that are performed by the component.

• May serve business, application, and technology behavior or active structure elements.

• An application interface may be assigned to an application service. A application service may access data objects.

Application Event

• Represents an application state change.

• May trigger or be triggered (raised) by an application function, process, or interaction.

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

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

Example – Application Behavior Elements

• The “Purchase Travel Insurance” application function is composed of two other application functions: “Transfer Quotation”, realizing an application service “Get Quotation”, and “Finalize Purchase”, realizing an application service “Purchase Quoted Insurance”.

• These application functions model the behavior of the “Quotation” and “Purchase” application components of Example 27.

• An application event “Request for a Quotation” triggers an application process “Obtain Travel Insurance”, which is served by the two afore mentioned application services.

Data Object

• Represents data structured for automated processing.

• Should be a self-contained piece of information with a clear meaning to the business, not just to the application level.

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

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

Example – Application Passive Structure Elements

• 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”.

Relationships in ArchiMate

• Classification:

  • Structural relationships (static construction or composition)

  • Dependency relationships (support of elements)

  • Dynamic relationships (behavioral dependencies)

  • Other relationships (do not fit above categories)

• Ordering by "Strength":

  • Realization (weakest)

  • Assignment

  • Aggregation

  • Composition (strongest)

  • Association (weakest)

  • Influence

  • Access

  • Serving (strongest)

Composition Relationship

• Represents that an element consists of one or more other concepts.

• The interpretation of a composition relationship is that the whole or part of the source element is composed of the whole of the target element. If a composite is deleted, its parts are (normally) deleted as well.

• A composition relationship is always allowed between two instances of the same element type.

Aggregation Relationship

• Represents that an element combines one or more other concepts.

• The interpretation of an Aggregation relationship is that whole or part of the source element aggregates the whole of the target concept.

• Unlike composition, aggregation does not imply an existence dependency between the aggregating and aggregated concepts.

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

Assignment Relationship

• Represents the allocation of responsibility, performance of behavior, storage, or execution.

• The interpretation of an assignment relationship is that whole or part of the source element is assigned the whole of the target element.

• Links active structure elements with units of behavior, business actors with business roles, and nodes with technology passive structure elements.

• An assignment relationship can also be expressed by nesting the model elements.

Realization Relationship

• Represents that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity.

• Indicates that more abstract entities (“what” or “logical”) are realized by means of more tangible entities (“how” or “physical”).

• The interpretation is that the whole or part of the source element realizes the whole of the target element.

• Used to model run-time realization; for example, that a business process realizes a business service, and that a data object realizes a business object, an artifact realizes an application component, or a core element realizes a motivation element.

Serving Relationship

• Represents that an element provides its functionality to another element.

• Describes how the services or interfaces offered by a behavior or active structure element serve entities in their environment.

• Represents a control dependency.

Access Relationship

• Arrowheads denote read and/ or write access.

• Represents a data dependency.

• Represents the ability of behavior and active structure elements to observe or act upon passive structure elements.

• Indicates that a process, function, interaction, service, or event “does something” with a passive structure element.

Influence Relationship

• Represents that an element affects the implementation or achievement of some motivation element.

• Used to describe that some architectural element influences achievement or implementation of a motivation element.

• The influence relationship can also be used to model ‘horizontal’ contributions between motivation elements.

Triggering Relationship

• Represents a temporal or causal relationship between elements.

• The interpretation is that the source element should be completed before the target element can start.

• Used to model the temporal or causal precedence of behavior elements in a process.

Flow Relationship

• Represents transfer from one element to another.

• Used to model the flow of, for example, information, goods, or money between behavior elements.

• A flow relationship does not imply a causal relationship.

Specialization Relationship

• Represents that an element is a particular kind of another element.

• Inspired by the generalization relationship in UML class diagrams but applicable to specialize a wider range of concepts.

• Alternatively, a specialization relationship can be expressed by nesting the specialized element inside the generic element.

• A specialization relationship is always allowed between two instances of the same element.

Association Relationship

• Represents an unspecified relationship or one that is not represented by another ArchiMate relationship.

• Can be used when drawing a first high-level model where relationships are initially denoted in a generic way and later refined to show more specific relationship types.

• An association relationship is always allowed between two elements or between a relationship and an element.

Junction

• Used to connect relationships of the same type.

• A relationship connector rather than an actual relationship.

• May have multiple incoming relationships and one outgoing relationship, one incoming relationship and multiple outgoing relationships, or multiple incoming and outgoing relationships.

• Used to explicitly express that several elements together participate in the relationship (and junction) or that one of the elements participates in the relationship (or junction).

Semantics of Structural Relationships

• Represent the “static” coherence within an architecture.

• Element on the source side contains, groups, performs, or realizes the concept on the target side.

• Composition and aggregation relationships from parts also apply to the whole.

• Realization relationship to external behavior elements also apply to internal behavior elements.

Semantics of Dependency Relationships

• Describe how elements support or are used by other elements.

• Part of the target element has a dependency on part of the source element, but this does not necessarily mean that this applies to all parts of the elements.

• Part of an internal behavior element is served by some part of an external behavior element

• Part of a behavior element accesses some part of a passive structure element.

Derivation Rules

• Formal Derivation Rules purpose:

  • Abstract from intermediary elements that are not relevant to show in a model

  • Support impact analysis

  • Apply to Structural and Dependency Relationships with the exception of the motivation, strategy or implementation elements.

• Limitations:

  • Derivation rules do not work relationships between core and motivation, strategy and implementation & migration elements, with the exception realization and influence relationships

  • Derivation of relationships is intended as a way to create summaries of detail models. It is a way to remove from details in a model, while still making valid “statements”

• Derivation from Triggering and Structural Relationships

  • Triggering relationships are transitive

• Derivation from Dynamic Relationships
  DR 1: TRANSITIVITY OF SPECIALIZATION
  If two relationships $p(a,b):S$ and $q(b,c):S$ exist, with S being Specialization, then a relationship $r(a,c):S$ can be derived
  DR 2: DERIVATION BETWEEN STRUCTURAL RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(b,c):T$ exist, with S and T being structural relationships, then a relationship $r(a,c):U$ can be derived, with U being the weakest of S and T. Structural relationships are ordered by strength:
  DR 3: DERIVATION BETWEEN STRUCTURAL AND DEPENDENCY RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(b,c):T$ exist, with S being a structural relationship and T being a dependency relationship, then a relationship $r(a,c):T$ can be derived.
  DR 4: DERIVATION BETWEEN OPPOSING STRUCTURAL AND DEPENDENCY RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(c,b):T$ exist, with S being a structural relationship and T being a dependency relationship, then a relationship $r(c,a):T$ can be derived.
  DR 5: DERIVATION BETWEEN STRUCTURAL AND DYNAMIC RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(b,c):T$ exist, with S being a structural relationship and T being a dynamic relationship, then a relationship $r(a,c):T$ can be derived
  DR 6: DERIVATION BETWEEN STRUCTURAL AND FLOW RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(c,b):T$ exist, with S being a structural relationship and T being Flow, then a relationship $r(c,a):T$ can be derived.
  DR 7: DERIVATION BETWEEN STRUCTURAL AND TRIGGERING RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(b,c):T$ exist, with S being Triggering and T being a structural relationship, then a relationships $r(a,c):S$ can be derived.
  DR 8: DERIVATION BETWEEN TRIGGERING RELATIONSHIPS
  If two relationships $p(a,b):S$ and $q(b,c):S$ exist, with S being Triggering, then a relationship $r(a,c):S$ can be derived.

Business Layer

• One of the three layers of the ArchiMate Core framework

• Depicts business services offered to customers, realized by business processes and performed by business actors.

Business Layer Core Elements

• Passive Structure Elements: Business Object, Contract, Representation, Product

• Behavior Elements: Business Process, Business Function, Business Interaction, Business Service, Business Event

• Active Structure Elements: Business Actor, Business Role, Business Collaboration, Business Interface

• The active structure elements describe the organizational elements that execute the behavioral elements to achieve the business service (roles, actors and collaboration)

• The behavior elements describe the functionality required to deliver the product provided by a business service (processes, functions and interaction)

• The passive structure elements describe the objects that are used and/or created by the behavior elements (business objects and their representation)

Business Role

• Represents the responsibility for performing specific behavior to which an actor can be assigned, or the part an actor plays in a particular action or event.

• Assigned to business processes or business functions.

• Useful in a structural organizational sense; for instance, in the division of labor within an organization.

Business Actor

*A business entity that is capable of performing behavior

• May be assigned to one or more business roles. It can then perform the behavior to which these business roles are assigned

• Business actors may be specific individuals or organizations; e.g., “John Smith” or “ABC Corporation”, or they may be generic; e.g., “Customer” or “Supplier”

Business Collaboration

*A business collaboration represents an aggregate of two or more business active structure elements that work together to perform collective behavior.

• In some cases, behavior is the collective effort of more than one business role; in fact, a collaboration of two or more business roles results in collective behavior which may be more than simply the sum of the behavior of the separate roles. Business collaborations represent this collective effort.

• A business collaboration may aggregate a number of business roles, actors, or other collaborations and may be assigned to one or more business interactions or other business internal behavior elements.

Business Interface

*A business interface represents a point of access where a business service is made available to the environment.

• A business interface exposes the functionality of a business service to other business roles or actors. It is often referred to as a channel (telephone, Internet, local office, etc.). The same business service may be exposed through different interface

• A business interface may be part of a business role or actor through a composition relationship, and a business interface may serve a business role.

• A business interface may be assigned to one or more business services, which means that these services are exposed by the interface.

Business Process

*A business process represents a sequence of business behaviors that achieves a specific result such as a defined set of products or business services.

• A business process describes the internal behavior performed by a business role that is required to produce a set of products and services. For a consumer the products and services are relevant and the required behavior is merely a black box, hence the designation “internal”

• A business role may be assigned to a business process to perform this process manually. An automated business process can be realized by an application process

• Complex business process may be an aggregation of other, finer-grained processes. To each of these, finer-grained roles may be assigned

Business Function

*A business function represents a collection of business behavior based on a chosen set of criteria such as required business resources and/or competencies, and is managed or performed as a whole.
*Just like a business process, a business function also describes
internal behavior performed by a business role.
*Complex processes in general involve activities that offer various functions, forming a string of business functions
*In general, a business function delivers added value from a business point of view
*Organizational units or applications may coincide with business functions due to their specific grouping of business activities

Business Interaction

*A business interaction represents a unit of collective business behavior performed by (a collaboration of) two or more business actors, business roles, or business collaborations.
*A business interaction is similar to a business process/function,
but while a process/function may be performed by a single role,
an interaction is performed by a collaboration of multiple roles.
*A business interaction may be triggered by, or trigger, any other
business behavior element (business event, business process,
business function, or business interaction). A business interaction may access business objects.

Business Service

*A business service represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment.
*A business service should provide a unit of behavior that is meaningful from the point of view of the environment. It has a purpose which states this utility in terms of the value it delivers.
*Business services can be external, customer-facing services (e.g., a travel insurance service) or internal support services (e.g., a resource management service).
A business process, business function, or business interaction may realize a business service. A business interface may be assigned to a business service. A business service may access business objects.

Business Event

*A business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization
*Business behavior may be triggered or interrupted by a
business event; business processes may raise events that trigger other business behavior
*Events may originate from the environment of the organization (e.g., from a customer), but also internal events may occur generated by, for example, other processes within the organization
*Unlike business processes, functions, and interactions, a
business event does not have a duration. However, a business event may have a time attribute that denotes the moment or moments at which the event happens

Business Object

• Represents a concept used within a particular business domain.

• 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 business object typically models an object type (cf. a UML class) of which multiple instances may exist in operations.

• Business objects may be accessed (e.g., in the case of information objects, they may be created, read, or written) by a business process, function, business interaction, business event, or business service.

• A business object may have association, specialization, aggregation, or composition relationships with other business objects.

  Contract

  *A formal or informal specification of an agreement that specifies the rights and obligations associated with a product
  *The contract concept may be used to model a contract in the legal sense, but also a more informal agreement associated with a product

The provided note includes an introduction to ArchiMate® 3, its objectives, the ArchiMate® Full Framework, top-level language structure, its relation to TOGAF, layering, abstraction, views, and viewpoints, definitions of key terms, the application layer and its core elements, relationships in ArchiMate, business layer and its core elements. However, it doesn't cover topics such as the Technology Layer, Strategy Layer, Implementation & Migration Layer, Motivation aspect, and Example ArchiMate Views. Would you like me to generate the missing notes?