EA Toolsets project : MetaExamples

HomePage :: PageIndex :: Guest Logon
[ ^^ OsEATools | ^ MetaModel | Metamodel - real-world examples | Archimate examples | TOGAF examples | Categories ]

Metamodel - real-world examples

The following sections provide a brief(ish) overview of how the categorisation works in conjunction with the core metamodel.

Clarity around where a model entity sits in relation to the layers helps to identify the probable direct stakeholders in any architectural or design decision. The direction of concern also helps to clarify the distinction between architecture and design: architecture looks 'upward', design looks 'downward'.

Clarity around which column/segment categories apply, and the underlying components of composites, also simplifies the process of architectural restructure and redesign. This is because these identify opportunities for substitution of asset, function, agent, capability, location etc, whilst still conforming to the same overall decisions, or aligning to the requirements implied or mandated by changed decisions or constraints. Some contexts may require extreme substitutions - such as replacing manual proceses with IT-based ones in process-reengineering, or IT-based processes with manual ones in disaster-recovery planning. Without awareness of the possibilities implied by the categorisation structure, such substitutions would likely seem 'impossible' to implement or even to imagine - thus risking loss of effectiveness for the organisation. By identifying the role and function of each type of entity within the terms of categories, the metamodel and its derived models indicate what is substitutable and what is not, enhancing the opportunities for improved organisational effectiveness.

Rows - layers of abstraction

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

The following ArchiMate relations are allowed between rows:

Other ArchiMate relations (triggering, flow, aggregation, composition, 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:

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:

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:

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:

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

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:

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

Decisions

A decision or reason is a choice - ultimately made by one or more real persons, either directly or by proxy via a machine or IT-system - to guide and direct the organisation within its shared enterprise.

In the upper layers, decisions define the organisation's understanding of and relationship with the enterprise. At the topmost layer ('Universals'), all decisions come down to a "Because." - in essence, a non-negotiable and ultimately non-rational choice. A trail of decisions and reasons devolve downward from these core choices: ultimately, it must be possible to trace every decision in the entire organisation back to one or more of those core choices.

A constraint is a choice imposed on the organisation from outside, elsewhere in the shared enterprise: examples include law and regulation, technical and other standards, and practical limitations imposed by the physical or other environment, or by limited availability of assets, locations, capabilities and, in some cases, events.

The semantic meanings derived from an architecture are the outcome of decisions about what is deemed meaningful and what is not. Technically speaking, every relation identified between entities in an enterprise architecture represents a decision of some kind (i.e. a decision that the relation exists).

In classic IT-centric 'enterprise architecture', all such decisions are constrained to conform to a simple true/false logic. Whilst this may be sufficient for describing the internal structure of software architecture, it is not sufficient for modelling business-architecture, in which modal logics of possibility, probability and necessity (such as the 'MoSCoW' set used in Agile requirements: Must, Should, Could, can Wait) will all play a part - and likewise the non-logical and/or non-rational decision-making processes involved in marketing, in innovation and in strategy-development.

The simplest categorisation is that used for skill-types:

Note that principles are the expression ('realization') of values. Principles will be layered right the way through from row-1 'core principles' to row-5 'principles underlying production policy', such as the run-time application health-and-safety policy, customer-relation policy, security policy, environmental policy etc. Values form the row-0 anchor for such trails; in row-6 the principles should have already been applied in practice, and should be verified/audited as such.

More composites

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

Some examples:

[ OsEATools | MetaModel | Metamodel - real-world examples | Archimate examples | TOGAF examples | Categories ]
There is no comment on this page. [Display comments/form]
2009-05-25 16:51:05 XML :: Owner: TomG :: Search: