EA in bOwls (Overview)

Preamble

From a strategic perspective, the digital transformation implies the merging of knowledge and systems architectures and consequently a seamless representation of contexts (data), processes and supporting systems (information), and objectives and strategies (knowledge). That can be best achieved with ontologies.

Ontologies take a special significance for enterprise architecture which, in contrast to systems’ architecture, must maintain a continuous and consistent representation of business environments and objectives.

Ontologies are especially relevant for requirements, when business analysts, project managers, and system architects have to agree about scope (domain or architecture), and development model (Agile or phased).

As a proof of concept, the Caminao Kernel (CaKe) uses the Stanford OWL 2/Protégé environment to provide an open and ecumenical platform for EA ontologies. That kernel is meant to be formal (based on axioms and non-circular definitions) and neutral (no assumption regarding modeling languages). EA ontologies developed with that kernel can thus serve two key purposes:

Quality assurance: OWL 2 primitives can be used to develop general and targeted procedures to check the consistency of representations
Engineering: domain- and platform-specific interfaces can be developed to ensure a seamless integration with organizational and technical environments

A first version of the Caminao Kernel can be consulted online on the Protégé website with the link CaKe_WIPg, or with a case study: A Diner in bOwls. That EA perspective can be compared to more generic approaches, e.g., the Gist ontology developed by Semantic Arts. For a more recent version: CaKe 4.0.

Organization

ONTOLOGIES, MODELS, & THESAURUSES

The contents of ontologies can be formally defined in terms language, models and thesaurus:

Thesauruses define the meaning of terms, categories, and concepts.
Models add syntax to build representations of contexts and concerns.
Ontologies add pragmatics in order to put models in broader perspectives.

These levels correspond to the epistemic nature of the targeted elements:

Concepts: pure semantic constructs defined independently of instances or categories.
Categories: symbolic descriptions of sets of objects or phenomena: Categories can be associated with instances of individuals in environments (descriptive, extensional) or instances of surrogates in systems (prescriptive, intensional).
Aspects: descriptions without external instances of their own: Aspects cannot be directly instantiated (or identified) in environments; they can only exist as digital components in systems.
Documents: entries for documents represent the symbolic contents, with instances representing the actual (or physical) documents.

Besides concepts and documents, which correspond to thesaurus and content management systems (CMS), the backbone of the kernel is built around categories of actual and symbolic entities.

OWL 2 Hierarchies

The Caminao kernel (or Cake) is built around four kinds of things (in OWL 2 parlance), plus one for individuals, corresponding to the epistemic nature of targeted elements. As to ensure complete neutrality, the semantics of hierarchies (yellow color) is purely conceptual, i.e. the lower levels can be defined in terms of the upper ones.

Aspects

Descriptions without external instances of their own: Aspects cannot be directly instantiated (or identified) in environments; they can only exist as digital components in systems.

Concepts (or ideas)

Pure semantic constructs defined independently of instances or categories.

Documents

Entries for documents represent the symbolic contents, with instances representing the actual (physical or digital) documents.

Individuals (or instances)

Physical or symbolic occurrences of ontological things.

The kernel uses OWL 2 hierarchies (yellow lines) to organize entries on a conceptual basis meant to be neutral with regard to abstraction semantics. For example, systems are defined in terms of agent and artifacts without any assumption regarding inheritance.

Aspects & Properties

While aspects are not meant to represent individuals at the enterprise level, they still can represent objects at system level. That’s not the case for object properties.Aspects are used for connecting nodes and structures, features, and states. Properties connectors (blue color) are used to weave representations together.

Beside engineering, knowledge, and logic connectors, the core of EA representation is achieved with three types of connectors:

Architecture connectors (refXX_) come with explicit semantics and are used to define references to EA ontological categories independently of modeling context, e.g., refObject_, refActivity_, refRole_).

Syntactic connectors receive their semantics from context:

Categories connectors (e.g., include_, subset_, extend_) are used to define the relationships between categories set in a modeling context, e.g., flows between activities, references between objects, transitions between execution states, or communication channels between locations.
Instances connectors are used to describe references and execution dependencies (connectRef_ and connectExe_) between instances in a modeling context (e.g., vehicles to owners); min and max cardinalities can be explicit or expressed as data properties.
Include connectors are also used when external identities cannot be established (e.g., aggregates).

Cake annotation properties are used to rank modeling tiers, detail connectors’ semantics, and customize models, e.g. with stereotypes and prototypes.

Axioms

To be ecumenical while ensuring semantic consistency, the thesaurus is built on a limited set of unambiguous axioms:

Limited: since axioms serve as roots to acyclic semantic graphs, there should be as few axioms as possible.
Unambiguous: axioms are meant to be either accepted or rejected, which implies that their meaning should be clear and leave no wiggle room for misunderstanding.

On that account, and assuming standard logic, ten axioms are to constitute the semantic scale of the kernel :

Instances

Physical, digital, or symbolic occurrences of objects or phenomena (both accepted as postulates): The distinction between physical , digital, and symbolic instances is not exclusive (consider hybrids); additionally, fictional instances are instances (physical or symbolic) that are not meant to be realized. Instances are represented by individuals in OWL.

Attributes

For characteristics of instances that belong to them and make them recognisable.

Collection

Set of instances managed uniformly, independently of their nature.

Identity

Unique value associated with an instance: External identities are defined independently of the organization or system under consideration. External identities can be biological, social, or designed; they are not exclusive (e.g., social security number and fingerprints). Internal identities are used to manage systems components independently of environments.

Symbolic Representations

A symbol is a sign pointing to something else (referent).
A symbolic representation is a symbol pointing to a set of instances.
A symbolic object is an object representing a referent; this means that symbolic objects can be physical, as they usually are.

Behavior

The ability of an instance to change the state of instances, including itself: Objects are either active (with behavior) or passive (without behavior), and the propriety is exclusive.

State

Named sets of values that characterize instances of objects (actual or symbolic), processes, or representations, between events. Stateful objects and activities come with a finite number of discrete states; stateless ones don’t have this limited array, and may indeed have an infinite number of discrete states.

Event

Change in the state of objects and phenomena: External events are changes triggered from outside the organization or system under consideration.

Traceability

The Caminao kernel comes with a built-in semantic integrity, enabling the traceability of definitions without circular references:

The OWL hierarchies (yellow lines) define the semantic contexts of entries
The kernel semantic connectors (kernelBw_, kernelFw_) point to additional definitions
Axioms serve as roots and firebreaks, ensuring acyclic definition networks

For example:

System is defined as Container and Agent (hierarchies)
The semantics of Container make references to Collection and Identity
The semantics of Agent make references to Behavior and Identity

Backward traceability: how definitions are built (kernelBw_)
Forward traceability: how definitions are used (kernelFw_)

Combined with the layered organization (axioms and acyclic networks for semantics, graphs for EA knowledge), these connectors can be used to check the consistency (e.g., no circular reasoning), of definitions.

Protege filters are used to select the nodes and/or edges to be displayed, e.g. the kernel filters above.

Hands On

The objective of the thesaurus is not to achieve any kind of truth but to build a basic set of necessary definitions that could be consistently extended and customized depending on business and engineering contexts.

To that end contents must be organized along enterprise architecture perspectives, and views easily defined.

EA Capabilities: Instances & Categories

Enterprise architectures are best represented as a mix of actual organization and systems (territories), and models or projects (maps), the former associated with instances (purple color), the latter with categories (blue color).

Compared to traditional models, ontological representations are meant to combine different levels of abstraction, as epitomized by the mix of instances and types, e.g.,

A customary model would define a type Cook, with instances for individuals, and sub-types possibly defined at enterprise level.
Alternatively, an ontological representation could bypass (or leaves open) a general type and define the type Cook directly in reference to an actual (instance) context (CakeKitchen)
The same option could be employed for the type Employee≈ in reference to an actual organization (Cake Inc).

That seamless integration of maps (categories) and territories (instances) serves two key aspects of EA:

A comprehensive and consistent representation of enterprises and their physical and business environments
A continuous representation of present and planned organization and systems

From Capabilities to Models

OWL hierarchies and capability connectors should remain neutral with regard to modeling methods and languages. On that account their semantics should be limited to conceptual relationships, without any specific meaning regarding abstraction, in particular with regard to inheritance.

Then, specific EA semantics should be expressed in terms of EA capabilities and descriptive models. Assuming that the semantics of prescriptive models can be aligned with established Object Oriented modeling principles, they are not to be detailed at the enterprise level, the focus being put on mapping neutral descriptions of capabilities to specific modeling and engineering methods.

Given the representation of architecture capabilities (context, roles, activities, objects, locations, events and processes), generic connectors are introduced to describe structural and functional relationships independently of modeling languages.

Category Connectors

Category (or intensional) connectors are then used when something can be said about the dependencies between representations:

include_ and includedIn_, when targeted elements are not identified directly (composition or collection)
extend_, and extension_, for functional variants of the same category
subset_ and subsetOf_, for structural variants of the same category
sortedBy_, for partitioning types (or powertypes)

These connectors can be applied indifferently to objects and activities:

Instance connectors

Instance (or extensional) connectors are used to describe static (connectRef_) and dynamic (connectExe_) relationships between elements identified at enterprise architecture level independently of modeling languages. Both kind of connectors can be explicitly qualified:

Minimum and maximum cardinalities: connectXnm_
Identifying role: connectX#_
Conditionality: connectX?_)

The semantics of these connectors is meant to be neutral, ensuring an ecumenical mapping to modeling languages, e.g. the semantics of UML main diagrams:

Data or control flow between activities (connectExe_)
References to symbolic objects (connectRef_)
Communication channels between containers or active objects (connectRef_)
Execution threads between states (connectExe_)

EA Engineering

Compared to system engineering usually set in well defined boundaries and time frames, EA engineering is better understood as a work in progress involving overlapping scopes and schedules, and consequently heterogeneous modeling.

Modeling Levels

EA representations should enable both iterative and phased approaches mixing legacy applications and new developments. That can be achieved by mixing different levels on descriptions in descriptive (enterprise level), prescriptive (system level), and technical (systems platforms) models:

Environments (Territories) & Representations (Maps)

EA is not limited to models, which constitute only a subset of ontologies. That discrepancy is materialized by two different connectors:

realizeX_ is used between epistemic levels of symbolic representations
mapTerritX_ is used between symbolic or non-symbolic external objects or phenomena and enterprise symbolic representations

Model-based Engineering

Ontologies should not be normative, especially with regard to the organization of enterprise architecture and engineering processes. To that end the kernel puts the focus on workshops and workflows broadly defined in terms of roles, resources (refResource_), and outcomes (refOutcome_), making room for enterprises’ specific structures, methods, and practices.

Model-based engineering workflows can thus be organized around use cases (specifications) and models (realizations).

Workflow

Responsibilities (jobRemit_) are meant to be defined according to enterprises’ organizational and technical contexts.

EA in bOwls (Overview)

Preamble