Who Needs a Metamodel?

What is a metamodel?

The English prefix “meta” comes directly from the Greek meaning “beyond” or “after.” That has been extended in English usage to mean “about,” connoting a higher level of abstraction. Thus, “meta-cognition” is “thinking about thinking” and a metamodel is a model of a model.

Why have one?

“Well, the first rule is that you can’t really know anything if you just remember isolated facts and try and bang ’em back. If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form. You’ve got to have models in your head. And you’ve got to array your experience both vicarious and direct on this latticework of models. . . . You’ve got to hang experience on a latticework of models in your head.”
—Charlie Munger, American investor, businessman, and philanthropist

In the world of systems engineering and design, data from the system context and the design become valuable in the context of making design decisions. The data enable the engineer to “know” about the context, problem and design. But, as Munger points out, that “knowing” cannot happen if the data are not assembled in such a way as to make them useful.

Information science discusses the relationships of facts to the decision-making process framed in what is known as the data-information-knowledge-wisdom hierarchy (DIKW). This hierarchy is often portrayed as a pyramid—a metamodel in and of itself. (Although there is some controversy about the appropriateness of the narrowing symbology of pyramid layers as they relate to the DIKW pyramid, that is outside the scope of this post, and we will accept the classic pyramid despite any potential representational flaws.) DIKW addresses exactly the issue that Munger raises when he observes, “If the facts don’t hang together on a latticework of theory, you don’t have them in a usable form.” The DIKW latticework sets the elements in relationship to each other in a way that makes the understanding and use of those elements possible.

Fig. 1

The DIKW lattice is founded on these definitions:

Data are symbols or signs, representing stimuli or signals. According to Jennifer Rowley, Professor of Information and Communications at Manchester Metropolitan University, data are “discrete, objective facts or observations, which are unorganized and unprocessed and therefore have no meaning or value because of lack of context and interpretation.” (Rowley, Jennifer; Richard Hartley, 2006, Organizing Knowledge: An Introduction to Managing Access to Information, Ashgate Publishing.)

Data take on meaning at the next level in the DIKW hierarchy, information. Rowley defines this level as “organized or structured data, which has been processed in such a way that the information now has relevance for a specific purpose or context, and is therefore meaningful, valuable, useful and relevant.” Rowley, Jennifer (2007). The Wisdom Hierarchy: Representations of the DIKW Hierarchy, Journal of Information and Communication Science. The potential for “meaning” arises from the organization or structuring of the data.

But this single level of structure is not quite enough to effectively feed the decision-making process. In order for information to take on significant meaning, another level of structuring in the latticework is required. As the European Committee for Standardization’s official Guide to Good Practice in Knowledge Management puts it, “Knowledge is the combination of data and information, to which is added expert opinion, skills and experience, to result in a valuable asset which can be used to aid decision making.” Professor Rowley characterizes the path to knowledge as the “synthesis of multiple sources of information over time” and “organization and processing to convey understanding, experience [and] accumulated learning.” (Rowley, Jennifer; Richard Hartley, 2006, Organizing Knowledge: An Introduction to Managing Access to Information, Ashgate Publishing.) Others (like Russell Ackoff) have stressed the functional (actionable) quality of the organized information becoming knowledge. They have likened it to recipes or instructions.

The next level in the DIKW hierarchy addresses how to use the recipes of knowledge. Rowley attributes to Russell Ackoff the statement “Wisdom is the ability to increase effectiveness. Wisdom adds value, which requires the mental function that we call judgment.” This further level of structure completes the DIKW hierarchy. Like chefs knowing when to use which recipes in what combinations, systems designers operating at the wisdom level are able to make the most effective use of their knowledge of the problem before them, its context and the solution choices for it.

NOTE: If the term “wisdom” waxes too philosophical for the reader, it can also be thought of as “understanding” or, in the context of communication, “shared understanding.” Whatever the term that is used, it is where the power of effective problem solving resides.

As Munger has reminded us, the use of a metamodel is critical. The DIKW shows us why that is so. The meaning of our facts and observations is created by placing them in relationship to each other. That meaning flows from the structure (relationships) supplied by the metamodel. This concept has been recognized from perspectives as different as epistemology and poetry. T.S. Eliot in his poem The Rock (1934), asks the fundamental philosophical question at the root of metamodels.

Where is the Life we have lost in living?
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in the information?

Those are the questions for the system designer seeking to put together system design information and observations effectively to solve the problem at hand. Wisdom can’t be lost to knowledge and knowledge can’t be lost in the information. The best guardian against this is the metamodel. As we have observed elsewhere, The Meaning is in the Metamodel.

Who needs one?

We all do!

Engineers and systems designers confronting a problem to be solved are faced with the challenge of positing a solution that will actually do just that. In order to develop an understanding of the problem and the possible solutions to it, data must be gathered and assembled into information. To that information, skill and experience must be applied to create knowledge. From the knowledge, maps and instructions can be drawn to guide the design process. Understanding may then be developed which can be used to effectively make the design decisions that will result in the optimal solution to the problem.

But, as Munger pointed out, that can’t happen without the latticework. It won’t work to “just remember isolated facts and try and bang ‘em back.” Facts must be organized into information and information into knowledge which can then be used effectively to prosecute the solution-seeking process. Without the “latticework,” this won’t work. For the system designer, that latticework is the systems metamodel.

Where is the systems metamodel? Or, where should it be?

Theoretically, the systems metamodel might reside in the designer’s head. For very simple problems with relatively little data in a few categories this might work on a limited basis. But in a complex world with complex problems demanding complex solutions, this breaks down quickly. Cause and effect are non-linear and non-deterministic. Behavior is often emergent and difficult to predict. Relying on the designer’s brain space to handle all that is a fool’s errand.

The systems metamodel needs to reside in a tool database where the computational power of the tool can provide the analytic and synthetic rigor to see that nothing is overlooked or over- or undervalued. For that, a time-tested, success-proven systems metamodel is required. It must be a complete systems metamodel able to hold the entire design in relationship and reflect any changes at any stage throughout the model.

Just having a tool does not guarantee an effective systems metamodel. Tools that divide the model into pieces—requirements tools, architecture tools etc. —do not provide the systems metamodel framework for the design. Instead, they thrust the job of synthesizing the pieces into a coherent design back into the designer’s brainspace. The advantages of a comprehensive latticework are never achieved.

The same is true of tools that rely on a number of perspectives or views of a design. Even where these are augmented with data dictionaries or allow use of similarly defined elements view to view, the model remains fragmented and crippled by its lack of coherence. When it comes to synthesizing the design, there is no substitute for the systems metamodel.

These problems can be easily illustrated by looking at Fig. 3 below. Imagine a particular tool—a domain-specific or drawing centric tool. Consider the subset of elements integrated in Fig. 3 that are handled in the domain tool. Or visualize how the drawing tool splits Fig. 3 up into groups of elements showing only subsets in each view it draws. The division of the systems metamodel destroys its usefulness.

Does anybody have one now?

Does a comprehensive systems metamodel reside in any tool currently available? From their inception in the early versions of CORE in the 1990s, Vitech’s tools CORE and GENESYS have been grounded in just such a systems metamodel. At the center of the systems metamodel are the four domains in full relationship. Requirements are the basis of behavior; behavior is allocated to components; components perform the behavior which is based on the requirements. This traceability is validated and verified at every stage in the design.

Fig. 2

Building on this foundation, the systems metamodel has been extended to include the broader set of elements fundamental to the design process. The systems metamodel as instantiated in the Vitech tools is depicted in Fig. 3.

Fig. 3

Notice that the fundamental relationships are still intact but are elaborated on by the other elements and relationships that make up the design space. This systems metamodel has been proven over and over across more than 25 years in design ventures ranging from commercial and government hardware and software to process design. Design data captured here becomes usable information providing knowledge to support design choices and maximize the effectiveness of solutions. This latticework works!

It is the systems metamodel that provides the latticework of meaning for the system model. That model exists today in Vitech’s CORE and GENESYS. It has a track record of over 25 years of successful design efforts. It is not something that is perhaps coming at some indeterminate point in the future. It is here now and it works!