An alliance of metamodels

metapattern meets RM-ODP

Pieter Wisse

Metapattern is a powerful approach to conceptual information modeling. It is not a comprehensive development approach for information systems. Therefore, it must be combined with other metamodels, methods, and so on.
The idea behind combining forces, or forming an alliance, should always be this: that a particular task must be fulfilled but is too big for a single unit to complete successfully. When several units contribute their efforts, a task's critical mass may be, literally or figuratively, overpowered.

A range of alliance types

Success by alliance comes at the price of coordination, though. This implies that an alliance is never totally homogeneous, as units contributing similar efforts would remain, by definition, uncoordinated. Many people can attempt to lift a rock. If their aggregate energy more than equals the rock's weight, then it is only when they apply energy simultaneously that the rock will move. Making people lift on the count of three, for example, would be a coordinating effort.
At the other extreme of typical alliances, as shown in Figure 1, all efforts by units are completely heterogeneous. Coordination becomes prominent. Considering the characteristics of participating units, a task is decomposed into disjunct aspects. For the completion of the overall task, actual efforts are matched to such aspects.

Figure 1: Spectrum of alliances.

In practical life, alliances lie somewhere in-between. It depends on the requirement of coordination as the only different effort and, on the other hand, of all efforts being different. Looking at this range, it should be evident that alliance and organization are synonyms. The term alliance helps to stress the importance of contributions, while the term organization has become associated with the (static) structure of participating units.

Autonomy

I have purposely called participants of an alliance units. A unit suggests autonomy, making clear that every alliance exists because of a fundamental tension. The assumption is that, given the opportunity, a unit would rather execute the task by itself, exclusively reaping the rewards. An important aspect of coordination, therefore, is to counteract hegemony.
Ideally, units exhibit self-control. Aware that their particular efforts are insufficient for task completion, they recognize the contributions of other units. Each unit wants its autonomy respected, relinquishing in turn some of its original autonomy. It accepts coordination for the benefit of enjoying a fair share of success which would escape it without contributing to the alliance.

Variety

The second reason to use the term unit is its generality. It covers a wide variety of phenomena. A unit may be an individual person or an organizational unit. Unit can also be given a less traditional meaning, such as that of method or paradigm.
The latest developments in the philosophy of science acknowledge that the complexity of reality cannot be explained or changed according to a single paradigm. This has led to acceptance of multiparadigmatic approaches. No paradigm (unit) may claim absolute priority. The proper alliance of such units supports the successful achievement of the specific, often complex (scientific) task.

Scientific aspects

An application of the metaparadigm of multiparadigmatically coordinated efforts should be the development of complex information systems. Such development is never mere deployment of scientific results achieved elsewhere. It follows from the need for innovation that a development process has scientific aspects, too. Without a scientific attitude—healthy curiosity—it would be impossible to gain sufficient understanding of the problem, opportunity, or situation. It would be equally impossible to design, construct and implement an optimal information system as the solution.

Hegemony and reduction

A scientific attitude alone, though, could be disastrous. For example: if the task is to improve the quality of service in a government agency. Other aspects need to be recognized and treated accordingly.
Suppose that a particular unit would perfectly match some aspect x of the task, but would be unsuitable for aspect y. And suppose, too, that the unit one-sidedly declared its paradigm valid for both aspects x and y. (This often happens with the best of intentions: therein even lies the danger.)
Such a course of events is known in philosophical discourse as reductionism, or simply reduction. What happens is that understanding, and subsequent practice, of y is reduced to the theory and practice underlying x. The difference between an open alliance and reduction is sketched in Figure 2.

Figure 2: Reduction of conceptual modeling by construction orientation.

Of course, reduction can work in any direction. It is equally harmful to view tool construction, including characteristic precision, as if the situation for its intended application must be charted. Such opposite reduction, when compared to Figure 2, is shown in Figure 3.

Figure 3: Reduction of construction by orientation at conceptual modeling.

Reductionist practices in this sense are normal in human society, and not always bad. Someone visiting a doctor expects to be treated as a patient. But a doctor who does not meet the patient as a person pursues professional reduction much too far—that is, she or he is not really a professional.
The saying that "To a man with a hammer, everything looks like a nail" expresses the practice of reduction well.
A major issue of task coordination can now be restated. An alliance can only remain successful when reduction by any participating unit is avoided or, when that is discovered as too ambitious, kept at an acceptable level. Ideally, every unit combats reductionist urges itself.

Strength and weakness

Coaches of top performing sports teams consistently select players based on their strengths. One such strength is the ability to avoid exhibiting eventual weaknesses. Thus, a team may be considered a combination of participating strengths.
Development of a complex information system is like a team effort. Units should be included on the basis of how well they match particular aspects. Any weakness concerning other aspects do not matter, as different units will properly match them.

knowledge and ignorance

A variation of this theme is that one unit must be completely knowledgeable about all other participating units. It is important for their task-oriented efforts to be optimally coordinated. This makes it both necessary and sufficient for a particular unit to know how to interact with other units. It can, and for the sake of effectiveness and efficiency should, be totally ignorant about how another unit internally acts to produce such contributing efforts.

Metapattern as participating unit

To develop a fitting information system, it is necessary to learn about the purpose(s) it has to serve. This entails acquiring an understanding of reality. Such understanding should be as rational as possible, in the sense that reality is viewed as essentially structured.
What having a structure (or its equivalent, being a system) assumes is that elements exist, with relationships between them. Special status is awarded to the element of the environment or, to be more precise, the rest of reality.
A strength of metapattern lies in its support for more realistically understanding reality. It escapes the traditional limitation of direct synchronization between the concepts of element (called real object, or simply object) and its behavior. Usually, a one-to-one correspondence is defined. As this correspondence is implicitly assumed, it is difficult to escape.
With metapattern, an object may be attributed with a multitude of behaviors (intexts), with each behavior unambiguously defined for a particular context.
Metapattern includes a simple method for integrated visualization of multiple contexts, of partial objects each having its own behavior or intext, and of integration of partial objects to constitute an overall object.
The principle of contextual differentiation of object behavior opens the possibility to reflect comprehensively on greater complexity of reality. Such conceptual models may be easily documented and communicated using metapattern's simple notation.
The emphasis on conceptual modeling as a strength is a clear indication of metapattern's weakness. It is not a paradigm, or metamodel, to support predominately technological aspects of (digital) information system development. In full recognition of this weakness, I advise not applying metapattern beyond the area of its evident strengths; that is, outside conceptual modeling. Otherwise, aspects requiring a characteristic paradigm for their optimal development would be reduced to what metapattern allows. With the focus of metapattern on (life in) reality, the equally necessary focus on tool technology would suffer.

Unit candidate

With metapattern optimally matched to conceptual aspects of development, one or more missing units are needed to successfully complete the overall development task. What are suitable candidates? Does a unit even exist that shows strengths for all aspects, including conceptual modeling? Such a unit would make it unnecessary to let metapattern participate in development.
The number of methods, paradigms or metamodels (call it what you will) offered as employable units for information system development has grown beyond reviewing capacity. Here, instead, only one unit is considered for alliance. This serious candidate must be introduced first.

Open distributed processing

A pervasive characteristic of western society is its variety, occurring for reasons that range from free competition to state intervention. Competition creates (some) variety, offering consumers at least the illusion of choice. Historically, when a state intervenes, it is often without regard for resources elsewhere. A famous case involves different widths between rails, causing carriages to be transferred at some international borders from one chassis to another.
At any rate, variety is a way of life; it’s a reality. Information processing is no exception. As with a train strictly keeping to a proprietary track, information processing remains relatively simple when performed in isolation; that is, using stand-alone resources. Increasingly, however, resources are combined for information processing, as a counter-phenomenon to variety exists, exhibiting itself in cooperation and communication. Adding to the complexity is that many such resources have not been developed with an alliance of different units in mind. (The recurring theme of alliance is, we hope, not lost on the reader.)
Accepting the fundamental variety—even honoring it where it supports special requirements and/or promotes innovation—the question becomes how distributed, often heterogeneous resources can still be successfully combined for information processing.
Throughout the ages, the answer has been: establish an agreement on exchange format (Figure 4). Such agreements are commonly known as standards. Again, digital information processing is no exception.

Figure 4: The principle of standardization.

Standards originate from several sources. Official, or de jure, standards are issued by Standards Developing Organizations (SDOs) in which nations participate, usually represented by their respective national standardization bodies. Actively involved in international standards for information processing are the International Telecommunications Union (ITU), the International Electro-technical Commission (IEC), and the International Organization for Standardization (ISO). ITU and ISO have a long-established healthy tradition of adopting each other's standards. More recently, ISO and IEC have joined forces as far as information processing standards are concerned; they work together through Joint Technical Committees (JTCs).
Over the years, many standards have been developed to combine resources over distance (telecommunications), and/or to bridge technical heterogeneity. A standardized framework for information processing—a metastandard—has been developed by ISO/IEC. It is called the Reference Model for Open Distributed Processing (RM-ODP). It goes without saying that RM-ODP is oriented at distributed information processing. Otherwise, there would be no need for a standard. The standard's objective is for information processing to be open; that is, no obstacles for successful information processing will remain when all participating units conform with RM-ODP. It is, so to speak, the standard which secures the opening required for successful exchange between resources that may otherwise be different from each other. (An alternative name for RM-ODP might be reference model for allied information processing resources, which directly illuminates the critical issue addressed by the standard.)

Technical orientation

The fact that official standards have a predominantly technical orientation is an early indicator that metapattern and RM-ODP could complement each other. A related example would be a simple telephone connection; an agreement must be made about how to transfer elementary signals while preserving (more accurately, reconstructing) their original structure to represent higher-level signals. Not standardized is what such higher-level signals, or information, mean. The vocabulary of the conversants is also not subject to standardization. Again, it is the signals, at an intentionally meaningless level from the (end) user perspective, which are standardized.
It is this limitation—avoiding any attempt at standardizing interpretation by (end) users—that has spurred technological development. It is the perfect example of a successful alliance. The aspects of tool use and tool development meet when base signals are transferred.
A note of warning is in order (see different meanings of object, below, for more). Aspects of communications such as phonetics, syntax, semantics and pragmatics are relative. From a particular perspective, they all have a corresponding meaning. Thus, pragmatics are also relevant when applying a strictly technological focus. Pragmatics with a life focus, however, mean something different. At the minimum, levels are shifting. It seems reasonable to suggest that, for example, a tool's internal semantics are in many ways its user's external phonetics. Semantics, therefore, within a tool such as an information system, is a different concept from semantics as experienced and practiced outside by the tool user. Even though it is a simplification, thinking in terms of restraining descriptions of communication aspects by focus—and only then investigating how they might correspond—may eliminate much confusion between collaborating units. Figure 5 shows a general example.

Figure 5: Possible shift of communicative (semiotic) categories between different focuses.

Figure 5 raises awareness that some communication or behavioral aspects are impossible to translate between focuses. This cannot be changed; it’s just the way it is. Such fundamental differences should be fully exploited, not denied—and that is why essentially different methods, metamodels, or whatever they are called, are required when a complex task may be characterized by a multitude of focuses. Success calls for an alliance of metamodels.
Again, meaning should not be reduced to a single focus. Such familiar use of similar terminology has unconsciously obstructed communication, rather than promoting it, as meanings can differ radically. Insufficient awareness of real differences often makes units believe they are competing while, in fact, they could act as allies to their mutual advantage.

Ambiguity

Earlier, I labeled the concerns of standardization bodies such as the ISO as primarily technical in nature. Does RM-ODP conform to this idea of a technical standard, even though it is a metastandard?
Two answers are possible. The first takes a point of view outside RM-ODP. For example, if viewed from the conceptual perspective of metapattern, the technical nature of RM-ODP is obvious; the standard primarily addresses concerns of construction, implementation and operational management of distributed tools for information processing—concerns not addressed by metapattern. An alliance of both metamodels, therefore, can make complex development tasks feasible.
It may look different, however, from inside RM-ODP. It is not so much the claim that the information viewpoint is completely covered by the standard. Being a metastandard, an alliance could well consist of metapattern supporting development of information views. In fact, this would be a real opportunity, except for RM-ODP insistence on the use of basic modeling concepts that show weaknesses for conceptual modeling when compared to metapattern.

Comparison

A short overview of some of RM-ODP's basic modeling concepts may suffice to appreciate the difference with metapattern with regard to conceptual modeling.
What is reality according to RM-ODP? First of all, reality is considered a universe of discourse. And "[t]he elements of the universe of discourse are entities and propositions."
An entity is defined by RM-ODP as "any concrete or abstract thing of interest." This would make an entity, or its synonyms, thing and element, the same concept as metapattern's (real) object.
A proposition is "an observable fact or state of affairs involving one or more entities." This (last) sentence itself is a proposition, too. The ontology of RM-ODP, however, is difficult to extract. It seems that the "universe" is made up of entities, while the "discourse" about it occurs through propositions. Metapattern tries to separate views of reality, on the one hand, and views of reality's representation (information) on the other.
RM-ODP defines an object as "a model of an entity." With object equivalent to entity, in metapattern terms the question must read: What is the model of an object? The answer needs an introduction.
When a real object (entity in RM-ODP) is observed from a behavioral perspective, variety must be acknowledged. Metapattern states that an object is presumed to be an overall object, consisting of partial objects, each attributing with different behavior. Now, what is the model of an overall object? It is a configuration of information objects, specifying multiple contexts as required to accommodate diverse behaviors; the partial objects are represented by unique nodes in this configuration, connecting every context with a corresponding intext which specifies the partial object's static and dynamic behavior.
But doesn’t RM-ODP accomplish the same result through naming contexts? It defines a name as "a term which, in a given naming context, refers to an entity." What multiple naming contexts do solve are problems of synonyms and, in particular, homonyms. They do not directly support, however, finely grained differentiation of behavior.
What about object interfaces in RM-ODP? Are they not equivalent to metapattern's contexts? To some extent they are. It could be possible to express an interface in terms of other objects (metapattern: information objects) and their relationships. A disadvantage of this interpretation is that the concept of interface is no longer available to support different implementations of behavior within a single metapattern-based context. It would thus be wise to keep the technologically oriented meaning of RM-ODP's concept of interface intact.
Whichever way interface is interpreted, RM-ODP's weakness in conceptual modeling, when compared to metapattern, should be apparent from a short comparison. A full review would be far beyond the competence of the author, anyway. In general, a professional conceptual modeler should retain a balance between knowledge and ignorance of technological issues.

