EA in bOwls (WIP)

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).

To demonstrate the benefits of the approach an OWL 2 kernel is proposed to build an EA conceptual thesaurus. That kernel is meant to be formal (based on axioms) and neutral (no modeling assumption). It ensues that OWL 2 primitives can be used to check the consistency of representations, paving the way to the development of platform-specific interfaces and model-based engineering.

Thesaurus Organization

OWL 2 Hierarchy

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: 

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

Since aspects are not meant to directly represent individuals in domains, they can be defined in terms of established systems’ generic of functional constructs:

  • Features (Properties and operations).
  • Numeric and logic expressions.
  • Abstract data types (collections, graphs, …)
  • Rules and heuristics.

The same distinction between system and enterprise levels is maintained for object properties, marking the difference between neutral OWL 2 semantics (yellow lines) and kernel’s specific ones (blue lines).

OWL Hierarchies (yellow) and Kernel Connectors (blue)

Beside the thesaurus ones (kernelBw_ and kernelFw_), kernel connectors are aligned with ontological levels:

  • Explicit type connectors (refXX) are used to define references to EA ontological categories independently of semantic context, e.g., refObject_, ref Activity_, refRole_).
  • Implicit type connectors (e.g., part_, 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.
  • Implicit instance connectors (connectXY_) are used to define links between instances of categories in a modeling context (e.g., vehicles to owners).
  • Data connectors (dataLink_) represent actual (observed) occurrences of connectors.

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.

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

Traceability

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

How definitions are built (backward traceability):

How definitions are built

How definitions are used (forward traceability):

How definitions are used

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.

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.

Modeling Levels

To begin with, hierarchies 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 semantics, 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 covered at this point.

On that basis, connectors at EA level (prefix ref) are used to map requirements to EA architecture capabilities: context, roles, activities, objects, locations, events and processes.

From that starting point, the thesaurus should enable both iterative and phased approaches: build descriptive models either iteratively or through modeling steps:

  • Iterative approach: heterogeneous representations mixing capabilities requirements and descriptive models.
  • Phased approach: homogeneous models, first for requirements capture, and then for analysis (or descriptive models).

Filters & Views

Protege filters are used to select the nodes and edges to be displayed, e.g.,: definitions (KernelBW and KernelFW), tutoring (tutor), hierarchies (Hierarchies), connectors (Connectors), instances (Instances).

Negative ones are used to mask specific elements, e.g., : XKernel, X1, X2, (hierarchies’ top levels), XHierarchies (OWL hierarchies), XErrors (tutoring examples of erroneous representations, XInstances, XParts, XRoles.

Case Studies

Basic Examples

Basic examples will be taken from a typical restaurant business with five basic domains:

To display the examples:

  1. Select the root
  2. Select the the associated filters
  3. Hide irrelevant nodes
Other Examples