Modeling Paradigm

Objective

As the world turns digital, the divides between social lives, corporate businesses, and physical realities are progressively dissolved. That calls for  some unified modeling framework that would supplement OMG’s unified modeling language (UML).

Taking a leaf from the Stanford University’s Symbolic Systems Program:

“Computer systems, robots, and people are all examples of symbolic systems, agents that use meaningful symbols to represent the world around them so as to communicate and generally act in the world,”

the objective would be to consolidate the modeling concepts supporting the symbolic representation of those agents.

Models Purposes

Insofar as enterprises are concerned, models can serve three kinds of purposes:

• Describe the relevant aspects of environments (e.g., analysis models).
• Predict changes in environments and the impact of policies (e.g., business intelligence ).
• Prescribe the functionalities and implementation of supporting systems (e.g., design models).

These purposes require different modeling capabilities.

Modeling Capabilities

Models can be classified with regard of scope (partial or full description of features), and target (actual occurrences or types):

• Extensional and partial: the model describes selected features of actual occurrences (e.g organization chart or IT service management)
• Intensional and partial: the model describes selected features of types (e.g functional architecture or business strategy)
• Extensional and complete: the model describes all features of actual occurrences (e.g business process or system configuration).
• Intensional and complete: the model describes all features of types (e.g business rules or SW design)

Since analysis models describe specific business domains they are usually partial and extensional. On the contrary,  as design models are used to generate software components, they are to be intensional and complete.

what’s the difference

The Stanford’s seemingly plain definition implies: 

• A unified understanding of people, organizations, and systems as agents with the ability to process symbolic representations
• A threefold modeling paradigm: for environments, both symbolic and physical objects and phenomena, and for systems, symbolic representations of environments
• A conceptual distinction between enterprise and systems representations, the former open-ended and pragmatic, the latter finite and normalized

The significance of this modeling paradigm is best understood when compared to the one upheld for systems by the Object Management Group (OMG):

“A UML model consists of three major categories of model elements [classifiers, events, and behaviors], each of which may be used to make statements about different kinds of individual things within the system being modeled.” 

3D (left) vs 2D (right) Modeling

Whereas the Stanford paradigm encompasses environments (including agents) and their symbolic representation by systems and organizations, the OMG paradigm deals only with symbolic representations, unconcerned by what they are meant to represent. It ensues that trying to apply the OMG paradigm to enterprises and environments is doubly misleading:

• It props up a “file and forget” approach and the belief that environments will remain as they were when they were modeled, a dubious assumption for enterprises immersed in digital environments.
• Since Object-oriented (OO) modeling is the established standard for systems and software design, the implicit inference would be that objects and behaviors in business environments should also be seen through OO glasses, something akin to a reversal of Plato’s allegory of the cave, making people outside the embodiment of their shadow on the wall.

Constraining representations into classifiers, events, or behaviors may have limited impact at the application level, but that’s not the case at the systems and enterprise levels, where that one-sided approach introduces clear modeling fault lines, in particular:

• Classifiers epitomize the flight-to-abstraction syndrome: defined as an “abstract metaclass,” they can be applied to any kind of object, event, behavior, interface, aspect, etc. That’s not a problem for systems architectures given their closed context and finite number of well-identified concepts. By contrast, the range of business meanings is open-ended as well as shifting, offering an unlimited number of skylights open to abstractions that are detached from any actual semantics. 
• If anything, enterprise architecture has to make a conceptual distinction between agents (environment), roles (organization) and actors (systems). That’s not possible with the OMG paradigm.
• Likewise, a conceptual distinction is necessary between business and systems events; the former correspond to changes in environments, the latter to changes in the state of representations. It’s easy to understand the consequences of a confusion between business state of affairs (e.g., bills due), and recordings in systems (e.g., bills paid).

Modeling Scopes

Agents with symbolic processing capabilities (systems, humans, robots) can appear into four types of models:

• Enterprise: models are meant to describe assets, organization, and processes.
• Domains: models are meant to describe business objects and associated semantics independently of enterprises.
• Systems functionalities: models are meant to describe how IT systems support business processes.
• Software components: models are meant to describe how systems functionalities are implemented.

The first step is therefore to characterize modeling languages with regard to scope:

• Business process modeling languages are used to associate business domains and enterprises organization.
• Domain specific languages do the same between business domains and software components, bypassing enterprise organization and systems architecture.
• Generic modeling languages like UML are supposed to cover the whole range of targets.
• Languages like Archimate focus on the association between enterprises organization and systems functionalities.
• Contrary to modeling languages programming ones are meant to translate functionalities into software end-products. Some, like WSDL (Web Service Definition Language), can be used to map EA into service oriented architectures (SOA).

While those languages can be combined, e.g., DSLs coupled with UML or BPM, there is no consolidated representation of targets’ content except for predefined ones, e.g., by ERPs.

From Conceptual Models to Architecture Capabilities

By bringing enterprise and system concepts under a seamless modeling framework this paradigm should provide the backbone of enterprise architecture.

On one hand conceptual models describe business context and enterprise organization and processes. On the other hand architecture capabilities specify what kind of support the systems can provide to processes. In between the functional models define the symbolic representations meant to realize the capabilities.

Software components (for symbolic representations) and resources deployment (for capabilities) are hidden as implementations.

Along that understanding, and beyond lexical controversies, it ensues that two basic scales are to be aligned:

• Architectures: enterprise (concepts), systems (functionalities), and platforms (technologies).
• Models: conceptual (business context and organization), analysis (symbolic representations), design (physical implementation).

That can be best achieved with an extension of the Zachman’s Framework

From Zachman Framework to The Pagoda Blueprint

Despite its conceptual consistency and clarity of purpose, the actual imprint of the Zachman framework has remain limited. The Caminao assumption is that a simple cosmetic transformations could pave the way to a broader adoption of its basic principles.

To begin with, the tabular representation is replaced by a geometric one, each of the three main columns being morphed into a pentagon representing architecture capabilities at organizational, functional, and technical level.

The layers are then organized as a pagoda blueprint and aligned with model based 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.

Finally, the pagoda central supporting pillar is meant to integrate data, information, and knowledge processing.

Consolidated symbolic representations

The next step is to unify the symbolic representation of agents endowed with symbolic processing capability and their behaviors:

• Containers: physical (e.g locations, systems) or  symbolic (e.g domains) spaces.
• Physical entities: agents (human beings, robots, systems) or passive objects.
• Roles of agents.
• Events.
• Activities: business logic and processes control.
• Symbolic descriptions of all the above.

Modeling scopes can be generalized and characterized with regard to visibility and synchronization with their target:

• Enterprises can be seen as a subset of social organizations, with models describing assets, organization, and processes. While the descriptions are not necessarily shared by outsiders, enterprise models must support the continuity and consistency of the business objects and activities they describe.
• Business domains can be reset along a knowledge perspective, with models describing items (objects or behaviors), features, and  ontologies. These models are meant to be shared across all concerned social entities. Since those entities are supposed to take full responsibility for the continuity and consistency of domain objects and activities, models of knowledge don’t have to be synchronized with instances and can therefore be modified independently.
• System functionalities can be reset in terms of services, with models describing access to the symbolic counterparts of actual objects and activities. Those models are by nature public and descriptions have no life-cycles.
• Software components describe the implementation of symbolic representations. Models are not meant to be shared but systems objects must be kept in synch with their enterprise counterpart.

UML can then be used to bring views and models together:

• UML diagrams can be customized into BPM editors.
• UML stereotypes and profiles can be defined for specific domains and/or enterprises.

Yet, the most significant benefits are achieved when model based system engineering is used to bring together conceptual models and enterprise architectures.

Models & Ontologies

Long secure behind organizational and technical fences, enterprises must now navigate through open digitized business environments and markets. For business processes it means a seamless integration with supporting applications; for corporate governance it means keeping track of heterogeneous and changing business contexts and concerns while assessing the capability of organizations and systems to cope, adjust, and improve. For that purpose ontologies could be used to bring architectures and environments modeling into a common paradigm.

Ontologies are systematic accounts of existence for whatever is considered, in other words some explicit specification of the concepts meant to make sense of a universe of discourse. From that starting point three basic observations can be made:

1. Ontologies are made of categories of things, beings, or phenomena; as such they may range from 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 they can be: politics, religion, business, astrology, etc.

With regard to models, only the second one puts ontologies apart: contrary to models, ontologies are about understanding and not supposed to be tied to empirical purposes. That makes them a perfect tool for enterprise architects.

Ontologies & Enterprise Architecture

Confronted to the generalization of digitized environments, enterprise architects have to  deal with a two-pronged challenge: on one hand waves of raw data have to be continuously fed to information systems; on the other hand knowledge management and decision-making processes have to be integrated with operations. Both requirements can be served by the ecumenical nature of ontologies.

Regarding open and partially defined business environments, architecture capabilities can be crossed with ontologies aligned with the nature of contexts and their impact on enterprise governance e.g:

• Institutional: mandatory semantics sanctioned by regulatory authority, steady, changes subject to established procedures.
• Professional: agreed upon semantics between parties, steady, changes subject to established procedures.
• Corporate: enterprise defined semantics, changes subject to internal decision-making.
• Social: pragmatic semantics, no authority, volatile, continuous and informal changes.
• Personal: customary semantics defined by named individuals.

That coarse-grained taxonomy of contexts can be combined with a fine-grained one set along the epistemic nature of targeted items, namely the semantics of individuals: terms, documents, symbolic representations, or actual objects and phenomena. That would outline four basic concerns that may or may not be combined:

• Thesaurus: ontologies covering terms and concepts.
• Document Management: ontologies covering documents with regard to topics.
• Organization and Business: ontologies pertaining to enterprise organization, objects and activities.
• Engineering: ontologies pertaining to the symbolic representation of products and services.

Beyond the integration of business processes and supporting engineering, using profiled ontologies to frame enterprise information and knowledge is to significantly enhance transparency and traceability, as illustrated by a simple example:

• Concepts : individuals (e.g :activity_) stand for core necessary semantics detached of context or purpose.
• Categories (aka classes, aka types) represent sets of instances, with individuals standing for specific ones (e.g :invoiceInsurers).
• Power-types represent categories of categories, with individuals standing for specific partitions (e.g :person/income).
• Documents  represent contents, notably methods or models, with individuals standing for specific ones (e.g a use case for :invoiceInsurers).
• Aspects describe structural or functional descriptions that cannot be instantiated (aka valued) on their own. Individuals can stand for knowledge (e.g : :staticalRegression) or raw (aka unstructured) data.

An ontological kernel has been developed with Protégé/OWL 2, a beta version being available for comments on the Stanford/Protégé portal using the link: Caminao Ontological Kernel (CaKe_WIP).

Further Reading

• What is to be Represented
• Knowledge Architecture
• Views, Models, & Architectures
• Ontologies & Models
• On Pies and Skies: Abstraction in Models
• Conceptual Models & Abstraction Scales
• Models & Meta-models
• Ontologies & Enterprise Architecture
• Ontologies as Productive Assets
• EA & MDA
• Building a bridge
• Caminao & Archimate
• Modeling languages: differences matter

External Links

• Stanford University’s Symbolic Systems Program
• Stanford Encyclopedia of Philosophy: Models in Science