[ 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

Events

Decisions

More composites

Many if not most 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
• service - composite of function and capability

---

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