[ OsEATools | MetaModel | Metamodel - real-world examples | Categories ]

---

Metamodel - real-world examples

Rows - layers of abstraction

Each of the seven rows represents a layer of abstraction (see rows).

The following ArchiMate relations are allowed between rows:

• realization - each abstraction needs to be 'realized' by entities in the layers below (i.e. realizations always occur 'downward' between the layers)
• specialization - some specializations are also realizations, in that they 'realize' an abstract class (such specializations also move 'downward' between layers - though note that unlike realizations, specializations may also occur within a layer)
• association - association is the general 'none of the above' relation in ArchiMate, with a semantic meaning that must be explicitly assigned - in some cases these may traverse between layers

Other ArchiMate relations (triggering, flow, aggregation, composition, assignment, used by, access) are allowed only within a row.

Columns and segments - primitives and base-composites

All of the columns (see columns) are abstractions. True primitives within a column may exist in the higher layers (row-0 to row-2 and sometimes row-3), but as we move towards the real world even entities which exist within a single column must be linked with one or more appropriate category-segments (see type or skill) as base-composites.

A primitive cannot be split any further; a composite may be split and recombined in other ways (in theory, at least, if not always in practice). Recombination enables redesign.

The Archimate relations may be used within and between columns as per the Archimate specification.

Assets

An asset is an entity (or Concept, in the Archimate base-ontology) for which the organisation is responsible and which it may access or use in functions. (A liability is an asset which has, for the moment, been assigned a negative value, and/or is required to be available to transfer to others at some future time.)

Assets are inputs and/or outputs to functions.

An asset would generally be described as a noun (either 'passive structure' or 'active structure', in Archimate terms).

Some examples:

• device (computer, vehicle, machine-tool etc) - asset>physical, with implied capability of at least the same category
• data - asset>virtual, also in narrative form as information held by person, as asset>virtual+relational
• paper form - asset>physical+asset>virtual
• person - implied via asset>relational, usually also assigned to some role (note: it is the relationship with the person that is the asset, not the actual person - by intent, real persons do not fit direct directly into this categorisation schema, and should never be described directly as 'assets')
• customer record - data about relation, hence asset>virtual <- asset>relational
• reputation - desire to 'belong', hence asset>aspirational + asset>relational
• morale - as for reputation, hence asset>aspirational/+asset>relational, but interlinked with capability as 'ability to do work'
• value - as for reputation, directed towards any other entity (any combination of asset, function, location, capability, event, decision)
• meaning - as for reputation, but interlinked with asset>virtual and/or decision
• money - assigned as asset>abstract (technically is a numeric measurement of belief - i.e. complex of asset>virtual and asset>aspirational with decision - but simplest to use the 'common-sense' view of describing it as an asset)

Note that time is not an asset, because it cannot be changed by a function, and cannot be the exclusive reponsibility of the organisation. (Time is best understood as a location.)

Functions

A function is a point where one or more assets may be created, referenced ('read'), amended ('updated') or destroyed - in other words, where change takes place.

A function would usually be described via a verb ('behaviour', in Archimate terms).

Each function is triggered by an event; its completion is marked by an event; and may in turn trigger other events.

Each function requires the availability of one or more capabilities to enact the work of the function.

Each function will be guided by decisions (e.g. as algorithms or 'business-rules') and should always be associated with decisions about business-purpose.

Each function will also occur in or at a location, but this is usually not an emphasis in discussions about functions themselves.

Some examples:

• manufacture bottle - function>physical
• update insurance record - function>virtual
• receive inbound goods at warehouse - function>physical with implied/embedded function>virtual for to record the goods-transfer
• make sales call - function>relational, also with implied function>virtual to update customer-records
• deliver marketing campaign - function>aspirational (because emphasis is on reputation and brand, rather than person-to-person as in sales)
• exchange currency - function>abstract in a monetary context
• assess valuation - complex of function>aspirational (perceived value) and function>abstract (e.g. monetary price)

Function, process and service are often confused with each other, especially when layers of abstraction are blurred together. The simplest way to distinguish them is that a function is a point at which assets may change; a service is an identified composite of function and capability for a specified purpose; and a process is a choreographed sequence ('flow' and 'triggering' in Archimate terms) of services to enable a business-purpose at a higher level of abstraction.

Locations

