Category: Enterprise Architecture

About the ‘S’ in MBSE

Preamble

As demonstrated by a simple Google search, the MBSE acronym seems to be widely and consistently understood. Yet, the consensus about ‘M’ standing for models comes with different meanings for ‘S’ standing either for software or different kinds of systems.


Tools At Hand (Annette Messager)

In practice, the scope of model-based engineering has been mostly limited to design-to-code (‘S’ for software) and manufacturing (‘S’ for physical systems); leaving the engineering of symbolic systems like organizations largely overlooked.

Models, Software, & Systems

Models are symbolic representations of actual (descriptive models) or contrived (prescriptive models) domains. Applied to systems engineering, models are meant to serve specific purposes: requirements analysis, simulation, software design, etc. With software as the end-product of system engineering, design models can be seen as a special case of models characterized by target (computer code) and language (executable instructions). Hence the letter ‘S’ in the MBSE acronym, which can stand for ‘system’ as well as ‘software’,

As far as practicalities are considered, the latter is the usual understanding, specifically for the use of design models to generate code, either for software applications, or as part of devices combining software and hardware.

When enterprise systems are taken into consideration, such a limited perspective comes with consequences:

  • It puts the focus on domain specific implementations, ignoring the benefits for enterprise architecture.
  • It perpetuates procedural processes built from predefined activities instead of declarative ones governed by the status of artefacts.
  • It gives up on the conceptual debt between models of business and organization on one side, models of systems on the other side.

These stand in the path of the necessary integration of enterprises architectures immersed into digital environments.

Organizations as Symbolic Systems

As social entities enterprises are set in symbolic realms: organizational, legal, and monetary. Now, due the digital transformation, even their operations are taking a symbolic turn. So, assuming models could be reinstated as abstractions at enterprise level, MBSE would become the option of choice, providing a holistic view across organizations and systems (conceptual and logical models) while encapsulating projects and applications (design models).

MBSE provides a holistic view of organisations and systems.

That distinction between symbolic and actual alignments, the former with conceptual and logical models set between organization and systems, the latter with design models set between projects and applications, is the cornerstone of enterprise architecture. Hence the benefits of implementing it through model based system engineering.

Leveraging MBSE

While MBSE frameworks supporting the final cycle of engineering (from design downstream) come with a proven track record, there is nothing equivalent upstream linking business and organization to systems, except for engineering silos using domain specific languages. Redefined in terms of enterprise architecture abstractions, MBSE could bring leveraged benefits all along the development process independently of activity, skills, organization or methods, for enterprises as well as services and solutions providers.

As a modeling framework, it would enhance the traceability and transparency for products (quality) as well as processes (delays and budgets) along and across supply chains.

‘S’ For Service

Implemented as a service, MBSE could compound the benefits of cloud-based environments (accessibility, convenience, security, etc.), and could also be customized without undermining interoperability.

To that end, MBSE as a service could be reframed in terms of:

Customers (projects): services should address cross-organizational and architecture concerns, from business intelligence to code optimization, and from portfolio management to components release.

Policy (processes): services should support full neutrality with regard to organizations and methods, which implies that tasks and work units should be defined only with regard to the status of artifacts.

Messages (artefacts): the specification of artefacts must be strictly aligned with enterprise architecture layers:

Contracts (work units and outcomes): services are to support the definition of work units and the assessment of outcomes:

  • Work units are to be defined bottom-up from artefacts.
  • Outcomes are to be assessed with regard to work units
  • Value in Models Transformations:
  • Transparency and Traceability: Two distinct model sets – Architecture Models and Implementation Models.

Endpoints (collaboration): if services are to be neutral with regard to the way they are provided, the collaboration between the wide range of is to be managed accordingly; that can only be achieved through a collaboration framework built on layered and profiled ontologies.

