In The Treachery of images, a famous painting by René Magritte, the artist painted the tobacco pipe depicted in Figure 1, labeled it with the caption "Ceci n'est pas une pipe.", or "This is not a pipe". He later remarked:
The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it's just a representation, is it not? So if I had written on my picture 'This is a pipe', I'd have been lying!
Magritte's work highlights that even through a painting of a pipe may be used for many purposes, none include smoking tobacco. J. Rothenberg captures the essence of making such representations of reality in the Nature of Modeling:
Modeling, in the broadest sense, is the cost-effective use of something in place of something else for some cognitive purpose. It allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger, and irreversibility of reality.
Metamodeling, or more formally, metadata modeling involves the conceptual abstraction ('meta') of models themselves. This process of abstraction involves integrating theory, concepts, configurations, rules, and constraints. The results must be adequate for the analysis, construction, and development of models that conform to the metamodel they are subordinate to. As in Magritte's painting, there is a recursive nature to these representations, as they must apply to a variety of modeling environments, representing:
- the objects being modeled
- the symbols and properties used to represent these objects
- the unique instances of these idealized objects and how they are managed across their lifecycle
- the relationships between these elements and the goals, strategies, and objectives of the organization
- how these are all organized to assure that the fitness of all elements for achieving their intended purposes is adequate.
The meta-model for an architecture definition typically focuses on the data which is to be produced, rather than focusing on the structure or packaging of the artifacts that provide that information content. This architectural data identifies, defines, and specifies the information needed to describe actors and objects within one or more viewpoints within a system of interest. Artifacts provide these viewpoints, but their architecture definition must be sufficiently comprehensive to demonstrate that the information is adequate for achieving the outcomes being pursued by all stakeholders. Until a thorough stakeholder analysis has been completed for those metamodels and child models, gaps in needed content may cause risk to travel to downstream processes.
In his paper,On the Unification Power of Models, Jean Bézivin describes this hierarchy of metamodels and models and the need for them to facilitate robust integration across the landscape being modeled:
In particular, one dimension that is absent in the previous discussion is the need for coordinating different maps. Since we said that we will use different maps to express different views on a given territory, and since these maps may be jointly used, then we must take some actions to allow the coordination between these views. Let us suppose that towns, on different maps, are differently drawn. We would need to assess that these towns correspond to similar entities, enabling them to act as "join points" between different views. We may state that each legend defines some kind of domain specific language, but how may these languages be related? The limits of the analogy show up here in this case, because what we would need is a language for describing legends, what we shall call a metametamodel.
To achieve this synthesis, the class of valid models associated with their common metamodel must conform to that metamodel in the same fashion that a computer program conforms to the grammar of the programming language in which it was written. And just as programmers and compilers are inseparable in creating, recognizing, and transforming source code into executing systems with predictable behavior, the tools for modeling metamodels should collective provide capabilities for constructing models in a domain specific language, augmented by validation rules in an object constraint language, to assure that the relationships across elements can be created and maintained in a consistent and complete state over their lifecycle.
An example will reinforce the nature of the types of objects which make up a metamodel, and how these elements support the modeling process itself. In this example, we will examine how to represent the information necessary to manage the elements of a capability, as it transitions from one configuration of information to another over time. Background on this topic is provided in more detail here. In architectural terms, the model's elements can be mapped from a program management information architecture: tasks are activities, ways are guidance, means are performers, conditions are constraints, standards are a particular sort of guidance, and desired effects are changes in the states of various resources, like people, capital, time, or material. This example is interesting because its elements are necessary for tracking causes and effects across changes in element definitions and relationships over time. These features enable predicate logic to be utilized to trace a full chain of events across time and space and isolate the chain of desirable outcomes from those which tie up precious resources but lead down dead ends or to undesirable outcomes. Such properties are essential to understanding how to effectively manage a range of capabilities over time, using such technologies as predictive analytics and proactive quality interventions.
First, a top-level foundation must be established to organize and record classifications and relationships between key entities within this domain:
- things - single individuals or groupings of individuals
- individuals - instances of a thing that exists in space and time
- types - which group things together
- tuples - an ordered pair of things used to describe types of relationships
These relationships draw from patterns which have been used in a variety of ontologies, conceptual schemes, and logical data models, and which underlie the structure of mature modeling frameworks in broad use today:
- composition (whole & part), since everything has parts, and everything is part of something else.
- generalization and specialization (super-types & sub-types), since everything can be classified as something.
- temporal ordering (before & after), since everything comes after something and before something else.,
- overlap (four-dimensional shared extents), since everything has parts that may be shared with other things. In particular, the overlap between elements is the relationship that binds a persistent whole to its changing parts.
Composition and specialization apply to all architectural concepts. Temporal ordering is needed to arrange things in time. Overlap is necessary to describe things that interface together without being contained within each other (such as in a whole-part relationship). From these constructions, a conceptual metamodel can be defined which provides a common taxonomy for all architecture elements that make use of these relationships:
- All the pieces and parts of a described architecture must be founded upon things that are real in the world.
- Everything of architectural interest has four dimensions, that is, they exist in space and time.
- Everything of architectural interest has parts. In particular, everything has both temporal parts and spatial parts. This is the basis for asserting the identity of a whole as its parts change over time.
- Everything of architectural interest is also a sort of something. Indeed, any given thing can be a sort of many different things at the same time, and over time, can change what this classification is.
- Everything of architectural interest should be measured. Something that exists in space and time can be observed. Anything that can be observed can be measured. At a minimum, we can measure the size and the position of any real thing of architectural interest.
When one contrasts the depiction of DODAF's metamodel of capabilities and compares it to the equivalent formal data model (DM2, figure 3). the data structures needed to track performance over time are clearly more complicated; the DoD developed and has maintained DM2 to import and warehouse architecture information produced by its subcontractors. It is not a coincidence that the elements used to perform such tracking are each a type of resource. These resources are interesting in this context because they must serve as a unit of measure, a medium of exchange, or a store of value. Their quantification, classification, and dynamic properties are essential to the effective management of the things they involve, regardless of whether those things are physical objects, individuals and groups, or metadata about these elements themselves.
There is a wide range of architecture tools that can collect, organize, and store architecture data. The focus on data supports the production of models which can be tailored for multiple fit-for-purpose uses. When these models are sufficiently robust, these tools may also support analysis and simulation of the content in support of core decision making processes. Consequently, tools are expected to comply with the well-formed specifications that enable exchanging the underlying architectural data.
The resulting logical data model is shown in figure 3, which was instantiated from the metamodel shown in figure 2. It is important to understand the implementation of the logical data model in relation to the metamodel itself. The model's elements are necessary to represent all the different types of resources, their involvement in managing the architectural elements described above, and managing the exchange of information about the architectural elements across tools. Once you think you understand this simple set of elements, you can dive into UML's metamodel, though to get much out of that, you should first familiarize yourself with its meta-object facility. which is a metametamodel for UML, expressed in (what else) UML.
The portion of an architecture's meta-model that captures and manages capabilities and their relationships must support a wide variety of disciplines, including systems engineering, planning, resource management, portfolio management, supply chain management, operations, and integration processes. All the artifacts produced by these disciplines must conform to a consistent metamodel, especially if the information used across these disciplines is expected to be reused. This can be challenging since each discipline tends to have their own standards, and these are often defined and managed by different communities of practice, standards bodies, and compliance determination mechanisms. Since architectural descriptions are employed at many levels, contexts, and for many purposes within an organization, the structural and content definitions of these elements can vary in content, structure, and level of detail; unfortunately, when they each have their own definitions of this information, integrating this information together can be problematic, especially without if the underlying metamodels themselves have not been integrated; when this is the case, the risk of changing these elements should be captured and actively mitigated to minimize the rework required.