EA & The Pagoda Blueprint

“The little reed, bending to the force of the wind, soon stood upright again when the storm had passed over”

Aesop

Resilience and adaptability to changing environments (Masao Ido)

Preamble

The consequences of digital environments go well beyond a simple adjustment of business processes and call for an in-depth transformation of enterprise architectures. 

To begin with, the generalization of digital environments bears out the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns. 

With regard to architectures, it means a seamless integration of systems and knowledge architectures.

With regard to processes it means a built-in ability to learn from environments and act accordingly.

Such requirements for resilience and adaptability in unsettled environments are characteristic of the Pagoda architecture blueprint.

Pagoda Blueprint

As can be observed wherever high buildings are being erected on shaking grounds, Pagoda-like architectures set successive layers around a central pillar providing intrinsic strength and resilience to external upsets while allowing the floors to move with the whole or be modified independently. Applied to enterprise architectures in digital environments, that blueprint can be much more than metaphoric.

The actual relevance of the pagoda blueprint is best understood when the main of data, information, and knowledge is set across platforms, systems, and organization layers:


The Pagoda Architecture Blueprint is derived from the Zachman’s framework

That blueprint puts a new light on model based approaches to systems engineering (MBSE):

  • Conceptual models, targeting enterprises organization and business independently of supporting systems.
  • Logical models, targeting the symbolic objects managed by supporting systems as surrogates of business objects and activities.
  • Physical models, targeting the actual implementation of symbolic surrogates as binary objects.

Pagoda Blueprint & Digital Environments

The Pagoda blueprint gets a new relevance in the context of digital transformation.

Moreover, the blueprint is not limited to enterprise architectures and can be applied to every kind of systems:

  • Devices associated to physical platforms supporting analog communication through the Internet of Things (a).
  • Equipements associated to physical platforms controlled by systems, supporting digital communication (b) and functional alignment (c) .
Beside enterprise architectures, the Pagoda Blueprint can be applied to equipments, systems or devices.

That would greatly enhance the traceability and transparency of transformations induced by the immersion of enterprises in digital environments.

Systems & Knowledge Architectures

If digitized business flows are to pervade enterprise systems and feed business intelligence (BI), systems and knowledge architectures are to be merged into a single nervous system as materialized by the Pagoda central pillar:

Business Intelligence and Decision-making
  • Ubiquitous, massive, and unrelenting digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms, and the information (previously data) models which ensure the continuity and consistency of systems.  .  
  • Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
  • A comprehensive and business driven integration of organization and knowledge could then support strategic and operational decision-making at enterprise level.

Rounding off this nervous system with a brain, ontologies would provide the conceptual frame for models representing enterprises and their environments.

Agile Architectures & Homeostasis

Homeostasis is the ability of a viable organism to learn from their environment and adapt their behavior and structures according to changes.
As such homeostasis can be understood as the extension of enterprise agility set in digital environments, ensuring:

  • Integrated decision-making processes across concerns (business, systems, platforms), and time-frames (tactical, operational, strategic, … ).
  • Integrated information processing, from data-mining to knowledge management.

To that end, changes should be differentiated with regard to source (business or technology environment, organization, systems) and flows (data, information, knowledge); that would be achieved with a pagoda blueprint.

Resilience and adaptability to changes

Threads of operational and strategic decision-making processes could then be weaved together, combining OODA loops at process level and economic intelligence at enterprise level.

Further Reading

Squared Outline: Layers

The immersion of enterprises into digital environments is blurring the traditional distinctions between architecture layers. Hence the need of clarifying the basic notions.


The Pagoda Architecture Blueprint is derived from the Zachman’s framework

Beyond the differences in terminologies (layers, levels, tiers, etc), four basic taxonomies can be applied:

  1. Enterprise architecture: business processes and organization, systems, platforms (Pagoda blueprint).
  2. Functional architecture: interfaces, control, persistency, services (Model/View/Controller).
  3. Representation: physical, logical, conceptual (Pagoda blueprint).
  4. Economic intelligence: data, information, knowledge

While some alignments are intrinsic, making explicit use of taxonomies is useful because they serve specific purposes.

n.b. The term “application layer” is usually defined in the context of communication architectures.

Further Reading

Squared Outline: Activity

As far as modeling is concerned a distinction has to be maintained between the symbolic description of activities and the processes describing their actual execution.