As a concluding remark, cross-breeding MBSE with Software as a Service (SaaS) could help to integrate systems and knowledge architectures, paving the way to a comprehensive deployment of machine learning technologies.

FURTHER READING

Squared Outline: Models As Currency

As every artifact, models can be defined by nature and function. With regard to nature, models are symbolic representations, descriptive (categories of actual instances) or prescriptive (blueprints of artifacts). With regard to function, models can be likened to currency, as they serve as means of exchange, instruments of measure, or repository.

Along that understanding, models can be neatly characterized by their intent:

  1. No use of models, direct exchange (barter) can be achieved between business analysts and software engineers.
  2. Models are needed as medium supporting exchange between organizational units with different business or technical concerns.
  3. Models are used to assess contents with regard to size, complexity, quality, …
  4. Models are kept and maintained for subsequent use or reuse.

Depending on organizations, providers and customers could then be identified, as well as modeling languages.

FURTHER READINGS

Squared Outline: Agile

The Agile development model should not be seen as a panacea or identified with specific methodologies. Instead it should be understood as a default option to be applied whenever phased solutions can be factored out.

Agile (a,b) versus phased (d,b,c,) development processes
  1. Scope: Of the twelve agile principles, ten apply to any kind of development, and only two are specific, namely shared ownership and continuous delivery .
  2. Characteristics: Assuming conditions are met, agile software engineering can be fully and neatly defined by a combination of users stories and iterative development.
  3. Alternative: When conditions cannot be met, i.e when phased solutions are required, model-based system engineering frameworks should be used to integrate business-driven projects (agile) with architecture oriented ones (phased).
  4. Variants and extensions: Even when conditions about shared ownership and continuous delivery are met, scaling issues may have to be taken into account; in that case they should be sorted out between broader business objectives on one hand, systems architecture engineering on the other hand

These guidelines are not meant to define how agile projects are to be carried out, only to determine their scope and relevance along other systems engineering processes.

Further Reading

Squared Outline: Enterprise Architecture

Whatever their nature, architectures can be defined as structured collections of assets and mechanisms shared by a set of active entities with common purposes: houses for dwelling, factories for manufacturing processes, office buildings for administrative ones, human beings for living, etc.

EASquare_PbsSols
Layers of Problems & Solution

Along that reasoning enterprises architectures should be defined in terms of one distinction and three layers:

  1. A distinction between specific and changing business contexts and opportunities on one hand, shared and stable capabilities on the other hand (represented with the Zachman’s framework above).
  2. The enterprise layer deals with the representation of business environment and objectives (aka business model), organization and processes.
  3. The system layer deals with the functionalities of supporting systems independently of platforms.
  4. The platform layer deals with actual systems implementations.

It must be noted that while the layered perspective is widely agreed (names may differ), taxonomies often overlap.

Further Reading

Redeeming Conceptual Debts

Preamble

To take advantage of their immersion into digital environments enterprises have to differentiate between data (environment’s facts), information (systems’ representations), and knowledge (enterprise behavior).

Outside / Insight (Anna Hulacova)

That cannot be achieved without ironing out the semantic discrepancies between corresponding representations.

Symbolic Representations

Along with the Symbolic System modeling paradigm, the aim of computer systems is to manage the symbolic representations of business objects and processes pertaining to enterprises contexts and concerns. That view can be summarized in terms of maps and territories:

Maps and territories of systems and their environment

Behind the various labels and modus operandi, maps can be defined on three basic layers:

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

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

These maps can be aligned with commonly agreed enterprise architecture layers, respectively for organizations and processes, systems functionalities, and platforms, with a fourth added for analytical models of business environments.

Conceptual Debt

Ideally, that alignment should pave the way to the integration of systems and knowledge architectures, as represented by the Pagoda blueprint:

Insofar as systems engineering is concerned, that would require two kinds of transformations: from conceptual to logical models (aka analysis), and from logical to physical models (aka design).

While the latter is just a matter of expertise (thank to the GoF), that’s not the case for the former which has to deal with a semantic gap between descriptions of specific and changing business domains and organizations on one side, generic and stable systems architectures on the other side.

As a result, what can be termed a conceptual debt has accumulated with the the number of logical models supporting physical ones without the backing of relevant ones for business or organization. The objective is therefore to bring all models into a broader knowledge architecture.

Models & Ontologies

As introduced by Greek philosophers, ontologies are systematic accounts of whatever is known about a domain of concern. From that point, three basic observations can be made:

  1. Ontologies are made of categories of things, beings, or phenomena; as such they may range from lexicon or simple catalogs to philosophical doctrines.
  2. Ontologies are driven by cognitive (i.e non empirical) purposes, namely the validity and consistency of symbolic representations.
  3. Ontologies are meant to be directed at specific domains of concerns, whatever their epistemic nature: engineering, business, politics, religions, mythologies, astrology, etc.

With regard to models, only the second observation puts ontologies apart: compared to models, ontologies are about understanding and are not necessarily driven by empirical purposes.

On that account ontologies appear as an option of choice for the integration of symbolic representations:

  • Data: instances identified at territory level, associated with terms or labels; they are mapped to business intelligence (environments) and operational (systems) models.
  • Information: categories associated with sets of instances; categories can be used for requirements analysis or software design.
  • Knowledge: ideas or concepts connect changing and overlapping sets of terms and categories; documents can be associated to any kind of item.

With models consistently mapped to ontologies, the conceptual debt could be restructured in the broader context of enterprise knowledge architecture.

Ontologies & Knowledge

As expounded by Davis, Shrobe, and Szolovits in their pivotal article, knowledge is made of five constituents:

  1. Surrogates, used as symbolic counterparts of actual objects and phenomena.
  2. Ontological commitments defining the categories of things that may exist in the domain under consideration.
  3. Fragmentary theory of intelligent reasoning defining what things can do or can be done with.
  4. Medium making knowledge understandable by computers.
  5. Medium making knowledge understandable by humans.

Points 1 and 5 are not concerned by the conceptual gap, the former being dealt with through the anchoring of identified individuals to surrogates (see below), and the latter being with human interfaces. That leaves points 2-4 as the conceptual hub where information models have to be integrated into knowledge architecture.

Assuming RDF (Resource Description Framework) graphs are used for knowledge representation (point 4), and taking a restaurant for example, the contents of information models (point 2) will be denoted by:

  • Primary nodes (rectangles), for elements specific to cooking and customers relationship management, to be decorated with features (bottom right).
  • Connection nodes (circles and arrows), for semantically neutral (aka syntactic) associations to be uniformly implemented across domains, e.g with predicate calculus (bottom left).
  • Semantic connectors supporting both syntactic and semantic associations (bottom, middle). 

Inserting information into knowledge architecture

Using ontologies to integrate models into knowledge architecture is to enable the restructuring of the conceptual debt.

Minding Semantic Gaps

Keeping with the financial metaphor, conceptual debts can be expressed in terms of spreads between models, and as such could be restructured through models transformation.

To begin with, all representations have to be anchored to environments through identified (#) instances.


Anchoring systems to their environment

Then, instances are to be associated to categories according to features
(properties or relationships) :

  • Customers, reservations, tables, and waiters are identified individuals managed through symbolic surrogates.
  • Names of dishes and ingredients do not refer to symbolic surrogates representing business objects, but are just labels pointing to recipes (documents).
  • Idem for the names of wines, except for exceptional vintages with identified bottles to be managed through symbolic surrogates.

As defined above, these models can be equivalently expressed as ontologies:

  • Properties are single-valued attributes.
  • Relationships define links between categories.
  • Aspects are structured sets of features meant to be valued through category instances.
  • Documents are contents to be accessed directly or through networks, (e.g preparations or wine reviews).
Fleshing out model backbone with features, relationships, and documents (black, italic)

It must be noted that the distinction between neutral and specific contents is not meant to be universal but be justified by pragmatic concerns, for instance:

  • Addresses are not defined as aspects but as category instances so that surrogates of actual addresses can be used to optimize deliveries.
  • Links to customers and addresses, being self-explanatory, can be defined as non specific.
  • The relationship from dishes to ingredients is structured and specific.

Sorting out truth-preserving constructs from domain specific ones is a key success factor for models transformation, and consequently debt restructuring.

Restructuring The Debts

Restructuring financial debts means redefining assets and incomes; with regard to systems it would mean reassessing architectures with regard to value chains.

To begin with, the Pagoda blueprint central pillar is to support the integration of systems and knowledge architectures and consequently the dynamic alignment of systems capabilities, meant to be stable and shared, with business opportunities, by nature changing and specific.

Then, the pairing of systems and knowledge architectures, like a DNA double helix, is to be used to restructure both technical and conceptual debts.


Pairing assets and incomes across architectures

With regard to technical debts, restructuring isn’t to present significant difficulties:

  • Pairing income flows (applications) to tangible assets (platforms) can be done at data level.
  • Model transformations between data (code) and information (models) levels can be achieved using homogeneous domain specific and programming languages.

Things are more complex with conceptual debts, for pairing as well as transformations:

  • There is no direct pairing because value chains (processes) are set across assets (organization).
  • Model transformations are to bridge the semantic gap between the
    symbolic representations of environments (knowledge) and systems (information) .

Nonetheless, these difficulties can be overcame combining integrated architectures and ontologies.

Regarding the structure of the conceptual debt, the income part is to be defined through business objectives (customers, products, channels, supply chain, etc.), and assets to be defined by corresponding enterprise architectures capabilities.

How to mind the gap between external and systems representations.

Regarding models transformations, ontologies will be used to mind the semantic gap between environments (knowledge) and systems (information) representations:

  • Power-types: describe instances of categories (age, income, education, …).
  • Specialization and generalization: defined with regard of intent, subsets for individuals (wine, gender), sub-types for aspects (temperature, serve in menu).
  • Knowledge based relationships (dashed line): used to describe objects and phenomena, actual, planned, or expected (face recognition of customers, influence of weather on dishes, association of wines and dishes, …
  • Concepts: introduced to relate information and knowledge: gourmet.
Ontological descriptions

With the backbones of symbolic representations soundly anchored to environment, it would be possible to complement functional and logical models with their conceptual counterpart and by doing so to eliminate conceptual debts. A symmetric policy could be applied to refactoring in order to redeem the technical debt associated to legacy code.

Managing Conceptual Debt

Like financial ones, conceptual debts are facts of life that have to be managed on a continuous basis. That can be achieved using Open Concepts to span the gap between the conceptual representation of business environments, objectives, and activities (a), and models of functional and technical architectures (b). Ontologies (c) could then leverage a seamless integration of conceptual (CD) and technical (TD) debts and consequently further in-depth digital transformation.

Using Open Concepts to consolidate technical and conceptual debts

That would ensure:

  • A separate management of models directly tied to systems, and ontologies with broader justification.
  • A distinction between a kernel (aka knowledge engine), environment profiles, and business domains.
EA & Knowledge Management

Further Reading

Squared Outline: States

States are used to describe relevant aspects in contexts and how the changes are to affect systems representations and behaviors.

On that account, events and states are complementary: the former are to notify relevant changes, the latter are to represent the partitions (²) that makes these changes relevant. Transitions are used to map the causes and effects of changes.

  1. State of physical objects.
  2. State of processes’ execution.
  3. State of actors’ expectations.
  4. State of symbolic representations.

Beside alignment with events, defining states consistently across objects, processes, and actors is to significantly enhance the traceability and transparency of architectures designs.

FURTHER READINGS

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

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: 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