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.
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 design models).
- Prescribe the functionalities and implementation of supporting systems (e.g business intelligence).
These purposes require different 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.
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.
- 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:
- Ontologies are made of categories of things, beings, or phenomena; as such they may range from simple catalogs to philosophical doctrines.
- Ontologies are driven by cognitive (i.e non empirical) purposes, namely the validity and consistency of symbolic representations.
- 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.
- 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