Characteristic meanings of object

From this short discussion it may be observed that the use of the term object is typical for the shift that, by definition, occurs between focuses. Applying RM-ODP's terminology, object seems a pragmatic concept, corresponding, as it should, with RM-ODP's characteristic focus on tool technology. Metapattern does not even recognize that technically pragmatic concept as it concentrates on conceptual modeling. It puts forward the concept of information object to enable translation of conceptual models onto construction models. As such, metapattern's information object may well be labeled an intermediary concept, too. It paves the way for the specifications of tools which, when constructed and made available, are integrated into the whole of reality.
Within metapattern, object is also a pragmatic concept. Indeed, terminology is highly isomorphic. But according to metapattern, what is meant by this is an object behaving in the totality of reality. This is different from RM-ODP's object, which behaves within a particular information system.
Ideally, pragmatics of real objects are exhaustively mapped onto pragmatics of digital technology objects. But such a full representation is illusive. The Belgian painter Magritte (1898-1967) humorously exposed the core of the insoluble problem when he included the statement "this is not a pipe" in a painting in which he figured a pipe. Thus, in a metapattern-based conceptual model, the term by which an(other) partial object is named should not share the nil identity with that partial object. Instead, the reference to the term must be considered a property of the partial object named. Otherwise, confusion sets in between the proper object and its representation. It is not the name proper which is an object's property in the sense of complete ownership; it is one object having or given the use of another object for its name. Remember that what is modeled concerning an object's name is, again, a representation. Out there in reality, the name is also an object.
It is difficult to illustrate the basic incongruence of real object and representation, but the reason for this problem is quite simple: any figure or model, would, by definition, imply the appearance of the real object through a representation. An opposite problem caused by the nature of a model: infinite regression rules the representation of a representation. Therefore, a model of how a representational object stands to the real object it represents needs to be simplified. In Figure 6, a choice is made for the real object 1 to be interpreted as a representational object. (The “real” cube represented must be understood to be missing by default.)

Figure 6: Incongruence between object and representation.

With real object 2 considered a name, it may be applied to represent real object 1. It is precisely this act of assigning representation which creates both relationship and distance between the two real objects involved. What their relationship amounts to has been extensively theorized about by disciplines such as semiotics. Now, with metapattern, their preferred distance can also be formally expressed. As indicated above, it follows that a representation of a representation should be excluded from sharing the nil identity with the representation of the real object represented. To avoid behavioral confusion, they must not participate as partial objects in the same overall object. This is shown in Figure 7.

Figure 7: Constraint on the relationship between real object and representational object.