Given that distinction, the objective is to align action semantics with the constraints of their execution:

  1. Action on symbolic representations without coupling with the context (no change).
  2. Action on symbolic representations with coupling with context (change in expectations).
  3. Interaction with actual context without direct coupling (change in process status).
  4. Interaction with actual context with direct coupling  (change in objects).

That taxonomy can then be applied to map use cases semantics to architecture capabilities.

Squared Outline: Time-frames

Time-frames are defined by root events and therefore best defined along the same guideline, namely their scope and the nature of coupling. 

Along that understanding, time-frames can be defined with regard to context (symbolic or actual) and coupling (asynchronous or synchronous):

  1. Symbolic, no coupling: time-frames set by internal events, involving a single actor.
  2. Symbolic, coupling: time-frames set by external events, involving a single actor.
  3. Actual, asynchronous: time-frames set by external events, involving different actors without real-time constraint.
  4. Actual, synchronous: time-frames set by external events, involving different actors with real-time constraint.

That taxonomy could be used to align time-frames with processes‘ execution mode.

2019: Hit The Caminao Ground Running

Hitting the ground running with Caminao is meant to be easy as it relies on
a well-founded modeling paradigm (Stanford Symbolic Systems Program) and a solid and well established reference framework (Zachman’s).

Moving On (Moises Levy)

Secured by these foundations, teams could carry on with agile and MBSE development models, helped, if and when necessary, by a comprehensive and consistent documentation freely available online.

Symbolic Systems Paradigm

The Stanford Symbolic System Program (SSP) is built on clear and incontrovertible evidence: the purpose of computer systems is to manage the symbolic counterparts (aka surrogates) of business objects and activities. Based on that understanding, enterprise architectures can be wholly and consistently defined by maps (the models) and territories (relevant business objects and activities and their symbolic counterparts in systems).

A formal as well as pragmatic understanding of Enterprises and Systems

That paradigm is at the same time straightforward and aligned with the formal distinction between extensional and intensional representations, the former for requirements analysis (descriptive models), the latter for systems design (prescriptive models).

Zachman’s Framework

Given its clarity of purpose and concepts, the Zachman Framework is arguably a reference of choice; its core is defined by six columns and five lines, each of them associated with well known concepts:

https://caminao.blog/wp-content/uploads/2018/06/pentaheds-zachtab3.jpg
A clear and compact set of unambiguous concepts encompassing the whole of enterprise architecture.

Yet, the table arrangement comes with some discrepancies:

  • Lines mix architectures artifacts (2-4) with contexts (1) and instances (5).
  • Columns mix capabilities (1-5) with objectives (6).

While keeping the semantics intact, Caminao rearranges the artifacts lines into pentagons:

Changing the format opens the door to enterprise architecture capabilities

That simple transformation significantly improves the transparency of enterprise architectures while bringing a new light on dependencies set across layers and capabilities. As it happens, and not by chance, it neatly fits with the Pagoda architecture blueprint.

Digital Transformation & The Pagoda Blueprint

The generalization of digitical environments bears out the Symbolic System modeling paradigm: to stay competitive, enterprises have to manage a relevant, accurate, and up-to-date symbolic representation of their business context and concerns. On that account, consequences go well beyond a shallow transformation of business processes and call for an in-depth transformation of enterprise architectures that should put the focus on their capacity to refine business data flows into information assets supporting knowledge management and decision-making:

  • Ubiquitous, massive, and unrelenting digitized business flows cannot be dealt with lest a clear distinction is maintained between raw data acquired across platforms and the information (previously data) models ensuring the continuity and consistency of systems. 
  • Once structured and refined, business data flows must be blended with information models sustaining systems functionalities.
  • A comprehensive and business driven integration of organization and knowledge could then support strategic and operational decision-making at enterprise level.

Such an information backbone set across architecture layers tallies with the Pagoda architecture blueprint well known for its resilience and adaptability in unsettled environments.


The Pagoda Architecture Blueprint is derived from the Zachman’s framework

That blueprint can be much more than metaphoric: applied to enterprise architectures it would greatly enhance the traceability of transformations induced by digital environments.

Proceed With Agile & MBSE

Once set on track with a reliable paradigm and a clear reference framework, teams can carry on with their choice of development models:

  • Agile schemes for business driven applications for which conditions of shared ownership and continuous delivery can be met.
  • Phased schemes for architecture developments set across business processes. 
How to pick the right development models and to integrate architecture and business driven projects

Whatever the development methods, the modeling paradigm will put enterprise architecture and projects management on a principled basis, and the framework will significantly enhance their integration.

Take a knowledge PERSPECTIVE

The success of knowledge graphs in AI applications is putting a new light on ontologies, first expounded by Greek philosophers as a general knowledge management scheme. 

Hence the benefits of using ontologies to bring under a common roof the full range of data, information, and knowledge pertaining to enterprise architectures.

FURTHER READING

 

Squared Outline: Events

In line with the Symbolic Systems paradigm, events are best understood in terms of interactions between systems (or enterprises) and the environment they represent (or live off).

Events with regard to nature and coupling

On that account events are to be associated with four kinds of notifications:

  1. Actual (aka non symbolic) changes in the state of objects.
  2. Actual (aka non symbolic) changes in the state of activities.
  3. Changes in the state of expectations (e.g requests/acknowledgments).
  4. Neutral changes in symbolic representations (e.g messages).

It must be noted that while synchronization constraints (e.g UML’s calls vs signals) characterize events’ communication semantics, they say nothing about events themselves.

That distinction is of a particular importance for the definition of time as a
change in a dedicated physical device, ensuring that, according to Einstein, events don’t happen at once.

FURTHER READINGS

Squared Outline: Intelligence in 3*4

Motifs & Motives

Assuming that intelligence is the capacity to learn, three kind of motifs should be considered:

  • Data, for facts from physical and symbolic environments
  • Information, for categories giving structure and meaning to data
  • Knowledge, for concepts adding purposes to information
The Fabric of Intelligence

These motifs serve three kinds of motives: communication between agents; representation of contexts, concerns, and conversations; imagination of alternatives realities.

That taxonomy neatly coincides with Spinoza’s philosophical one: data for senses and beliefs, information for reason, and knowledge for judgment..

Four Threads

Intelligence can thus be characterized by four cognitive operations:

  • Deduction infers individual facts from categories’ features
  • Induction: infers categories’ features from observed facts
  • Abduction: adds conceptual explanations to induction
  • Intuition: makes direct associations between experience (facts) and beliefs (concepts)
Necessary (solid line) and non-necessary (dotted line) Inference patterns

Induction, deduction, and abduction may arguably be performed by artificial brains providing traceability; that’s not the case for intuition because it involves accountability.

Brains’ Capabilities

The 3*4 taxonomy of intelligence’s motifs and threads can then be used to characterize brains’ capabilities in terms of problem solving.

To begin with the representation of issues:

  • Symbolic representation can rely on functions (data), models (information), and semantic or conceptual graphs (explicit knowledge)
  • Alternatively, non symbolic representation can start with digits (data), documents (information), and neural networks (implicit knowledge)
Brains’ Capabilities

Problem solving itself will make use of:

  • Symbolic representation: deduction (data), induction (information), and abduction (knowledge)
  • Non symbolic representation: data analytics (data), pattern matching (information), and Machine learning (implicit knowledge)

Capabilities can then be used to draw a line between natural and artificial brains.

Artificial vs Natural Brains

The enterprises immersion in digital environments combined with the ubiquity of Artificial intelligence and Machine learning technologies have put traceability and accountability on top of design issues; hence the need to set the limits of artificial brains:

  • Artificial brains can build and process symbolic and non symbolic representations
  • Artificial brains can solve problems applying logic and abstraction or 
    data analytics, respectively to symbolic and non symbolic representations
  • Like natural ones, artificial brains combine sensory-motor capabilities with purely cognitive ones
  • Like human ones, and apart from sensory-motor capabilities, artificial brains support a degree of cognitive plasticity and versatility between symbolic and non symbolic representation and processing.

While artificial brains’ capabilities appear to match human ones, that’s not the case fall when shortfalls in traceability (e.g., with abduction or intuitions) must be supplemented by judgements’ accountability.

Artificial General Intelligence

While still an open-ended field of research, the debate about Artificial ‘General’ Intelligence (AGI) can be summarized in terms of scope or agents.

Regarding scope the debate turns around the ability of Machine learning technologies to:

  • Reproduce human implicit knowledge and intuition
  • Deal consciously with actual and virtual realities

As both issues remain shrouded in the mystery of individual consciousness, it might be worth to consider the collective dimension of general intelligence. Applying the principle to enterprises:

  • Motifs: intelligence rooted in operations (facts), organization (concepts) and systems (categories)
  • Motives: intelligence driven by business processes (communication), information management (representation), and planning and decision-making (imagination)
A Collective perspective (green circle) of ‘General’ intelligence

Implicit knowledge and intuition would be rooted in data and process mining, and weaved with the fabric of consciousness built from a continuous adjustment of managed (actual) and planned (virtual) realities.

FURTHER READING

Books

Squared Outline: Ontologies

The primary aim of ontologies is to bring under a single roof three tiers of representations and to ensure both their autonomy and integrated usage:

  • Thesauruses federate meanings across digital (observations) and business (analysis) environments
  • Models deal with the integration of digital flows (environments) and symbolic representations (systems)
  • Ontologies ensure the integration of enterprises’ data, information, and knowledge, enabling a long-term alignment of enterprises’ organization, systems, and business objectives

To ensure their interoperability, tiers should be organized according to linguistic capabilities: lexical, syntactic, semantic, pragmatic.

To ensure their conceptual integration, ontologies must maintain an explicit distinction between:

  • Concepts: pure semantic constructs defined independently of instances or categories
  • Categories: symbolic descriptions of sets of objects or phenomena: Categories can be associated with actual (descriptive, extensional) or intended (prescriptive, intensional) sets of instances
  • Facts: observed objects or phenomena 
  • Documents: entries for documents represent the symbolic contents, with instances representing the actual (or physical) documents

As for technical integration, it is can be achieved through graphical neural networks (GNN) and Resource description framework (RDF).

FURTHER READING

Frameworks: How to Avoid Quagmires

Preamble

Deciding upon a framework is a choice that bears upon a wide range of enterprise activities and may induce profound transformations in organization and systems. It ensues that the outcome is practically settled at the outset: once on a wrong path the only option is often to cut the losses as soon as possible.

gianni-motti
When the first step settles the issue for the whole journey (Gianni Motti)

As it happens, there is no reason to hurry and every reason to take the time before opting for a long-term and comprehensive commitment.

Taking simple litmus tests can be used to avert overhasty moves into quagmires. Compared to a comprehensive assessment, the objective would only be to establish a shortlist of frameworks worth of a further assessment. For that purpose forms (but not substance) are to be considered for the consistency of definitions, the specificity of value propositions, and the reliability of roadmaps.

Consistency of Definitions

Frameworks come with glossaries covering generic, specific, and standard terms in various proportions; the soundness of these glossaries can be assessed independently of their meanings.

For that purpose simple metrics can be applied to a sample of definitions of core concepts, (e.g: agent, role, actor, event, object, activity, process, device, system, architecture, enterprise):

  • Self-contained: terms directly and fully defined, i.e without referring to other glossary terms (c,a,m).
  • Number of references used.
  • Circular references: terms including at least one path to itself (d,e,f)
  • Average length of non-circular references
  • Overlaps (i and j)
  • Conflicts (w by (x><e)
GloGraph
Basic definitions graph (x contradict e)

Even computed on small samples (10 to 50), these metrics should be enough to provide a sound yardstick.

Value Proposition Specifics

Pledges about meeting stakeholder needs, holistic undertaking, or enhanced agility are part and parcel of every pitch; but as declarations of intent they give little information about frameworks.

To be given consideration a framework should also be specific about its value proposition, in particular with regard to its description of enterprise architecture and systems engineering processes.

Assuming that the specificity of a value proposition equals the likelihood of a contrary stance (no framework would purport ignoring business needs or being non agile), general commitments must be supported by schemes meant to make a difference.

Roadmap Reliability

Given what is at stake, adopting a framework should only be considered if it can significantly reduce uncertainty. On that account road-maps built from pre-defined activities are deceptive as they rely on the implicit assumption that things will always be as they are meant to be. So, taking for granted that positive outcomes can never be guaranteed independently of circumstances, a framework reliability is to be assessed through its governance apparatus.

Along that reasoning, key stages, steps, or activities defined by a roadmap should be framed into a clear decision-making processes, e.g the observation, orientation, decision, action (OODA) loop.

A framework reliability could then be judged by its ability to support enterprise architects in assessing situations and picking a course of action.

Further Reading

Squared Outline: Requirements

Depending on context and purpose requirements can be understood as customary documents, contents, or work in progress.

  1. Given that requirements are the entry point of engineering processes, nothing should be assumed regarding their form (natural, formal, or specific language), or content (business, functional, non-functional, or technical).
  2. Depending on the language used, requirements can be directly analyzed and engineered, or may have to be first formatted (aka captured).
  3. Requirements taxonomy should be set with regard to processes (business or architecture driven) and stakeholders (business units or enterprise architecture).
  4. Depending on content and context, requirements can be engineered as a whole (agile development models), or set apart as to tally with external dependencies (phased development models).

Further Reading