Caminao Framework Overview

Click on Cards

The Pagoda Blueprint

Compared to brick-and-mortar architectures, which are tangible and perennial, enterprise architectures are works in progress to be carried out all along the life cycle of enterprises. Hence the need of maps to monitor changes in business and technical environments, ensuring the continuity and consistency of representations and the traceability and accountability of decisions-making processes.

To that effect, enterprise architectures are described in terms of key capabilities (Who, What, How, Where, When) at levels (or tiers or layers) defined with regard to environments:

At the enterprise (or organizational) level, blueprints consider business environments, concepts, objectives, organization and processes.
At the technical (or operational) level, blueprints consider physical and digital environments, systems interfaces, and platforms.
In-between, logical/functional blueprints deal with the symbolic representation of business models, organization, and systems.

While terminologies may vary, the Pagoda levels can be neatly aligned with:

Established conceptual, logical, and physical modeling levels
MDA (Model Driven Architecture) CIM (Computation Independent), PIM (Platform Independent), and PSM (Platform Specific) models
Zachman architecture framework

More limited alignments can also be achieved with engineering frameworks like Archimate or Capella/Arcadia.

Knowledge

Symbolic representations are the bread and butter of architecture, especially for enterprise architecture which is by itself a mix of physical and symbolic artifacts; not to mention their immersion in digital environments.

EA Ontologies

From a functional perspective the role of ontologies is to manage knowledge representations (KR); as defined by Davis, Shrobe, and Szolovits, that can be summarised with five basic functions:

Surrogates: manage the symbolic counterparts of objects, events and relationships identified in context and pertaining to concerns.
Ontological commitments: maintain a set of consistent statements about the categories of things that may exist in the domain under consideration.
Fragmentary theory of intelligent reasoning: support actionable an representation of what the things can do or can be done with.
Medium for efficient computation: make knowledge understandable by computers and support smooth learning curves.
Medium for human expression: improve the communication between specific domain experts and generic knowledge managers.

Traditional models can support points 1, 4 and 5, but often fall short of points 2 and 3. Ontologies are meant to generalize the representation of and the reasoning about any kind of realm, actual or virtual:

Terms, for elementary meanings (lexicon)
Facts, for actual or symbolic elements identifiable in environments (directories)
Categories, for the symbolic representation of facts
Concepts, for semantic constructs defined independently of instances or categories
Documents, for structured symbolic contents

To that effect, EA ontologies must bring together different kinds of resources:

Thesauruses, deal with the meaning of terms, categories, and concepts.
Models, add syntax to build representations of contexts and concerns.
Ontologies, add pragmatics in order to ensure the functional integration of models and thesauruses in physical and symbolic environments.

Mirroring the representation of contents, linguistic tiers can be mapped to communication interfaces: digital (things), symbolic (systems), natural (people).

Data, Information, Knowledge

The raison d’etre of enterprise architecture is to bring under a common roof business, organizational, and technological perspectives. As there is no reason to assume a comprehensive, ecumenical and fixed language, ontologies must provide constructs ensuring the interoperability of the various thesauruses and modeling languages in use.

To begin with, a key distinction is necessary between data, information, and knowledge:

Data (or facts as defined by ORM) encompass whatever can be observed in environments
Information (aka models) deals with the symbolic representations managed by enterprises
Knowledge is for enterprises’ objectives and value chains, in other words data or information put to use

To ensure the sharing of resources as well as a full traceability of outcomes, layered yet interoperable representations are required:

Networks, for the semantics of the terms employed
Resource Description Framework (RDF), for the syntax used by modeling languages to describe the structure of categories
Graphs, for the concepts and pragmatics of domain specific languages

A galactic metaphor can be used to describe their integration:

Stars, planets, and satellites, respectively for concepts, categories, and facts
Gravity forces, for positive or negative semantic bonds between terms
Star systems and orbits, for the abstraction levels within (subtypes) and between (realization) perspectives

For instance:

‘Wheels’ is a familiar equivalent for ‘Car’, ‘Bike’ is opposed to ‘Car’ (definition) and ‘Wheels’ (usage)
Stat system for concept Vehicle encompasses Car, Boat, and Plane categories, as well as Time Capsule concept
Motorbike and Bicycle are actual subtypes of bike, as instances can be mapped to identified elements in environments
Compact, Van, and SUV are functional (aka symbolic) subtypes of rental categories, as instances can be mapped to sets of identified elements in environments
Retired and Employed commuters are actual realization of Commuter (as opposed to subtypes) because while there are instances identified in environment there is no managed categories representing them
Ford Mustang and Fiat500 are functional realization of Car Model (as opposed to subtypes) because there is no identified instances or managed categories

It must be stressed that ensuring the interoperability of representations makes no assumption with regard to their validity.

Ontological Prisms

Ontologies are meant to ensure the integration of thesauruses, models, and knowledge graphs, as well as the interoperability of representations: facts (data view), categories or types (information view), and ideas or concepts (knowledge view). That can be achieved with ontological prisms treating contents as light, enabling some kind of reversible diffraction between ontologies’ contents and data, information, and knowledge constituents.

To be of any use the diffraction mechanisms must ensure a consistent composition and decomposition of contents at different levels of abstraction, within and across views:

Subsets (data view): between identified facts (physical or symbolic) and named sets (symbolic)
Types and subtypes (information view): between identified facts and categories or types (symbolic)
Kind-of (knowledge view): between ideas, or concepts
Realizations: across views

Ontological prisms could thus be used to ensure 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 ontological prisms 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)

On that basis ontological prisms can serve as matrices for EA digital twins:

Processes design reflect the crossing of business models (knowledge) and business intelligence (data mining)
Operations reflect the crossing of application (information) and environment (process mining)
Organization reflects the crossing of business models (knowledge) and enterprise architecture capabilities (information)

The Brain of the Firm

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)

Decision-Making

Decision-making is often confused with problem-solving, namely how to pick a solution given a set of resources, typically people, information, financing, materials. That paradigm ignores the temporal dimension of enterprises’ decision-making which are made of interdependent commitments meant to be carried out across shifting backgrounds and overlapping timescales.

Assuming a knowledge management framework, the objective is to pair (as in DNA strands) the Observation/Orientation/Decision/Action (OODA) steps of decision-making processes with their Data/Information/Knowledge counterparts for content.

Observation: data can be obtained from digital or business environments. It can be analysed and turned into knowledge (business intelligence) or matched with models of managed information.
Orientation: reasoning (information) is applied to observations (data) and judgment (knowledge).
Decision: judgment (knowledge) is supported by observations (data) and causal chains (information).
Action: decisions are carried out through a mix of operations (data) and organization (knowledge).

Each step can thus put its focus on key issues, namely:

Uncertainty (observations): facts are not gold nuggets ready to be picked from river beds; their meanings are mined from data and applications as determined by segmentation (models). Confidence, and more generally the quality of data, can thus be enhanced during decision-making processes.
Causalities (orientation): competing in digital environments means that root causes and rationales, usually set upfront for problem-solving, can now be reassessed on a continuous basis, with causal chains improved through the integration of data analytics and information models.
Risks (decisions): since business competition is by nature a time-dependent, nonzero-sum game, risks can be reassessed until the “last responsible moment,” when delaying a commitment would reduce the range of options or the expected returns. Such reassessment (knowledge) can take into account reduced uncertainties (data) and improved causal chains (information).
Experience (action): decisions taken at the enterprise level usually involve sets of intertwined commitments and deeds whose efficiency is determined by the alignment of operations (data) with organization (knowledge). Set in digital environment, experience can benefit from direct feedback combining knowledge and observations.

More generally, the pairing of decision-making processes with the nature of symbolic resources can help to define horizons:

Operational: when observed data can be directly mapped to information and put to use as knowledge, thus allowing for routine decision-making (a)
Tactical: when the execution of decisions can be improved by additional data and better traceability (b)
Strategic: when commitments must be made without reliable causal chains for the time frame considered; regular costs/benefits assessments must thus be replaced by risk-management schemes covering for ill-fated turns of events (c)
Support: for actions meant to improve the capabilities of enterprises’ organization and systems.

*Horizon Knowl’Edges: Operational (a), Tactical (b), Strategic (c)*

EA Engineering

Enterprise architectures are a combination of culture, organization, and systems with a life of their own. It ensues that EA changes cannot be carried out through autonomous projects as they must ensure the continuity, integrity, and consistency of supported activities. On that account phased processes with neatly defined inception and completion are of limited use for large, diversified, and structured organizations. Hence the benefits of setting apart changes pertaining to EA engineering from projects carried out at the system level.

Requirements

Requirements expressed at the enterprise architecture level can be of any kind and nothing can be assumed upfront about their footprint. Hence the benefit of ontological prisms for their elicitation:

Business domain requirements describe activities independently of the part played by supporting systems
Functional requirements describe the part of activities supported by systems
Capability requirements describe functions shared across business processes
Non functional requirements (Quality of service and technical) refer to to the implementation of supporting systems independently of specific functional contents.

Projects & Workshops

EA engineering should first be defined by scope:

System level, focused on the consistency and continuity of the representations managed by supporting systems
Enterprise level, focused on the role of systems in support of business models

and purpose:

Business value, for requirements rooted in the specifics of business processes as defined directly or through use cases
Architecture assets, for requirements set across business processes, through models or system cases

Engineering interfaces are then defined accordingly:

Business cases (BC), between enterprises and environments
Use cases (UC), between enterprises and systems, with Agile cases (AC) for stand-alone projects without organizational or technical dependencies (ensuring shared ownership continuous deliveries)
Function cases (FC), between systems
Technical cases (TC), within systems

Indicative remits can be added but the specifics are best left to enterprises’ organization.

Given scope and purpose, activities can then be assigned to workshops:

Enterprise, for business objectives and organization (descriptive models)
Domains, for the symbolic representation of business objects and processes (prescriptive models)
Applications, for the implementation of processes by supporting systems (technical models)
Systems, for operational resources deployments (configurations)

Projects, built bottom-up from work units attached to targeted artifacts, are managed as dynamic trees explored and developed according to the status of nodes and leaves:

Roots are used to set contexts, business processes, and anchors in descriptive (or CIM) models (downward arrow). They can also be associated with functions and anchors in prescriptive (or PIM) models.
Use cases are first seen as black boxes anchored to descriptive (or PIM) models (downward arrow).
System cases are further detailed and anchored to technical (or PSM) models, and applications are developed and tested.
Applications are integrated with functions, tested through use cases, and then used as white boxes; i.e., with their counterpart in systems (upward arrow).
Use cases are finally integrated, tested, and accepted in operational (processes’) environments (upward arrow).

Processes & Workflows

Enterprise architects “…are like sailors who have to rebuild their ship on the open sea, without ever being able to dismantle it in dry dock and reconstruct it from the best components.” (Otto Neurath)

That can only be done through workflows that combine phased and iterative schemes:

Agile development, for business-specific applications free of cross dependencies
Model-based developments, for architecture- based functions subject to cross dependencies
Workflows combining Agile and Model-based developments, for requirements with enterprise-level dependencies

Agile developments are carried out iteratively through a direct collaboration across enterprise, application, and systems workshops, without impacting shared use cases or models. Phased developments are organized across limited to the sharing of use cases or also to shared models.

The aim of the Pagoda playbook is set a path toward a comprehensive enterprise architecture supporting an incremental integration of engineering and business processes along revisited CMMI (Capacity maturity model integration) levels:

Initialization: existing assets, resources, and practices (systems, tools, organizational units, …) are progressively inventoried and matched with core Pagoda blueprint elements (components, models, use cases, …).
Management: inventoried elements are organized with regard to commonly accepted engineering categories, e.g., Zachman’s or ArchiMate’s
Normalization: projects are progressively defined (or refactored) in terms of core Pagoda blueprint categories for use cases and models, and development models, Agile or phased
Assessment: phased projects are refactored and assessed in terms of Model-based engineering processes.
Optimization: engineering processes, Agile or phased, are mapped to business ones, paving the way to EA maturity assessment.

EA Governance

Applying the ontological prism to Pagoda architectures can be used to align EA governance with symbolic resources:

Requirements (facts)
Business intelligence (facts/concepts)
Strategic planning (concepts)
Modernization (concepts/categories)
Systems engineering (categories)
Systems modeling (facts/categories)

Combined with enterprises immersion in digital environment that will provide a systemic, intelligible, and actionable framework for EA governance.

Caminao Framework Overview

The Pagoda Blueprint