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.
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.
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
- ‘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.
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:
- 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.
And ontological prisms can go further, turning digital twins into enterprises’ nervous and cognitive systems combining:
- A sensory-motor integration of structures (Pagoda blueprint) and decision-making processes (OODA) immersed in digital environments
- A Collective intelligence fusing implicit and explicit knowledge with reasoning, judgment, and learning capabilities.
That would realize Stafford Beer’s vision of the “Brain of the Firm”.
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.
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.
- 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
- Quality of service (QoS) requirements refer to supporting systems capabilities independently of functional contents.
- Technical requirements refer to the implementation of systems capabilities independently of their 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
- 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.
- Knowledgeable Organizations
- Knowledge Management Booklet
- Edges of Knowledge
- The Pagoda Playbook
- ABC of EA: Agile, Brainy, Competitive
- EA in bOwls (Overview)
- Knowledge-driven Decision-making (1)
- Models & Meta-models
- Ontologies & Enterprise Architecture
- Abstraction Based Systems Engineering
- EA & MDA
- EA: The Matter of Layers
- EA: Maps & Territories
- EA: Work Units & Workflows