EA: Ontological Prisms & Digital Twins

Preamble

The digital revolution calls for a change of paradigm that could take into account the difference between digital flows (data), managed information, and knowledge. Benefits can be illustrated by a simple shift of perspective from layered pyramids to prisms.

Ontologies could then be used to implement such prisms and serve as actionable maps of enterprise architecture. One step further, symbolic representations could be fused into the digital and physical fabric of EA to form the matrix of digital twins.

Ontological Diffraction

While ontologies are meant to ensure a seamless and consistent integration of thesauruses, models, and knowledge graphs, their effective use depends on the interoperability of business and system perspectives. And that interoperability must be achieved across contents: facts (data view), categories or types (information view), and ideas or concepts (knowledge view).

Comparing ontologies to prisms and their contents to light and colors, the objective is to achieve some kind of reversible diffraction between ontologies’ contents and data, information, and knowledge constituents.

Actual Views

Analytical (data) views are meant to represent facts (as defined by the Object-Role Modeling methodology) deemed to be relevant. Their backbones are built using structural and partitioning connectors. They usually work bottom-up, typically from data and process mining aiming at predictive models (knowledge), or from business process requirements aiming at descriptive ones (information).

For instance, a data analysis carried out on commutes’ duration and transport scheme.

Conceptual Views

Conceptual (knowledge) views put the focus on the description of business environments and objectives independently of managed representations, the aim being to support communications across enterprise units and business domains. Their backbones add ontological and OWL hierarchy connectors to composition ones. They usually work top-down, from conceptual or abstract descriptions to data or business analysis.

For instance, an urban mobility policy could start with a conceptual overview of transports.

Logical Views

Logical and functional (information) views are focused on managed representations. Their backbones are built with standard modeling connectors (e.g. UML) for structures, association, execution and inheritance.

*Managed representation of transport passes*

For instance, the managed information about transport passes and users.

It must be noted that while OWL hierarchies (yellow color) are used as generic kind-of (or is-a) connectors, they can be refined or combined with more specific ones; e.g., IndividualTransport and CollectiveTransport can be connected to Transport as concepts (subClassOf_/native) and activities (include_).

Governance Perspectives

Ontological prisms enable the alignment of governance issues with symbolic resources:

Business perspective and communication (facts/concepts),
Systems perspective and representation (facts/categories)
Enterprise perspective and strategies (concepts/categories).

That can be achieved through the pairing of ontologies with actionable architecture.

Business Perspective

Perspectives combining data and knowledge views can be used to map out the source of predictive models, typically through data mining.

*Analytical & Business Intelligence View*s

For instance business intelligence can use data mining to define commuter profiles that could be crossed with managed information about pass users.

System Perspective

Perspectives combining data and information views can be used to map out the links between business intelligence and users’ needs on the one hand, models of managed information on the second hand.

Conversely, a dual data/information perspective can be used to support compliance with privacy regulations, e.g. by ensuring the separation between information managed for pass users (Person≈), and private data of commuters (Person_).

Enterprise Architecture Perspective

The main benefit of combining knowledge and information views is to bring together business and architecture perspectives, a key concern for enterprise architects. That can be done at different levels: on the one hand with the mapping of predictive, descriptive, and prescriptive models; on the other hand with the use of descriptive logic to integrate business rules in models.

For instance, a free pass requirement for seniors (seniorFreePass) is defined with descriptive logic, to be applied to planned pass users (transPass:2025) defined as current ones (PassUser).

Abstraction Semantics

There can be no mapping without dealing with complexity and abstraction, especially when, as with enterprise architecture, targeted territories mix physical and symbolic realms. When considered separately, the concepts of complexity and abstraction usually beget contentious arguments; and yet, there is a broad if cursory consensus about using the latter to deal with the former. Ontological diffraction can put some flesh on the bones of agreements.

Variants & Diffractions

For modellers, abstraction may be compared to a philosopher’s stone, if only because models can always be scaled up the abstraction ladder until being detached from the complexity of actual contexts and concerns.

But the concept itself is by nature equivocal; whether defined as a cognitive process or as a symbolic artifact, abstraction is meant to factor out a number of attributes used to characterize sets of physical, symbolic, or semantic elements. As it happens, both understandings of abstraction can be aligned with ontological diffractions:

Subset (data view): between identified elements (physical or symbolic) and named sets (symbolic)
Types and subtypes (information view): between identified elements and categories or types (symbolic)
Kind-of (knowledge view): between ideas, or concepts

With terms (semantics) ensuring the interoperability of named sets, concepts, and categories.

Taking a preliminary understanding of a mobility exemple:

From a data perspective, one could identify cars, transport passes, and persons; one could also put names on the subset of rental fleet in maintenance, or of senior pass users.
From a knowledge perspective concepts like Vehicle, Transport, or Service could serve as references, and Concept car as a test case.
The information perspective presents the types and subtypes used by information systems, typically Object oriented design principles.

Diffractions & Abstractions

These three kinds of abstraction can then be applied to corresponding variants:

Subsets: senior pass users, cars in maintenance
Kind-of: public service, public transport, Collective vehicle
Subtypes: fiat500, rental car, commuter, bus pass

At that point it appears that diffracted variants are not necessarily aligned, e.g.:

Set and subset of pass users and senior ones (actual) can be matched by type and subtype representation (logical)
By contrast, while the commuters subtype corresponds to an actual subset, the persons type only represents the persons subset which own a pass

Moreover, discrepancies between abstracted views are not only about elements and may also be rooted in semantics, e.g.:

Should Vehicle and Car be defined both as concepts or as categories ?
Should Fiat500 be defined as category or individual ?
Should cars in maintenance be defined as subset ?

In fact, these discrepancies reflect a basic issue: there is no reason for abstraction hierarchies of facts, concepts, and categories to coincide. That issue appears clearly when abstractions are applied to enterprise architecture; in that case matching business and system abstractions is at the core of a principled and continuous adjustment of business models and architecture capabilities, and, as a corollary, of complexity management.

Abstractions Alignment

While there is no reason to assume that EA’s abstraction hierarchies mirror environments’ ones, some kind of alignment is required; that can be achieved if abstractions are characterized by variants’ footprint: intrinsic (structure or identity) or functional (features or behavior):

For concepts (knowledge view), variants are about terms (functional) and concepts (intrinsic):

PublicService and PublicTransport are conceptually defined in terms of Service and Transport, respectively (intrinsic)
ConceptCar and Boat are semantically defined in reference to Vehicle (functional)
It must be noted that, contrary to Car, Boat is not a managed category

For categories (information view), the distinction is between functional and structural types and subtypes:

RentalCar is a subtype managed independently of Car structure or identity (functional)
SeniorPassUser and BusPass are subtypes attached to PassUser and TransportPass, respectively (intrinsic)

For facts (data view), variants can be defined for partitions (functional) and subsets (intrinsic):

Status and IncomeBracket are defined independently of structure or identity (partitions)
SeniorPass and CarModel are attached to structure or identity (subsets)

Realizations are used for abstractions set across epistemic levels:

Between concepts and categories (functional): Car (a category) as a realization of Vehicle (a concept)
Between facts and concepts or categories (intrinsic): Fiat500 (a symbolic object) as a realization of CarModel (a category); Scooter (a physical object) as a realization of Vehicle (a concept)

The challenge is then to manage the consistency of actual, conceptual, and system descriptions. As far as semantics are concerned, that can be achieved through thesauruses. But when environments and systems representations are considered, one must ensure that structures are consistently identified, and that the semantics of features are set accordingly; that can be done with anchors.

Anchoring Abstractions

