Element - ArchiMate®-Diagramme

Meaning is defined as the knowledge or expertise present in a business object or its representation, given a particular context.

A meaning is the information-related counterpart of a value: it represents the intention of a business object or representation (for example, a document, message; the representations related to a business object). It is a description that expresses the intent of a representation.

It is possible that different users view the informative functionality of a business object or representation differently.Also, various different representations may carry essentially the same meaning.

A meaning can be associated with a representation that carries this meaning.

The name of a meaning should preferably be a noun or noun phrase.

A business event is defined as something that happens (internally or externally) and influences behavior.

Business processes and other business behavior may be triggered or interrupted by a business event. Also, business processes may raise events that trigger other business processes, functions, or interactions. A business event is most commonly used to model something that triggers behavior, but other types of events are also conceivable; e.g., an event that interrupts a process. Unlike business processes, functions, and interactions, a business event is instantaneous: it does not have duration. 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. A business event may trigger or be triggered (raised) by a business process, business function, or business interaction. A business event may access a business object and may be composed of other business events.

The name of a business event should preferably be a verb in the perfect tense.

A business function is defined as a behavior element that groups behavior based on a chosen set of criteria (typically required business resources and/or competences).

Just like a business process, a business function also describes internal behavior performed by a business role. However, while a business process group’s behavior is based on a sequence or "flow" of activities that is needed to realize a product or service, a business function typically groups behavior based on required business resources, skills, competences, knowledge, etc.

In general, a business function delivers added value from a business point of view. A business function may be triggered by, or trigger, any other business behavior element (business event, business process, business function, or business interaction). A business function may access business objects. A business function may realize one or more business services and may use (internal) business services or application services. A business role or an application component may be assigned to a business function.

The name of a business function should preferably be a verb ending with "-ing" or a noun ending in "- ion" or "-ment"

A business object is defined as a passive element that has relevance from a business perspective.

Business objects represent the important “informational� or “conceptual� elements in which the business thinks about a domain. Generally, a business object is used to model an object type (cf. a UML class), of which several instances may exist within the organization. A wide variety of types of business objects can be defined. Business objects are passive in the sense that they do not trigger or perform processes. Business objects may be accessed (e.g., in the case of information objects, which are most common in the application domains in which ArchiMate is applied, they may be created, read, written) by a business process, function, a business interaction, a business event, or a business service. A business object may have association, specialization, aggregation, or composition relationships with other business objects. A business object may be realized by a representation or by a data object (or both).

The name of a business object should preferably be a noun.

A business process is defined as a behavior element that groups behavior based on an ordering of activities. It is intended to produce 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".

However, a complex business process may be an aggregation of other, finer-grained processes, each of which may be assigned to finer-grained roles that are aggregated by roles that are aggregated by the original role. There is a potential many-to-many relationship between business processes and business functions. Informally speaking, processes describe some kind of “flow� of activities, whereas functions group activities according to required skills, knowledge, resources, etc. A business process may be triggered by, or trigger, any other business behavior element (e.g., business event, business process, business function, or business interaction). A business process may access business objects. A business process may realize one or more business services and may use (internal) business services or application services. A business role or an application component may be assigned to a business process to perform this process manually or automated, respectively.

The name of a business process should preferably be a verb in the simple present tense.

A business interaction is defined as a behavior element that describes the behavior of a business collaboration.

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. The roles in the collaboration share the responsibility for performing the interaction. 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. A business interaction may realize one or more business services and may use (internal) business services or application services. A business collaboration or an application collaboration may be assigned to a business interaction. The name of a business interaction should preferably be a verb in the simple present tense.

A Business collaboration is defined as an aggregate of two or more business roles that work together to perform collective behavior.

A business process or function may be interpreted as the internal behavior assigned to a single business role. 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. Business interactions are used to describe the internal behavior that takes place within business collaboration. A collaboration is a (possibly temporary) collection of roles within an organization which perform collaborative behavior (interactions). Unlike a department, which may also group roles, a business collaboration does not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles.

A business collaboration may be composed of a number of business roles, and may be assigned to one or more business interactions. A business interface or an application interface may be used by a business collaboration, while a business collaboration may have business interfaces (through composition).

The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.

A contract is defined as 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.It may also be or include a Service Level Agreement (SLA), describing an agreement about the functionality and quality of the services that are part of a product. A contract is a specialization of a business object.The relationships that apply to a business object also apply to a contract. In addition, a contract may have an aggregation relationship with a product.

The name of a contract is preferably a noun.

A location is defined as a conceptual point or extent in space.

The location concept is used to model the distribution of structural elements such as business actors, application components, and devices. This is modeled by means of an assignment relationship from location to structural element. Indirectly, a location can also be assigned to a behavior element, to indicate where the behavior is performed.

A product is defined as a coherent collection of services, accompanied by a contract/set of agreements, which is offered as a whole to (internal or external) customers.

This definition describes financial, services-based, or information products that are common in information-intensive organizations, rather than physical products. A financial or information product consists of a collection of services, and a contract that specifies the characteristics, rights, and requirements associated with the product.

Generally, the product concept is used to specify a product type. A product may aggregate business services or application services,4 as well as a contract. A value may be associated with a product.

The name of a product is usually the name which is used in the communication with customers, or possibly a more generic noun.

A representation is defined as a perceptible form of the information carried by a business object.

Representations (for example, messages or documents) are the perceptible carriers of information that are related to business objects. If relevant, representations can be classified in various ways; for example, in terms of medium (electronic, paper, audio, etc.) or format (HTML, ASCII, PDF, RTF, etc.). A single business object can have a number of different representations. Also, a single representation can realize one or more specific business objects.

A representation may realize one or more business objects. A meaning can be associated with a representation that carries this meaning.

The name of a representation is preferably a noun.

A business role is defined as the responsibility for performing specific behavior, to which an actor can be assigned.

A business process or function may be interpreted as the internal behavior assigned to a single business role. 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. Business interactions are used to describe the internal behavior that takes place within business collaboration. A collaboration is a (possibly temporary) collection of roles within an organization which perform collaborative behavior (interactions). Unlike a department, which may also group roles, a business collaboration does not have an official (permanent) status within the organization; it is specifically aimed at a specific interaction or set of interactions between roles. However, a business collaboration can be regarded as a kind of "virtual role", hence its designation as a specialization of role. It is especially useful in modeling B2B interactions between different organizations.

A business collaboration may be composed of a number of business roles, and may be assigned to one or more business interactions. A business interface or an application interface may be used by a business collaboration, while a business collaboration may have business interfaces (through composition).

The name of a business collaboration should preferably be a noun. It is also rather common to leave a business collaboration unnamed.

A business interface is defined as 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 (provided interface), or expects functionality from other business services (required interface). It is often referred to as a channel (telephone, internet, local office, etc.). The same business service may be exposed through different interfaces. A business interface may be part of a business role through a composition relationship, which is not shown in the standard notation, and a business interface may be used by 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.

The name of a business interface should preferably be a noun.

A business service is defined as a service that fulfills a business need for a customer (internal or external to the organization).

A business service exposes the functionality of business roles or collaborations to their environment. This functionality is accessed through one or more business interfaces. A business service is realized by one or more business processes, business functions, or business interactions that are performed by the business roles or business collaborations, respectively.It may access business objects. A business service should provide a unit of functionality that is meaningful from the point of view of the environment. It has a purpose, which states this utility. The environment includes the (behavior of) users from outside as well as inside the organization. Business services can be external, customer-facing services or internal support services.

A business service is associated with a value. A business service may be used by a business process, business function, or business interaction. A business process, business function, or business interaction may realize a business service. A business interface or application interface may be assigned to a business service. A business service may access business objects.

The name of a business service should preferably be a verb ending with "-ing". Also, a name explicitly containing the word "service" may be used.

Value is defined as the relative worth, utility, or importance of a business service or product.

Value may apply to what a party gets by selling or making available some product or service, or it may apply to what a party gets by buying or obtaining access to it. Value can hold internally for some system or organizational unit, it is most typically applied to external appreciation of goods, services, information, knowledge, or money, normally as part of some sort of customer-provider relationship. A value can be associated with business services and, indirectly, with the products they are part of, and the roles or actors that use them. Although the name of a value can be expressed in many different ways (including amounts, objects), where the "functional" value of a service is concerned it is recommended to try and express it as an action or state that can be performed or reached as a result of the corresponding service being available.

A business actor is defined as an organizational entity that is capable of performing behavior.

A business actor performs the behavior assigned to (one or more) business roles. A business actor is an organizational entity as opposed to a technical entity; i.e., it belongs to the business layer. Actors may, however, include entities outside the actual enterprise; e.g., customers and partners. Examples of business actors are humans, departments, and business units. A business actor may be assigned to one or more business roles.

The name of a business actor should preferably be a noun.

A data object is defined as a passive element suitable for automated processing.

This concept is used in the same way as data objects (or object types) in wellknown 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.

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.

The name of a data object should preferably be a noun.

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

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.

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

The concept of application collaboration is 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. 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.

The name of an application collaboration should preferably be a noun.

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

The name of an application component should preferably be a noun.

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

The name of an application interface should preferably be a noun.

An application service is defined as a service that exposes automated behavior.

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". Also, a name explicitly containing the word "service" may be used.

An artifact is defined as a physical piece of data that is used or produced in a software development process, or by deployment and operation of a system.

An artifact represents a concrete element in the physical world. It is typically used to model (software) products such as source files, executables, scripts, database tables, messages, documents, specifications, and model files. An instance (copy) of an artifact can be deployed on a node. An application component or system software may be realized by one or more artifacts. A data object may be realized by one or more artifacts. A node may be assigned to an artifact (i.e., the artifact is deployed on the node). Thus, the two typical ways to use the artifact concept are as an execution component or as a data file. In fact, these could be defined as specializations of the artifact concept.

The name of an artifact should preferably be the name of the file it represents. An artifact may consist of sub-artifacts.

An infrastructure function is defined as a behavior element that groups infrastructural behavior that can be performed by a node.

An infrastructure function describes the internal behavior of a node; for the user of a node that performs an infrastructure function, this function is invisible. If its behavior is exposed externally, this is done through one or more infrastructure services. An infrastructure function abstracts from the way it is implemented. Only the necessary behavior is specified. An infrastructure function may realize infrastructure services. Infrastructure services of other infrastructure functions may be used by an infrastructure function.

An infrastructure function may access artifacts. A node may be assigned to an infrastructure function (which means that the node performs the infrastructure function).

The name of an infrastructure function should preferably be a verb ending with "-ing".

A device is defined as a hardware resource upon which artifacts may be stored or deployed for execution.

A device is a specialization of a node that represents a physical resource with processing capability. It is typically used to model hardware systems such as mainframes, PCs, or routers. Usually, they are part of a node together with system software. Devices may be composite; i.e., consist of sub-devices. Devices can be interconnected by networks. Artifacts can be assigned to (i.e., deployed on) devices. System software can be assigned to a device. A node can contain one or more devices.

The name of a device should preferably be a noun referring to the type of hardware. A device can consist of sub-devices. Different icons may be used to distinguish between different types of devices; e.g. mainframes and PCs.

A node is defined as a computational resource upon which artifacts may be stored or deployed for execution.

Nodes are active processing elements that execute and process artifacts, which are the representation of components and data objects. Nodes are, for example, used to model application servers, database servers, or client workstations. A node is often a combination of a hardware device and system software, thus providing a complete execution environment. These sub-nodes that represent the hardware devices and system software may be modeled explicitly or left implicit. Nodes can be interconnected by communication paths. Artifacts can be assigned to (i.e., deployed on) nodes.

The name of a node should preferably be a noun. A node can consist of sub-nodes. Artifacts deployed on a node may either be drawn inside the node or connected to it with an assignment relationship.

A communication path is defined as a link between two or more nodes, through which these nodes can exchange data.

A communication path is used to model the logical communication relations between nodes. It is realized by one or more networks, which represent the physical communication links. The communication properties (e.g., bandwidth, latency) of a communication path are usually aggregated from these underlying networks.

A communication path connects two or more nodes. A communication path is realized by one or more networks. A communication path is atomic.

A network is defined as a communication medium between two or more devices.

A network represents the physical communication infrastructure. This may comprise one or more fixed or wireless network links. The most basic network is a single link between two devices. A network has properties such as bandwidth and latency. It embodies the physical realization of the logical communication paths between nodes.

A network connects two or more devices. A network realizes one or more communication paths. A network can consist of sub-networks.

An infrastructure interface is defined as a point of access where infrastructure services offered by a node can be accessed by other nodes and application components.

An infrastructure interface specifies how the infrastructure services of a node can be accessed by other nodes (provided interface), or which functionality the node requires from its environment(required interface). An infrastructure interface exposes an infrastructure service to the environment. The same service may be exposed through different interfaces.

In a sense, an infrastructure interface specifies a kind of contract that a component realizing this interface must fulfill. This may include, for example, parameters, protocols used, pre- and postconditions, and data formats. An infrastructure interface may be part of a node through composition (not shown in the standard notation), which means that these interfaces are provided or required by that node, and can be used by other nodes. An infrastructure service can be assigned to an infrastructure interface, which exposes the service to the environment.

The name of an infrastructure interface should preferably be a noun.

An infrastructure service is defined as an externally visible unit of functionality, provided by one or more nodes, exposed through well-defined interfaces, and meaningful to the environment.

An infrastructure service exposes the functionality of a node to its environment. This functionality is accessed through one or more infrastructure interfaces. It may require, use, and produce artifacts.

An infrastructure 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, such as application components and nodes. Typical infrastructure services may, for example, include messaging, storage, naming, and directory services. It may access artifacts; e.g., a file containing a message.

An infrastructure service may be used by application components or nodes. An infrastructure service is realized by a node. An infrastructure service is exposed by a node by assigning it to its infrastructure interfaces. An infrastructure service may access artifacts.

The name of an infrastructure service should preferably be a verb ending with “-ing�. Also, a name explicitly containing the word "service" may be used. An infrastructure service may consist of sub-services.

System software represents a software environment for specific types of components and objects that are deployed on it in the form of artifacts.

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, a workflow engine, or COTS software such as ERP or CRM packages. Also, system software can be used to represent, for example, communication middleware. Usually, system software is combined with a device representing the hardware environment to form a general node. System software can be assigned to a device. Artifacts can be assigned to (i.e., deployed on) system software. A node can contain system software.

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

The grouping relationship indicates that objects belong together based on some common characteristic.

Similar to the UML package, the grouping relationship is used to group an arbitrary group of model objects, which can be of the same type or of different types. In contrast to the aggregation or composition relationships, there is no "overall" object of which the grouped objects form a part.

A goal is defined as an end state that a stakeholder intends to achieve.

In principle, an end can represent anything a stakeholder may desire, such as a state of affairs, or a produced value. Examples of goals are: to increase profit, to reduce waiting times at the helpdesk, or to introduce on-line portfolio management.

Goals are generally expressed using qualitative words; e.g., "increase", "improve", or "easier". Goals can also be decomposed; e.g., "increase profit" can be decomposed into the goals "reduce cost" and "increase sales". However, it is also very common to associate concrete objectives with goals, which can be used to describe both the quantitative and time-related measures which are essential to describe the desired state, and when it should be achieved.

A principle is defined as a normative property of all systems in a given context, or the way in which they are realized.

Principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context. A requirement defines a property that applies to a specific system.

A principle needs to be made specific for a given system by means of one or more requirements, in order to enforce that the system conforms to the principle. For example, the principle "Information management processes comply with all relevant laws, policies, and regulations" is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.

A principle is motivated by some goal. For example, the aforementioned principle may be motivated by the goal to maintain a good reputation and/or the goal to avoid penalties. The principle provides a means to realize its motivating goal, which is generally formulated as a guideline. This guideline constrains the design of all systems in a given context by stating the general properties that are required from any system in this context to realize the goal. Principles are intended to be more stable than requirements in the sense that they do not change as quickly as requirements may do. Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.

A requirement is defined as a statement of need that must be realized by a system.

In the end, a business goal must be realized by a plan or concrete change goal, which may or may not require a new system or changes to an existing system.

The term "system" is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again. Therefore, a system may refer to any active structural element, behavioral element, or passive structural element of some organization, such as a business actor, application component, business process, application service, business object, or data object.

Requirements model the properties of these elements that are needed to achieve the "ends" that are modeled by the goals. In this respect, requirements represent the "means" to realize goals.

During the design process, goals may be decomposed until the resulting sub-goals are sufficiently detailed to enable their realization by properties that can be exhibited by systems. At this point, goals can be realized by requirements that assign these properties to the systems.

For example, one may identify two alternative requirements to realize the goal to improve portfolio management: (i) by assigning a personal assistant to each customer, or (ii) by introducing on-line portfolio management. The former requirement can be realized by a human actor and the latter by a software application. These requirements can be decomposed further to define the requirements on the human actor and the software application in more detail.

A constraint is defined as a restriction on the way in which a system is realized.

In contrast to a requirement, a constraint does not prescribe some intended functionality of the system to be realized, but imposes a restriction on the way in which the system may be realized. This may be a restriction on the implementation of the system (e.g., specific technology that is to be used), or a restriction on the implementation process (e.g., time or budget constraints).

An assessment is defined as the outcome of some analysis of some driver.

An assessment may reveal strengths, weaknesses, opportunities, or threats for some area of interest. These outcomes need to be addressed by adjusting existing goals or setting new ones, which may trigger changes to the enterprise architecture. Strengths and weaknesses are internal to the organization. Opportunities and threats are external to the organization. Weaknesses and threats can be considered as problems that need to be addressed by goals that "negate" the weaknesses and threats. Strengths and opportunities may be translated directly into goals. For example, the weakness "customers complain about the helpdesk" can be addressed by defining the goal "improve helpdesk". Or, the opportunity "customers favor insurances that can be managed on-line" can be addressed by the goal "introduce on-line portfolio management".

The name of an assessment should preferably be a noun or a (very) short sentence.

A stakeholder is defined as the role of an individual, team, or organization (or classes thereof) that represents their interests in, or concerns relative to, the outcome of the architecture.

This definition is based on the definition in TOGAF [4].

A stakeholder has one or more interests in, or concerns about, the organization and its enterprise architecture. In order to direct efforts to these interests and concerns, stakeholders change, set, and emphasize goals. Examples of stakeholders are the CEO, the board of directors, shareholders, customers, business, and application architects, but also legislative authorities.

The name of a stakeholder should preferably be a noun.

A driver is defined as something that creates, motivates, and fuels the change in an organization.

Drivers may be internal, in which case they are usually associated with a stakeholder. Examples of internal drivers (or "concerns") are "Customer satisfaction", "Compliance to legislation", and "Profitability". Drivers of change may also be external; e.g., economic changes or changing legislation.

The name of a driver should preferably be a noun.

A work package is defined as a series of actions designed to accomplish a unique goal within a specified time.

A work package has a clearly defined beginning and end date, and a well-defined set of goals or results. The work package concept can be used to model projects, but also, e.g., sub-projects or tasks within a project, programs, or project portfolios.

A deliverable is defined as a precisely-defined outcome of a work package.

Work packages produce deliverables. These may be results of any kind; e.g., reports, papers, services, software, physical products, etc., or intangible results such as organizational change. A deliverable may also be the implementation of (a part of) an architecture.

A gap is defined as an outcome of a gap analysis between two plateaus.

A gap is an important outcome of a gap analysis in Phases B, C, and D of the TOGAF ADM, and forms an important input for the subsequent implementation and migration planning. The gap concept is linked to two plateaus (e.g., Baseline and Target Architecture, or two subsequent Transition Architectures), and represents the differences between these plateaus.

A plateau is defined as a relatively stable state of the architecture that exists during a limited period of time.

An important premise in TOGAF is that the various architectures are described for different stages in time. In each of the Phases B, C, and D of the ADM, a Baseline Architecture and Target Architecture are created, describing the current situation and the desired future situation. In Phase E (Opportunities and Solutions), so-called Transition Architectures are defined, showing the enterprise at incremental states reflecting periods of transition between the Baseline and Target Architectures. Transition Architectures are used to allow for individual work packages and projects to be grouped into managed portfolios and programs, illustrating the business value at each stage.

The Business Process viewpoint is used to show the high-level structure and composition of one or more business processes. Next to the processes themselves, this viewpoint contains other directly related concepts, such as:

- The services that a business process offers to the outside world, showing how a process contributes to the realization of the company’s products

- The assignment of business processes to roles, which gives insight into the responsibilities of the associated actors

- The information used by the business process Each of these can be regarded as a "sub-view" of the business process view.

A GAP Analysis View is primarily used to show the GAPs between different Versions of the Enterprise Architecture.

The goal realization viewpoint allows a designer to model the refinement of (high-level) goals into more concrete goals, and the refinement of concrete goals into requirements or constraints that describe the properties that are needed to realize the goals. The refinement of goals into subgoals is modeled using the aggregation relationship. The refinement of goals into requirements is modeled using the realization relationship. In addition, the principles may be modeled that guide the refinement of goals into requirements.

The implementation and migration viewpoint is used to relate programs and projects to the parts of the architecture that they implement. This view allows modeling of the scope of programs, projects, project activities in terms of the plateaus that are realized or the individual architecture elements that are affected. In addition, the way the elements are affected may be indicated by annotating the relationships. Furthermore, this viewpoint can be used in combination with the programs and projects viewpoint to support portfolio management:

- The programs and projects viewpoint is suited to relate business goals to programs and projects. For example, this makes it possible to analyze at a high level whether all business goals are covered sufficiently by the current portfolio(s).

- The implementation and migration viewpoint is suited to relate business goals (and requirements) via programs and projects to (parts of) the architecture. For example, this makes it possible to analyze potential overlap between project activities or to analyze the consistency between project dependencies and dependencies among plateaus or architecture elements.

The Information Structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying infrastructure; e.g., by means of a database schema.

The Infrastructure Usage viewpoint shows how applications are supported by the software and hardware infrastructure: the infrastructure services are delivered by the devices; system software and networks are provided to the applications. This viewpoint plays an important role in the analysis of performance and scalability, since it relates the physical infrastructure to the logical world of applications. It is very useful in determining the performance and quality requirements on the infrastructure based on the demands of the various applications that use it.

A project viewpoint is primarily used to model the management of architecture change. The "architecture" of the migration process from an old situation (current state enterprise architecture) to a new desired situation (target state enterprise architecture) has significant consequences on the medium and long-term growth strategy and the subsequent decisionmaking process. Some of the issues that should be taken into account by the models designed in this viewpoint are:

- Developing fully-fledged organization-wide enterprise architecture is a task that may require several years.

- All systems and services must remain operational regardless all the presumable modifications and changes of the enterprise architecture during the change process.

- The change process may have to deal with immature technology standards (e.g., messaging, security, data, etc.).

- The change has serious consequences for the personnel, the culture, the way of working, and the organization.

Furthermore, there are several other governance aspects that might constrain the transformation process, such as internal and external co-operation, project portfolio management, project management (deliverables, goals, etc.), plateau planning, financial and legal aspects, etc.

The requirements realization viewpoint allows the designer to model the realization of requirements by the core elements, such as business actors, business services, Business processes, application services, application components, etc. Typically, the requirements result from the goal refinement viewpoint.

In addition, this viewpoint can be used to refine requirements into more detailed requirements. The aggregation relationship is used for this purpose.

The assignment relationship links active elements (e.g., business roles or application components) with units of behavior that are performed by them, or business actors with business roles that are fulfilled by them.

The assignment relationship can relate a business role with a business process or function, an application component with an application function, a business collaboration with a business interaction, an application collaboration with an application interaction, a business interface with a business service, an application interface with an application service, or a business actor with a business role.

Alternatively, an assignment relationship can be expressed by nesting the model elements.

The specialization relationship indicates that an object is a specialization of another object.

The specialization relationship has been inspired by the generalization/specialization relationship in UML class diagrams, but is applicable to specialize a wider range of concepts. The specialization relationship can relate any instance of a concept with another instance of the same concept.

Specialization is always possible between two instances of the same concept.

An association models a relationship between objects that is not covered by another, more specific relationship.

Association is mainly used, as in UML, to model relationships between business objects or dataobjects that are not modeled by the standard relationships aggregation, composition, or specialization. In addition to this, the association relationship is used to link the informational concepts with the other concepts: a business object with a representation, a representation with a meaning, and a business service with a purpose.

The composition relationship indicates, that an object is composed of one of more other objects. Composition is always possible between two instances of the same concept. Alternatively, a composition relationship can be expressed by nesting the model elements.

The aggregation relationship indicates that a concept groups a number of other concepts. Aggregation is always possible between two instances of the same concept. Alternatively, an aggregation relationship can be expressed by nesting the model elements.

The realization relationship links a logical entity with a more concrete entity that realizes it.

The realization relationship indicates how logical entities ("what"), such as services, are realized by means of more concrete entities ("how2).

The realization relationship is used in an operational sense (e.g., a process/function realizes a service), but also in a design/implementation context (e.g., a data object may realize a business object, or an artifact may realize an application component).

The triggering relationship describes the temporal or causal relationships between processes, functions, interactions, and events.

The triggering relationship is used to model the causal relationships between behavior concepts in a process. No distinction is made between an active triggering relationship and a passive causal relationship.

The used by relationship models the use of services by processes, functions, or interactions and the access to interfaces by roles, components, or collaborations.

The used by relationship describes the services that a role or component offers that are used by entities in the environment. The used by relationship is applied for both the behavior aspect and the structure aspect.

The flow relationship describes the exchange or transfer of, for example, information or value between processes, function, interactions, and events.

The flow relationship is used to model the flow of, for example, information between behavior concepts in a process. A flow relationship does not imply a causal or temporal relationship.