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

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. 
Anatomy of Ontologies

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.

OWL 2 Kernel Hierarchy
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. 

Categories

Symbolic descriptions of sets of objects or phenomena: Categories can be associated with actual (descriptive, extensional) or intended (prescriptive, intensional) sets of instances.

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.

Figure 2. Aspects & properties

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 define structures (include_) and associations (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.

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, seven axioms are to constitute the semantic scale of the kernel :

Instances

Physical or symbolic occurrences of objects or phenomena (both accepted as postulates): The distinction between physical 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.

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
  1. A symbol is a sign pointing to something else (referent).
  2. A symbolic representation is a symbol pointing to a set of instances.
  3. 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

These axioms serve as roots and firebreaks in acyclic semantic networks of EA definitions. 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

Semantic connectors are introduced to ensure the traceability of definitions and eliminate circular references:

Figure 3. Axioms & Definitions
  • 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).

Figure 4. Instances, Categories, and Capability Connectors

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

  • A consistent representation of enterprises and their physical and business environments
  • A continuous representation of actual and future 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 apply to objects as well as activities:

Figure 5a
Figure 5b
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?_)
Figure 6a
Figure 6b

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

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 & Models

EA is not limited to models, which constitute only a subset of ontologies. That discrepancy is materialized by the use of 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
Figure. 8
Model-based Engineering

Ontologies should not be normative, especially with regard to organization. To that end the kernel puts the focus on workshops and workflows broadly defined in terms of roles, resources (refResource_), and outcomes (refOutcome_).

Figure 9 Workshops

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

Figure 10 Workflows

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

About the Companion Series

The aim of the OWL Companion series is to illustrate the principles developed in the book Enterprise Architecture Fundamentals (soon on Amazon’s shelves) through their implementation with OWL 2 Protégé.

Episodes of the book companion are meant to be directly aligned with the book chapters. Episodes of the case study companion put functional topics in the workshops perspective, with a focus on the modeling.

Models will be accessed online by selecting elements, or through tutor’s predefined views using the basic facilities of Protégé online user interface:

  • Filters defined by the Caminao kernel
  • Hiding or focusing nodes
Filters (left), Hide & Focus (right)

FURTHER READING