Preamble
Assuming that models are meant to depict sets of actual instances (descriptive models) or to specify how to create new ones (prescriptive models), one would expect meta-models to do the same for sets of modeling artifacts seen as some kind of “meta” instances.
Based on that understanding, a first step would be to define meta-models with regard to models semantics and abstraction scales. But that may not be enough given the range and diversity of contexts and concerns to be taken into account; to that end models and meta-models would have to defined in terms of ontologies.
Models & Semantics
With regard to systems engineering, models’ semantics are unambiguously determined by their target: business environments or systems artifacts:
- Models of business environments describe the relevant features of selected objects and behaviors, including supporting systems. Such models are said extensional as they target subsets in actual contexts.
- Models of systems artifacts specify the hardware and software components of supporting systems. Such models are said intensional as they prescribe how new artifacts are to be built.
Assuming that meta-models describe subsets of symbolic artifacts, they can be characterized by the semantics of their target. Depending on frameworks and methodologies, some approaches will use a single (aka “unified”) language to cover all aspects, whereas others will deal separately with the different aspects. Taking the Model Driven Architecture (MDA) for example, that would include platform specific (PSM), platform independent (PIM), and computation specific (CIM) models, respectively for technical, functional, and business aspects.
With model based engineering frameworks like MDA, meta-models are mostly used to support downstream models transformation focused on designs and code; extending their use to upstream models is more challenging as they would have to straddle the divide between business and system realms. For that purpose meta-models would have to support knowledge-based transitions between targeted businesses and their symbolic footprint in associated supporting systems.
The Matter of Meta
As mentioned elsewhere, meta-models should not be seen as models set at higher levels on linear abstraction scales, but as a qualitatively different kind of models representing cross concerns set on distinctive abstraction ladders. Whatever their semantics, such ladders can be neatly characterized by the semantic homogeneity of targeted instances:
- Extensional meta-models (M2ext) will categorize descriptive artifacts (locations, events, actors, documents, etc.) according to considerations other than domain-specific ones, e.g regulatory or organizational contexts and interactions with systems.
- Intensional meta-models (M2int) will categorize prescriptive artifacts (class, file, etc.) independently of implementation-specific considerations, e.g particular programming languages or operating systems.
- Mixed meta-models (M2ext-int) will group descriptive and prescriptive artifacts under some common roof, e.g to for design patterns associating extensional categories with their symbolic surrogates.
As should be expected, the semantic nature of meta-models is to determine their use.
Purpose: What’s Meta For ?
From an enterprise architecture perspective, meta-models can serve a wide range of purposes.
Governance driven meta-models focus on management, and are consequently meant to provide user-oriented documentation:
- Descriptive (extensional) ones are derived from CIMs, e.g to support regulatory or portfolio management. They can also serve to build predictive models for business intelligence.
- Prescriptive (intensional) ones are derived from PSMs, e.g to support maintenance.
- Mixed ones combine descriptive and prescriptive elements, e.g to define patterns or to support traceability and risk management. That can be achieved directly, e.g with requirements management tools, or through intermediate models, e.g PIMs.
Engineering driven meta-models are meant to support models transformation, and consequently to feed automated processes:
- Descriptive (extensional) ones are derived from CIMs and used to support transformations into other descriptive models, e.g analytical or canonical ones.
- Prescriptive (intensional) ones target platform specific models (PSM), their purpose is to define patterns for crossed transformation or code generation targeting different platforms.
- Like their governance equivalent, mixed engineering meta-models are meant to provide a conceptual bridge between descriptive and prescriptive artifacts, with the difference that they have to support automated processing.
Combined with MBSE, meta-models were supposed to provide a conceptual roof to be shared between models semantic (descriptive, prescriptive, or mixed) and enterprise architecture purposes (governance or engineering). That didn’t happen.
In the Jungle of Profiles
Despite conceptual soundness and potential benefits, the actual deployments of model based systems engineering (MBSE) remain focused on software development, mainly code generation from design models.
One of the primary reason for that limited employ is a lack of a principled framework supporting the integration of the whole modeling cycle, from requirements to design, and the ensuing pitfalls to models reuse; a motley of profiles (227 and counting from the Object Management Group) is consequently needed to deal with the wide range of EA contexts and concerns. But the mix of purposes can be confusing, as illustrated by the holiday-maker shopping list of intents for the OMG’s UAFP specifications:
- Extraction of specified and custom models from an integrated architecture description (AD).
- Describe a system from a set of stakeholders’ concerns through a set of predefined viewpoints and associated views.
- Reflect custom viewpoints or to develop more formal extensions for new viewpoints.
- Model architectures for a broad range of complex systems, which may include hardware, software, data, personnel, and facility elements;
- Model consistent architectures for system-of-systems (SoS) down to lower levels of design and implementation;
- Support the analysis, specification, design, and verification of complex systems; and
- Improve the ability to exchange architecture information among related tools that are SysML based and tools that are based on other standards.
- Provide a standard representation for AD support for Defense Organizations.
- Support a standard representation for non-defense organizations’ ADs as part of their Systems Engineering (SE) technical processes.
- Support US Department of Defense Architecture Framework (DoDAF) 2.02, Canada’s Department of National Defense Architecture Framework (DNDAF), North Atlantic Treaty Organization (NATO) Architecture Framework (NAF) v 3.1.
- Based upon the DoDAF 2.0.2 Domain Metamodel (DM2) and the MODAF ontological data exchange mechanism (MODEM).
- Improve the ability to exchange architecture data between related tools that are UML/SysML based and tools that are based on other standards.
- Conforms to terms defined in the ISO/IEC/IEEE 42010 standard for architecture description,
- Specifies a SysML v1.3 profile.
As it happened (aeons ago …), ontologies have been introduced to tackle that difficulty.
Sorting Out Contexts & Concerns: Ontologies
As originally understood by ancient Greek philosophers, ontologies define the epistemic nature (aka condition of existence) for whatever is considered, in our case enterprise architecture contexts and concerns.
To begin with, ontologies can be designed according to the nature of contents (concepts, documents, categories, or artifacts), layers (environment, enterprise, systems, platforms), and contexts (institutional, professional, corporate, social, or personal); applied to enterprise concerns that would entail:
- Thesaurus: for the whole range of terms and concepts independently of instances (intensional).
- Documents: for information contents independently of actual instances (intensional).
- Business and operations: for enterprise organization, objects and activities (extensional).
- Engineering: for systems surrogates associated to enterprise organization and business objects and activities (intensional).
Then, models pertaining to enterprise architectures can be profiled according to layers (environment, enterprise, systems, platforms), and contexts (institutional, professional, corporate, social, or personal):
Finally, models, meta-models, and profiles can be integrated into an ontological framework:
Ontologies so appear as the matrix of all modeling languages, encompassing models, meta-models, profiles, and every kind of abstraction, which makes them the best option for EA knowledge management.
The Caminao Ontological Kernel provides a test-bed as well as a workbench for that approach, with a case study for the EU GDPR regulation.
Further Reading
- Thread: Abstractions
- Thread: Model Based Systems Engineering
- Modeling Paradigm
- Modeling Languages: Differences Matter
- Conceptual Models & Abstraction Scales
- Open Concepts
- Open Concepts Will Make You Free
- Abstractions and Emerging Architectures
- UML’s Semantic Master Key, Lost & Found
- EA Documentation: Taking Words for Systems
- Models Transformation
- Knowledge Based Models Transformation