ArchiMate 3.0 Simplified

Introduction

ArchiMate is a modeling language that provides a uniform representation for diagrams that describe Enterprise Architectures. An Enterprise Architecture describes stakeholders concerns, motivation and strategy. When modeling an enterprise architecture there are three main layers you want to describe:

Business Layer: Describes the processes the business uses to meet its goals

Application layer: Describes how specific applications are designed and how they interact with each other,

Technology layer: Describes the hardware and software infrastructure that supports applications and their interactions

There are three other layers (strategy, physical, and implementation and migration) that I will not address here. The ArchiMate modeling language defines three types of elements that are used to represent all the layers (Business, Application, and Technology)

Elements that act (active elements or a structure) such as (business actors, application components, nodes, and interfaces). An Active element can be:

An internal active structure element represents an entity that is capable of performing behavior.

A collaboration is an aggregate of two or more active structure elements, working together to perform some collective behavior.

An interaction is a unit of collective behavior performed by (a collaboration of) two or more active structure elements

An external active structure element, called an interface, represents a point of access where one or more services are provided to the environment.

Elements that represent the behavior of those elements that act (behavioral elements) (service, event)

An internal behavior element represents a unit of activity performed by one or more active structure elements.

An external behavior element, called a service, represents an explicitly defined exposed behavior.

An event is a behavior element that denotes a state change

Elements that cannot act and which are acted upon by that behavior (passive elements) (information , data, physical object)

The distinction between behavior and active structure is commonly used to separate what the system must do and how the system does it from the system constituents (people, applications, and infrastructure) that do it. In modeling new systems, it is often useful to start with the behaviors that the system must perform, while in modeling existing systems, it is often useful to start with the people, applications, and infrastructure that comprise the system, and then analyze in detail the behaviors performed by these active structure

Another distinction is between conceptual, logical, and physical abstraction levels. This has its roots in data modeling: conceptual elements represent the information the business finds relevant; logical elements provide logical structure to this information for manipulation by information systems; physical elements describe the storage of this information; for example, in the form of files or database tables. In the ArchiMate language, this corresponds with business objects, data objects, and artifacts, and the realization relationships between them.

Business Layer Elements


Active Elements

  • Business Actor: is a business entity that is capable of performing behavior.
  • Business Role: is 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
  • Business Collaboration: is an aggregate of two or more business internal active structure elements that work together to perform collective behavior.
  • Business Interface: is a point of access where a business service is made available to the environment.

Behavioral Elements

  • Business Process: represents a sequence of business behaviors that achieves a specific outcome such as a defined set of products or business services.
  • Business Function: is a collection of business behavior based on a chosen set of criteria (typically required business resources and/or competences), closely aligned to an organization, but not necessarily explicitly governed by the organization
  • Business Interaction: is a unit of collective business behavior performed by (a collaboration of) two or more business roles.
  • Business Service: represents an explicitly defined exposed business behavior.
  • Business Event: is a business behavior element that denotes an organizational state change. It may originate from and be resolved inside or outside the organization.

Passive Elements

  • Product: represents a coherent collection of services and/or passive structure elements, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.
  • Representation: represents a perceptible form of the information carried by a business object.
  • Contract: represents a formal or informal specification of an agreement between a provider and a consumer that specifies the rights and obligations associated with a product and establishes functional and non-functional parameters for interaction.
  • Business Object : represents a concept used within a particular business domain

Application Layer Elements


Active Elements

  • 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
  • Application Collaboration: represents an aggregate of two or more application components that work together to perform collective application behavior.
  • Application Interface: represents a point of access where application services are made available to a user, another application component, or a node.

Behavioral Elements

  • Application Process: represents a sequence of application behaviors that achieves a specific outcome.
  • Application Function: represents automated behavior that can be performed by an application component.
  • Application Interaction: represents a unit of collective application behavior performed by (a collaboration of) two or more application components
  • Application Service: represents an explicitly defined exposed application behavior.
  • Application Event: is an application behavior element that denotes a state change.

Passive Elements

  • Data Object: represents data structured for automated processing.

Technology Layer Elements


Active Elements

  • Node: represents a computational or physical resource that hosts, manipulates, or interacts with other computational or physical resources.
  • Device: is a physical IT resource upon which system software and artifacts may be stored or deployed for execution.
  • System Software: represents software that provides or contributes to an environment for storing, executing, and using software or data deployed within it.
  • Technology Collaboration: represents an aggregate of two or more nodes that work together to perform collective technology behavior
  • Technology Interface: represents a point of access where technology services offered by a node can be accessed.
  • Path: represents a link between two or more nodes, through which these nodes can exchange data or material.
  • Communication Network: represents a set of structures and behaviors that connects computer systems or other electronic devices for transmission, routing, and reception of data or data-based communications such as voice and video.

Behavioral Elements

  • Technology Process: represents a sequence of technology behaviors that achieves a specific outcome.
  • Technology Function: represents a collection of technology behavior that can be performed by a node.
  • Technology Interaction: represents a unit of collective technology behavior performed by (a collaboration of) two or more nodes.
  • Technology Service: represents an explicitly defined exposed technology behavior.
  • Technology Event: is a technology behavior element that denotes a state change.

Physical Elements

  • Facility: represents a physical structure or environment.
  • Equipment: Equipment represents one or more physical machines, tools, or instruments that can create, use, store, move, or transform materials.
  • Distribution Network: represents a physical network used to transport materials or energy.
  • Material: tangible physical matter or physical elements.
  • Location: represents a geographic location.

Passive Elements

  • Technology Object: represents a passive element that is used or produced by technology behavior.
  • Artifact: represents a piece of data that is used or produced in a software development process, or by deployment and operation of an IT system.

Relationships

The ArchiMate language defines a core set of generic relationships, each of which can connect a predefined set of source and target elements, andin a few cases also other relationships). Many of these relationships exact meaning differs depending on the source and element that they connect.

Structural Relationships

Structural relationships represent the ‘static’ coherence within an architecture.

  • The composition relationship indicates that an element consists of one or more other elements. A composition relationship is always allowed between two instances of the same element type.
  • The aggregation relationship indicates that an element groups a number of other elements. An aggregation relationship is always allowed between two instances of the same element type.
  • The assignment relationship expresses the allocation of responsibility, performance of behavior, or execution.
  • The realization relationship indicates that an entity plays a critical role in the creation, achievement, sustenance, or operation of a more abstract entity.

Dependency Relationships

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

  • The serving relationship represents a control dependency, denoted by a solid line. The serving relationship models that an element provides its functionality to another element.
  • The access relationship represents a data dependency, denoted by a dashed line. The access relationship models the ability of behavior and active structure elements to observe or act upon passive structure elements.
  • The influence relationship is the weakest type of dependency, used to model how motivation elements are influenced by other elements. The influence relationship models that an element affects the implementation or achievement of some motivation element.

Dynamic Relationships

The dynamic relationships describe temporal dependencies between elements within the architecture. Two types of dynamic relationships are distinguished:

  • The triggering relationship represents a control flow between elements, denoted by a solid line. The triggering relationship describes a temporal or causal relationship between elements.

  • The flow relationship represents a data (or value) flow between elements, denoted by a dashed line. The flow relationship represents transfer from one element to another.

Other Relationships

  • The specialization relationship indicates that an element is a particular kind of another element.

  • An association models an unspecified relationship, or one that is not represented by another ArchiMate relationship.

  • A junction is used to connect relationships of the same type.

Further Readings

  • Open Group ArchiMate® 3.0 Specification
  • Enterprise Architecture at Work: Modeling, Communication, and Analysis, Third Edition, M.M. Lankhorst et al., Springer, 2013.
  • The Anatomy of the ArchiMate® Language, M.M. Lankhorst, H.A. Proper,H. Jonkers, International Journal of Information Systems Modeling and Design (IJISMD), 1(1):1-32, January-March 2010.
  • Extending Enterprise Architecture Modeling with Business Goals and Requirements, W. Engelsman, D.A.C. Quartel, H. Jonkers, M.J. van Sinderen,
  • Enterprise Information Systems, 5(1):9-36, 2011.
  • TOGAF® Version 9.1, an Open Group Standard (G116), December 2011, published by The Open Group; refer to: http://www.opengroup.org/bookstore/catalog/g116.htm.
  • TOGAF® Framework and ArchiMate® Modeling Language Harmonization: A Practitioner’s Guide to Using the TOGAF® Framework and the ArchiMate® Language, White Paper (W14C), December 2014, published by The Open Group; refer to: http://www.opengroup.org/bookstore/catalog/w14c.htm.
  • Unified Modeling Language®: Superstructure, Version 2.0 (formal/05-07-04), Object Management Group, August 2005.
Advertisements