Value Proposition of Metamorphic Modeling

Integration projects are started for the following reasons: the replacement of core application systems, especially such applications as enterprise resource planning (ERP) systems,the creation of enterprise data warehousing or business intelligence capabilities, the establishment of supply chain automation and business to business “e-Commerce”, the automation of business processes through workflow,the replacement or introduction of infrastructure, especially of “middleware”, the federation and synchronization of corporate systems due to mergers, the establishment of a “service oriented architecture,” and the introduction of Semantic Web technologies, especially such things as the Resource Description Framework (RDF) and the Web Ontology Language (OWL).

Each of these endeavors have their merits and value to the organization, some more than others at different times in the organization’s lifetime. While each of these projects can share data integration requirements, they also have vast differences in requirements such as throughput, periodicity (the continuum from real-time, instant synchronization to periodic batch update), communication infrastructure, and data storage strategy. Despite the similarities in their data integration requirements, it is these other differences which have led vendors to develop products with highly diverse architectures.

One of the more interesting consequences of the diversity of integration products and architectures is that oftentimes, the vendors seem unaware of the similarities between their products, especially if they are being marketed to different types of projects. The same can often been said of their customers. It is often the case, therefore, that each new integration project is approached as completely separate and unrelated to other existing or planned integration efforts within the organization. Often this can mean that the organization assembles different teams of people to staff the different projects. Staffing such projects often focuses on the team’s familiarity with the chosen technologies or the languages used to invoke the integration tool, instead of their ability to understand and think through how the data ought to be integrated for the highest-value. This in turn leads, as well, to each project inventing its own methods for documenting (or often not documenting) the data integration.

Very large organizations may, over time, find themselves implementing examples of each of the types of projects listed above. If they don’t take a broad perspective to each problem, they are likely to find themselves with investments in several, incompatible data integration solutions, with little or no way of reusing the knowledge of data equivalences that are embedded in each one.

With this system-architectural and market environment in mind, the Metamorphic Modeling Methodology has been defined. Metamorphic Modeling provides a language for describing and capturing the integration design details of all of an organization’s data integration efforts. It presents a standard, reusable way for an organization to produce high quality designs for data integration of any type and for any purpose. Using it, the organization will find the following capabilities open to it: a “design for integration” can be codified and standardized, and a body of reusable work products can be developed with applicability across the full spectrum of data integration projects, resulting in less redundancy of effort and more consistency of results across the organization; the ability to move the data integration skills from one platform to another – the portability of method across different problem types; a cadre of practitioners can be trained in the methodology, establishing a team which can produce reliable, consistent results repeatedly, for any data integration project the organization is faced with;high-quality, consistent integration designs are more easily managed, their implementation more readily measured, tested and verified; high-value business knowledge can be retained by the organization while projects are freed to locate the best quality and most cost-effective development team they can for the chosen architecture, even and especially when the organization decides to outsource the actual development effort (perhaps even offshore); and established, pre-existing data integrations can be reverse-engineered into Metamorphic Modeling conventions, perhaps even automatically, where they can then be used as specifications for re-implementation in a different technology or tool.

Advertisements

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: