EA Toolsets project : ArchiMate

ArchiMate

ArchiMate is a proposed standard for enterprise-architecture notation - see http://www.archimate.org and http://www.opengroup.org/archimate/doc/ts_archimate/

Its am is to be the equivalent of UML or BPMN but at a higher level, dealing with layered integration between business services and technology implementation.

It is one of the few notations that does cross between layers, but at present is still strongly IT-centric - i.e. no actual description of business drivers etc, beyond a somewhat limited concept of 'Meaning' and 'Value' (though see BizzDesign extensions at http://www.bizzdesign.nl and below).

Layering in Archimate

Archimate is based on the classic 'four architectures' used in TOGAF and so many other IT-centric frameworks, resulting in three distinct layers:

Business layer - in essence, somewhat better than the TOGAF-style 'anything not-IT that might impact on IT', but still firmly centred on the relationship between business and IT
Applications/Data layer ('Information Systems' layer in TOGAF) - IT-based applications and IT-based information
Technology Infrastructure layer - information-technology only

In line with service-oriented architecture, 'Service' entities are often used as an intermediate boundary-layer between each of these three layers:

Business Service - provides client/customer-oriented view or encapsulation of 'the business'
Application Service - provides a business-oriented view or encapsulation of IT applications and data
Infrastructure Service - provides an application-oriented view or encapsulation of the underlying IT-infrastructure

Below the Business layer, in essence Archimate has little or no knowledge of a world outside of IT. One side-result is that, as in TOGAF, everything 'not-IT' has to be bundled clumsily into the 'Business' layer.

In practice it is probably simplest to understand the Archimate 'layers' not as vertical layers in the Zachman sense, but as horizontal 'silos', each of which requires their own Zachman layering, and which between them only cover a small portion of the enterprise centred around IT.

Entities ('Concepts') in Archimate layers

Business layer

As in TOGAF, the 'business' layer is a blurred mixture of high-level strategy (rows 0-2), mid-level integration (rows 3-4) and manual and/or customer-facing sections of run-time implementation (rows 5-6).

Business Actor - agent, usually collective (e.g. department) [usage in Archimate is closer to a location>relational rather than agent, as it does not appear to incorporate capability]
Business Role - agent, usually individual, incorporating capability
Business Collaboration - abstract intersection of two or more Business Roles - "can be regarded as a kind of 'virtual role'" [always shown as the common root of a set of 'aggregation' relations]
Business Interface - interface, typically shown as bridge between an agent and a service (;horizontal' interface within the Business layer)
Business Function - abstract service encapsulates function and capability - typically shown containing one or more Business Process entities
Business Process - abstract process internal to the organisation (rather than a Business Service, which is an external outcome of activity) - may encapsulate sub-processes - is expected to be aligned with a single Business Role - its outcome is a defined set of Business Products and/or Business Services (see BizzDesign 'Deliverable')
Business Activity - (listed but not defined in Archimate standard) - probably abstract service and/or process enacted by an actor
Business Event - abstract event, with type not indicated (i.e. typically at row-3 or above)
Business Interaction - "a collaboration of two or more Business Roles" [as with Business Collaboration, this is typically shown as a root for aggregation relations - the distinction between this and Business Collaboration is far from clear]
Business Product - "a coherent set of services" - typically shown as an aggregation of Business Service linked to a Contract [this concept of 'product' is typical in information-centric industries - e.g. banking and insurance - but makes little or no sense in many others e.g. manufacturing or retail sale]
Contract - "a specification of an agreement" - composite of a record (asset>virtual probably with asset>physical), decision ('agreement', 'rights and obligations') and asset>aspirational ('belonging') linked to asset>relational (the parties to the agreement)
Business Service - abstract process as an external 'vertical' interface to Customer etc (i.e. a 'Deliverable') - "should be a verb ending in '-ing'"
Value - "that which makes some party appreciate a product or service" - implied as composite of decision ('makes'), asset>relational ('some party') and asset>aspirational ('appreciate') - typically shown attached (via 'association' relation) to a Business Service or Business Product
Meaning - "the knowledge or expertise present in the representation of a Business Object" - unclear, but probably an abstract/high-level asset>virtual, possibly also composite with decision - typically shown attached (via 'association' relation) to Representation
Representation - "the perceptible form of information", typically the physicalisation of information, i.e. composite of asset>virtual + asset>physical
Business Object - defined as information only, i.e. asset>virtual

Note that there is no means to describe manual processes other than at an abstract level, nor any direct means to describe non-information physical assets or relational assets. Physical and/or relational analogues of Business Object, Representation and Business Product will be needed to cover the full enterprise scope in most industries; also Value needs further clarification.

BizzDesign extensions
In their Architect toolset, BizzDesign provide a number of extensions to Archimate to anchor it more strongly into the context of the high-level business architecture. All of these extensions may only be linked to other entities in the model via Archimate 'association' relations.

Principle - generic decision>principle and/or >heuristic or >analytic, usable in any layer from row-1 to row-5
Architecture Principle - decision>principle (and, probably, decision>heuristic) applied to architecture itself
Guideline - generic decision>heuristic (e.g. in reference-model)
Business Goal - abstract decision linked via 'association' relation with a Program or Project [typically used as aggregation-by-enclosure for Goal entities]
Program - an aggregation or encapsulation of Project entities
Project - "a management environment that has been created to deliver one or more business products according to a specified business case" - (is probably simples to leave it outside of the categorisation schema, but in effect consists of a complex composite of process, role, event, asset, capability and so on; the project Deliverables probably should be recorded in terms of the categorisation schema, since they would deliver new capability, new asset, new function or service, and so on)
Deliverable - aggregation of Business Service and/or Business Product; also aggregation or encapsulation of capability (or service) and/or asset as end-product of a Project or Program
Goal - "a measurable requirement that is associated with a specific aspect of the organisation, and should be formulated SMART" - a composite of event + decision typically associated with a Project or Program
Effect - "a measurable phenomenon or aspect (changing or retaining the current situation) that has a quantifiable influence on a goal" - in effect, composite of asset>virtual ('measurable') and decision ('influence')
Period - a set of two or more location>abstract ('time') coordinates

Application/Data layer

This layer of Archimate is a straightforward IT-specific architecture: everything about 'Application' is in effect assumed to be IT, and the only assets used in functions are assumed to be information/data. It should be possible to re-use most of these concepts at a broader whole-of-enterprise scope, but the notation itself does not support it,and does not provide any means to distinguish between asset-types if we do so - which would be essential in multi-service load-balancing and in business-continuity/disaster-recovery planning.

Application Component - composite of actor>virtual, service>virtual and interface>virtual
Application Collaboration - aggregation of Application Component
Application Interface - "declares how a component can connect with its [virtual] environment" - 'horizontal' interface within the Application layer, but apparently only between service>virtual entities [there appears to be no concept here of a user-interface for a human actor, or of an interface to a physical machine]
Application Service - an exposed 'externally'-visible service>virtual ('vertical' interface)
Application Function - a service>virtual that is internal to a exposed service [in effect, equivalent of a 'private' method in UML]
Application Interaction - a collaborative 'behaviour' representing an abstract transaction-process between Application Components
Data Object - asset>virtual

Infrastructure (Technology) layer

This represents the real-world row-5/-6. As in TOGAF and FEAF, the Infrastructure layer at present applies solely to IT: there are no entities that can be used to describe directly what FEAF calls 'Human Capital' (real people, manual processes) or 'Other Fixed Assets' (non-IT machines, machine-based processes).

Artifact - "a physical piece of information" - asset>virtual + asset>physical, in essence identical to Business Object except that it occurs in the real-world row-5/-6 rather than the design-level row-3/-4
Communication Path - "a link between two or more Nodes, through which these may exchange information" - composite of two of location>virtual (often composite with location>physical and/or location>relational) with asset>virtual (content) and possibly asset>physical (e.g. cable)
Network - "a physical communication medium" - asset>physical associated with asset>virtual
Infrastructure Interface - a point of contact between two IT-capability roles ('horizontal' interface)
Infrastructure Service - an 'externally'-visible encapsulation of low-level IT asset>physical and/or asset>virtual and/or process>virtual ('vertical' interface)
Node - container for arbitrary composite of location (>virtual and/or >physical), asset (likewise >virtual and/or >physical) and service>virtual and/or process>virtual
System Software - in effect, aggregation of low-level service>virtual and/or process>virtual
Device - asset>physical, optionally also as container for aggregation of low-level service>virtual and/or process>virtual

Archimate relations

Archimate provides ten predefined relation-types, by intention conceptually similar to those defined in UML.

Specialization - as in UML, a class/sub-class relationship indicating a more specialised version of an abstract entity, which may also imply a realisation relationship
Composition - as in UML, a dependent relationship in which the 'children' are exclusive internal components of the 'parent', and do not have separate existence (i.e. cannot be used by other entities other than through the 'parent')
Aggregation - as in UML, a 'uses' relationship in which the 'children' are independent services used by the 'parent' (i.e. can be used directly by other entities)
Assignment - exclusive realisation - only the assigned entity will realise the requirements of the matching abstract entity (e.g. business-process is realised solely by IT-application)
Realisation - traverse down the Zachman layers from abstraction to real-world implementation (arrow points from realisation-entity to abstract-entity)
Triggering - trail of process execution, implies an event at each end of the link - often though not always also implies a matching parallel flow of assets
Flow - trail of asset movement, typically implying change to the asset
Used-by - link between Archimate layers, but actually at the same Zachman layer (e.g. at run-time, IT-application is used-by 'manual' business-process) - in effect, used to resolve the blurring of Zachman layers forced by the IT-centrism of the TOGAF-style 'four architectures as three layers'
Access - reference to an asset, usually without change to the asset
Association - general-purpose 'is associated with' relation - meaning is implied by entity-type, or must be described explicitly

Other Archimate entities

Archimate includes a small number of additional entities that (in principle) have no direct semantic meaning, such as Group, Junction and Note.

Group - an arbitrary grouping of entities for explanatory purposes
Junction - a branch-point on a 'flow' or 'triggering' relation between two entities, to reduce visual clutter in a model
- BizzDesign Architect also supports 'And Junction' and 'Or Junction' entities, which do have the respective implied semantic meanings for synchronisation of flows or triggers in process execution
Note - an arbitrary annotation for explanatory purposes