Anchors (#) are introduced to tie identified concepts, facts, and categories while hiding respective abstractions:

Cars, passes, and users are consistently identified in environments and systems, ensuring the consistency of references for rental cars, car models, and passes without making assumptions about respective abstractions
The semantics of the Transport category is strictly aligned with the corresponding concept.

Combining anchors with differentiated abstraction semantics can directly improve both ecumenism and interoperability:

Ecumenism: domain-specific abstractions can be developed independently yet consistently attached to shared business entities
Interoperability: abstractions can be fine-grained as to secure the sharing of representation overlaps

More generally, anchored representations and differentiated abstractions are at the core of change and complexity management.

Changes & Abstractions

Taking cue from cybernetics, complexity can be understood in terms of entropy, summarily defined as a measure of discrepancies between facts (aka micro-states) and symbolic representations (aka macro-states); for enterprises entropy would thus stem from flawed representations of business objectives, organization, and systems.

Changes & Complexity

When complexity is understood in terms of entropy, the focus is put on the exchanges of information between organizations and environments. While the availability of relevant metrics for size and complexity remains a disputed issue, some existing yardsticks can help:

Assessment of facts as represented by datasets (micro-states) is a technical issue routinely handled with statistical methods like regression analysis.
Assessment of symbolic representations (macro-states) can be based on metrics like function points, applied to descriptive models at the enterprise level and prescriptive ones at the system level.

Then, considering relative measurements instead of absolute ones, changes (≈) in complexity, and consequently entropy (Ω), could be assessed in terms of alignment between:

*Changes in complexity (≈) and Entropy (Ω)*

Business processes and operations (environment/micro-states)
Operations and organization (architecture/macro-states)
Business processes and organization (value chains)

Using the symbolic pyramid as a nexus between environment and enterprises, the objective would be to improve the versatility and plasticity of enterprise architectures: the former for its ability to change processes without changing enterprise architecture; the latter for its ability to change enterprise architecture without affecting processes.

Complexity & Abstractions

As contended by cybernetics, entropy stems from flawed communication between systems and environments; for organizations that would mean a discrepancies between emerging and designed changes, the former originating from environments, the latter initiated by enterprises management. Entropy would stem from emerging changes unforeseen or at odds with existing organization or systems; or from misguided policies out of sync with shifting environments.

Ontologies, meant to support the integration and interoperability of the whole of EA symbolic resources, can be used to manage complexity and reduce entropy, with abstractions used to build the gears between emerging and designed changes.

Emerging changes & Versatility

Emerging changes originate in business and physical environments, typically through data and process mining. Some are meant to be dealt with at system or enterprise level, others can be taken into account through changes in processes without inducing structural changes in architectures. Complexity (and entropy) increases when changes that could be dealt with through processes induce structural changes in representations. For instance, new partitions about areas, duration, or pass users should be managed through processes and functional types without affecting the structure of pass and users representation.

Versatility can prevent such slips by circumscribing specific changes to the semantics and rules (partitions) of business processes, and their implementation to functional types or subtypes. That will ensure that the mapping of subsets semantics to anchored representations is not affected.

Designed changes & Plasticity

Designed changes are defined and planned at the enterprise or system level; some are specific to business domains, others encompass shared functions or services.

Complexity (and entropy) may arise out of two opposite slips:

Blurred specialization: when additional subtypes induce changes in the semantics of base types, and consequently in the semantics of prior subtypes meant to be unconcerned. For instance, adding a Rail pass subtype would turn the initially exclusive base type into a non exclusive one (a).

Over generalization: prior subtypes are merged with additional ones in order to consolidate current and new representations, and thus ironing out the representation of meaningful subsets or partitions. For instance, merging MTA and combined subtypes will induce unnecessary changes in processes (b).

Plasticity can prevent both kind of weakened representation by ensuring that changes are bounded by anchors (structures identity) and domains (features semantics).

Object-oriented Design

As it happens, these guidelines can be matched with established Object-oriented (OO) design principles known as SOLID:

Single responsibility principle (SRP): identified architecture elements must have only one reason to change (no blurred specialization).
Open/close principle (OCP): identified architecture elements are open for specialization but closed for modification (no over generalization)
Liskov substitution principle (LSP): instances of anchored sets (data) should not depend on the abstraction level of their representations (information)
Interface-segregation principle (ISP): functional types and subtypes are semantically homogeneous with regard to the structural types they are attached to: each level comes with all the necessary features, nothing more
Dependency-inversion principle: combines OCP and LSP, such that the semantics of higher (enterprise) levels are defined independently of those at lower (domains) levels

That congruence enables a continuous and sustainable alignment of architecture designs with emerging changes brought about from shifting environments. And that alignment is not limited to symbolic representations: with enterprises immersed in digital environments ontologies can be turned into ” …virtual representation of an object or system that spans its lifecycle, is updated from real-time data, and uses simulation, machine learning and reasoning to help decision-making.” (What is a digital twin? IBM)

Digital Twin as “Brain of the Firm”

Taking IBM’s general description as a reference, ontological prisms can serve as matrices for EA digital twins:

Supporting comprehensive and consistent symbolic representation of the different components of an enterprise architecture
To be updated from real-time data, if with some latency for information and knowledge
Enabling the pairing of decision-making processes and symbolic resources and the explainability of actual and simulated processes.

Ontological prisms can go further, turning digital twins into enterprises’ nervous and cognitive systems combining osmosis and homeostasis:

Ontologies ensure the comprehensive and consistent symbolic representation of the different components of an enterprise architecture
Machine learning technologies enable updates from real-time data, if with some latency for information and knowledge (Osmosis)
Knowledge graphs enable the pairing of decision-making processes and symbolic resources and the explainability of actual and simulated processes (homeostasis)

That combination of sensory-motor systems immersed in digital environments on the one hand, a collective intelligence with reasoning, judgment, and learning capabilities on the other hand, gives a new relevance to Stafford Beer’s vision of a “Brain of the Firm” supporting the three fundamental cognitive functions:

Understanding of contexts and opportunities (business intelligence)
Symbolic representation of relevant aspects of contexts and opportunities (system modeling)
Symbolic representation of virtual aspects of contexts and opportunities (planning)

That would realize Stafford Beer’s vision of the “Brain of the Firm”.

EA: Ontological Prisms & Digital Twins

Preamble