Without such understanding, it is difficult to avoid substituting, rather than simulating, the behavior of the representational object for that of the real object. Starting the analysis from higher-order representations increases the reduction of reality even more. Is substitution, and its danger, not exemplary for technocratic approaches to reality?
Conceptual modeling is least reductionist when based on, and performed using, an ontological, reality-oriented system of (meta)concepts. A technologically-based metamodel can never be made to express what it different from its origin. RM-ODP, for example, can hardly be considered a metamodel of reality. All it presumes to exist are entities (things, elements). Structural elaborations are grounded in the tool technology. That focus must be complemented.
Only when the name-as-real-object is distinguished from the name's representation in the conceptual model is it possible to appreciate that, in reality, the object-object and the name-object are ontologically different objects (to use just two examples). They are representationally related, which is important. But, to repeat, it does not qualify them to be considered partial objects of one and the same overall object. Magritte made this perfectly clear long ago in his brilliantly immediate way. For C.S. Peirce (1839-1914) it was the principle of his semiotic philosophy.
Denying the fundamental dissociation of an object and its representation is also at the root of branches of, say, idealized artificial intelligence, which aims to equal and even surpass human intelligence. The answer: there is nothing artificial about intelligence. Instead, every real object should be considered to have its own, characteristic intelligence. Therefore, digital machine intelligence is a much better term. It acknowledges that a machine may be intelligent but essentially different from a human being.
Important choices about necessary limitations should be made through conceptual modeling. When conceptual information models are forced within a basically technical frame of reference (metamodel), it is almost a certainty that choices will never be optimal. This reduction is not yet fully evident with information systems for control of closed, technical systems. The unambiguity of technical system behavior is even, so to speak, preordained. Thus, there are no fundamental differences between the behavioral domains of technical system and the controlling tool. The behavior to be modeled is the technology. (And that is why traditional object orientation is successful for information systems controlling technical systems.)
But a tool for use in an open, social or socio-technical system cannot escape the reality of different behavioral domains. Representational objects in the behavioral domain within the tool itself can simulate real objects in the behavioral domain of the wider social system, but they can never substitute for them. With substitution a pure impossibility, the range of possibilities for simulation indicates the risk associated with confusing real objects with tool-based objects.
One of the conclusions from this philosophical analysis should be that RM-ODP's basic modeling concepts may still operate satisfactorily for conceptual modeling of closed, technical systems. Then, the simple, one-to-one representational correspondence between real object (RM-ODP: entity) and information object (RM-ODP: object) will often not constrain what is minimally included of a conceptual model.
The expressive power of RM-ODP's basic modeling concepts will often be insufficient, however, for conceptual modeling of social systems, characterized as these are by qualitatively greater variety and complexity of (real) object behavior. Metapattern's richer language invites the modeler to respect behavioral diversity of a real object, resulting in conceptual models with a closer simulation fit. In a good alliance, RM-ODP's basic modeling concepts should not be made to also conceptually model reality. They can be put to effective use starting with the creation of a tool-oriented construction model from the conceptual model created earlier with metapattern.

Not reduction, but mapping for alliance

The obstacle which RM-ODP has formally (with conformance requirements part of the standard) erected against a successful alliance can, in principle, be easily removed. At the same time, it is difficult to achieve, as it needs a change of perspective from inside to outside RM-ODP. The requirement for some basic modeling concepts to be universally applied in all of RM-ODP's viewpoints does not serve any real purpose. Actually, it risks reducing the quality of overall development by forcing the extension of technical interpretations on conceptual issues. This is a mistaken approach, encountered in attempts to extend the metamodel of software engineering to conceptual modeling. The isomorphism between what is seen with a focus on life and on tool technology, respectively, exists only with a single focus. A dual focus (or multi-paradigmatic approach) reveals a superficial isomorphism at most, to say nothing about semantics or pragmatics. A small conceptual isomorphism is always insufficient to deal with issues which are qualitatively different by nature.
Again, reduction, in its philosophical sense, is difficult to defeat. It is seductive, and it seems easy to transfer success with one aspect to another. Why trust another unit to contribute? Why spend the extra effort on coordination? And why share benefits of success? It often takes an experience of failure to realize the benefits of alliance.
A standard is achieved rationally, and with the maximum guarantee of quality, when concepts can be successfully mapped between aspects (or focuses), one to another, or one to a configuration of others.

Source of inspiration

When the strengths and weaknesses of RM-ODP are explicitly recognized, metapattern may inspire some improvements in the next version of the ISO/IEC metastandards.
The idea of multiple contexts lends itself to distributed information processing. What must be established is, if not an unambiguous procedure, at least a heuristic for mapping conceptual diversity—and the opportunities provided by it—to the relevant (distributed) configuration for information processing.
Other relevant issues are metapattern's “standardized” conceptual mechanisms for time and validity control. With respect to time, for example, RM-ODP applied the epoch concept. It should be no problem to refine it to the level of control suggested by metapattern.
What also must be developed in detail when an alliance is pursued are mappings between metapattern and the schemata required by RM-ODP's information viewpoint. In many ways, what are called invariant, static and dynamic schemata in RM-ODP are combined by metapattern. One question is: What is still missing, if anything?
In preparing for and eventually evaluating and alliance, the overriding awareness should be that success comes through building on genuine strengths of participating units rather than through compensating weaknesses.
Metapattern must be open to continuous improvement. It is hoped that professional conceptual modelers will be inspired to make valuable contributions.

This text was included in Metapattern: context and time in information models (Addison-Wesley, 2001, see Appendix B).