A location is a point or region within one or more identified coordination-schemas. There are an infinite number of possible location-schemas: only a small subset of these will be relevant to an organisation, though in a full enterprise architecture this set may be considerably broader that might at first be expected.

A location would usually be described as a noun ('passive structure', in Archimate terms). It is distinct from asset in that it is always somewhat abstract, and it is not in itself the responsibility of the organisation (though assets at a location may well be).

A location-schema usually implies that, to the organisation, a location would usually be linked to respective information (i.e. asset>virtual etc) to identify that location within the frame of the schema.

Some examples:

• geographic location - location>physical
• URI (uniform resource indicator) - location>virtual
• IP address - location>virtual
• network location - location>virtual + location>physical
• postcode or zip-code - location>virtual mapped to location>physical
• building-number or room-number - location>virtual mapped to location>physical
• reporting-relationship - location>relational
• social-network node - location>relational
• membership of market segment - location>relational mapped to location>physical and/or location>aspirational
• time - location>abstract

Capabilities

A capability combines two types of segments: the asset-types on which the capability may act (hence capability), and the skill-level (closely aligned to decision-types), which identifies the competence required.

In practice, a capability is always linked with a function (because without it, the capability literally has no function); the combination is commonly described as a service.

A capability is usually associated with or embedded in an agent, which may be any combination of physical (a machine), virtual (IT, which ultimately must also resolve to a physical machine) and/or relational (either individual - i.e. link to a real person - or collective - which would thus also imply an aspirational component).

A cluster of related capabilities is often described as a role.

Some examples:

• ability to machine metal - capability>physical
• ability to store and retrieve records (e.g. a database) - capability>virtual, but may also include >physical (e.g. paper records) and/or >relational (e.g. narrative knowledge)
• ability to manage customer relationships - capability>relational
• ability to inspire 'belonging' (e.g. via brand, marketing) - capability>aspirational
• ability to conduct financial transactions - capability>virtual + capability>abstract

Note that the skill-level for the capability also identifies the asset/function-types through which the work can be performed:

• rule-based, real-time; training, 'novice' - machine, IT, human (though note that humans tend to be inconsistent in following rigid rule-based structures)
• analysis, often post-action or delayed-time rather than real-time; 'apprentice', 'best-practice' - IT, human; often difficult to impossible with physical-only machines
• heuristics and guidelines, often iterative and experimental; 'journeyman', 'worst-practice' - usually human only, drawing from true skill and experience; IT usually in decision-support role only; almost impossible to implement with physical-only machines
• principle-based, real-time; 'master' - can only be done by humans with very high levels of skill and experience; cannot be enacted successfuly with IT alone

See also decision-types below: attempting to use a capability that does not or cannot match the skill-level required for the decision-types leads to incompetent decision-making, which in turn guarantees failure to eachieve the desired goals.

Events

An event is a point of change in context that is deemed significant (i.e. related to a decision), and usually indicates a choice-point for a decision to start or end some activity (often a function, service or process/).

An event will often be accompanied by a change in an associated asset and/or location, such as the arrival of a message or physical object, or arrival at an airport. For this reason, it is simplest to categorise events with the respective asset-type segment, as these are used for both assets and locations.

Some examples:

• trip of mechanical sensor - event>physical
• message-event, data-signal - event>virtual
• rule-event, algorithmic event (BPMN error, cancel, terminate, compensation) - event>virtual+event>aspirational (because there is an implied purpose to the event)
• sales-event - event>relational+event>aspirational (sales impacts on marketing, which is about 'belonging')
• merger, demerger or restructure of organisation - event>aspirational (impacts on 'belief and belonging')
• timer-event - event>abstract

Note that whilst events may occur in time, most events are not of time - the distinction may seem subtle, but is important.

Decisions

More composites

Many real-world entities are complex composites that straddle two or more columns.

Some examples:

• actor or agent - composite of asset (usually physical and/or human via relational) and capability
• role - cluster of related capabilities linked to a specific business-purpose (decision)
• service - composite of function and capability
• process - choreographed sequence of services, which may itself be viewed as an abstract function and/or service
• application - capability bundled with agent (typically an IT-based agent) that presents interfaces for a set of services and/or processes
• interface - a point of contact between agents, usually to perform specific roles

---

[ OsEATools | MetaModel | Metamodel - real-world examples | Categories ]