Metamorphic Models

As per my Glossary page, a Metamorphic Model is: 

A series of documents and diagrams capturing the association of meaning to physical representations, and in particular, the equivalence or comparability of the respective concepts attached to different physical structures used by organizations of humans for communicating these concepts toward some end or purpose.

A framework for documenting, with the intent of communicating, how symbols are generated, manipulated, altered and replaced during some significant human activity, such as the performance of procedures intended to accomplish some goal.

Standard Presentation Forms

Within the Metamorphic Modeling Methodology, three equivalent, standard presentation forms are recognized as valid descriptions for a Metamorphic Model. These are written text description; graphical depiction; and logical formula. Depending on the audience, the author, and the purpose of the model, any one of the three can be used alone. However, it is likely under normal use that the three will be intermixed simultaneously, as each provides useful short-hands for different kinds of expressions.

A Metamorphic Model, fully developed, consists of several layers of sub-models, each built on top of and in reference to the layer below it.

Practitioners and Practical Reality

There exists, currently, in the marketplace of products and best practices, and in the less formal conventions developed by individual practitioners, other notations or descriptive approaches to document various aspects or subsets of the universe of problems addressed by the methodology. Just a handful of these are discussed in the next section.

Some of these may be more or less equivalent in structure and expressive power with the areas they overlap, and the practitioner should not consider that the standard depictions are required by the methodology. In many cases, practitioners will be required to use the notation and conventions of the integration tools available to them. From the standpoint of the methodology as defined to date, this practical reality is not a critical problem. If the practitioner uses some other tool or notation to describe, say, the detailed derivation or transformation of some subsets of data, but finds nothing available to describe the interrelationships and dependencies between and among transformations, by using the Step Model with appropriately worded references to the external depictions, then a complete Metamorphic Model would be the result.

In a similar vein, while the methodology defines a cohesive hierarchy of depictions from the broadest ”super context” to the most detailed function, it does not dictate that any or all of them must be used. To be a practitioner of the methodology simply implies that an understanding of the domain of data movement and integration, its issues, and the alternatives available exists in the mind and practices of the individual.

A practitioner of Metamorphic Modeling who never uses the formalism of the methodology, or who uses merely a token portion of it, is said to perform “small ‘m’” Metamorphic Modeling. In contrast, someone who uses the formalism in large measure, is considered to perform “big ‘M’” Metamorphic Modeling. This distinction is not a qualitative one, just a subjective measure of the practitioner’s depth and commitment to the formalism. This distinction is also made only at the project level, describing the level of use by the practitioner for a specific collection of problems, and not an indication of proficiency or expertise.

The practical reality is that there are no tools specifically designed to support the exact depictions of the formalism, and it is not readily apparent that any such tools are really needed. The number and variety of integration tools, meta data repositories, diagram drawing tools and computer-aided software engineering (CASE) tools that are available, and even dictated by specific implementation architectures, is so great that adding another tool, not tightly integrated with these others, would seem to discount the value of one more.

What this implies is that what is really being described by the Metamorphic Modeling Methodology is a way of thinking and communicating in a unified, all-encompassing manner about the movement of data through organizations.

Alternate Conventions

Within the discipline of Data Warehouse Design, the movement of data from legacy data sources into newly-defined data targets is a critical component. Yet, there are few (if any) published approaches to the design of the processes which will move this data. The best practitioners have developed their own idiosyncratic, re-usable conventions and specification techniques, but the vast majority (at least in the experience of the author) barely consider the problem to be worthy of attention. Thus the success and correctness of the data movement processes relies largely on the skill and thoroughness of the programmers, and their ability to interpret the often minimal specifications given to them.

One of the most ubiquitous design and specification techniques in the state of the practice currently amounts to the production of a spreadsheet or other list where a source data element, typically a column in a database table, is paired together with a target data element. Occasionally, there may be a note describing additional logic or manipulation, but often this very spare document represents the sum total of the design for the interface.

This level of detail basically corresponds to the level captured by the Derivation Model, which is basically just one level above the specification of individual functions. While there may be situations when such a level of detail is warranted and sufficient, as when the purpose of the movement from source to target is a one-time conversion, and the mapping is one-to-one at the row level, in most situations having only such a slim amount of information results in forcing the programmer to become the analyst and re-discover the missing requirements in the course of development, test and acceptance. Whole classes of information are missing from such a specification, such as whether the entire contents or a subset of the source should be moved, whether different subsets should be treated differently, whether there are preceding dependencies or subsequent processes that must also be run, and more.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: