• Home
• News
• Resources
• Books
• Glossary
• Archives
• Blog
• About
• Contact

Fundamentals of integration metadata IV: An integration metamodel

June 17, 2005 @ erp4it from alphasong

(No Ratings Yet)

 Loading ...

Entire series:

Part 1: Delving into the concept of IT "system"

Part 2: Tracing the integration spiderweb

Part 3: Software deployment

Part 4: An integration metamodel

Finally, here is an overall logical metamodel for your EAI competency (click for larger). The principles underlying this metamodel have been proven in practice in a full-service Integration Competency Center (although let me be clear that there is a long distance from this logical representation, which draws heavily on open OMG standards, to an operational physical persistence architecture, with many different ways to realize it!):

Continued...

Major requirements for an ICC metamodel include:

• Support partial information about a complex integration environment, and stepwise refinement of its documentation.
• Map both process and data to information exchanges
• Easy transformation to a purely relational representation if required.
• Use of widely-accepted industry terms as primary structuring entities
• Support the OMG’s Common Warehouse Metamodel where possible

Most of the rationale for this metamodel can be derived from a close reading of the first three installments of this series.

In most large IT shops, integrations are informally documented as boxes and lines, with boxes being major applications and the lines being data feeds. Sometimes, this is all that is known of the integration space and therefore the metamodel must support this summary approach:

The concept of “interface system” is a recommended best practice, as system (among other things) is a unit of manageability, and this supports integration competency centers’ ownership of the integration space.

As well as supporting queries such as “show me all integrations handling data element X,” this metamodel also can subset integrations by mapping them to business processes.

Systems contain components.

Both are recursively decomposable. While in UML both are seen as types of components, distinguished by an IsInstantiable flag, the distinction between logical and physical seems significant enough in enterprise IT to merit two metaclasses; furthermore, the UML approach does not seem to prevent a physical, instantiable component from owning a logical component, which does not make sense.

This structure represents some of the more difficult concepts in metamodeling software architectures: what might be called the type/deployment/instance problem. One needs to distinguish between software package type (e.g. Apache), deployment (Apache on xyz server), and instance (Apache launched on xyz server at 08:00 2/3/2004 on port 8080 with settings a, b, and c.) This is needed not so much for app servers like Apache, but for heavily generic, parameter-driven applications that might connect to different databases and use different middleware all based on the instance parameters.

Note that Deployed Component can participate in any relationship that Component can, and RuntimeComponent in any relationship DeployedComponent or Component can. This flexibility will need to be backed with education as to best practices. It is an open question whether all should be modeled at the most granular level (RuntimeComponent) or whether this level of detail should be reserved only for the tough cases requiring it.

The Server class can be further elaborated into a logical/physical representation per the previous discussion.

Finally, the above set of structures represents the component, the physical data source, and the data definition. The classes deriving from DataDefinition may be seen as placeholders for the appropriate Common Warehouse Metamodel packages. Note the distinction between the data source and data definition; this is a key aspect of solving the problem. This structure allows the separate management of message queues, databases, and flat files, along with their correlation with appropriate data definitions and participation in interface systems. The structure also handles message queues and flat files that may be overloaded with differing schema. The metamodel problems become particularly complex in such cases, and could consume much further discussion.

Also note that this metamodel does not handle publish/subscribe architectures, and that message queues have several varieties (local, remote, error) that interact in specific ways. It also does not handle request/reply dependencies (e.g. Web services), and a reasonable alteration might be to also allow the logical Interface System metaclass to have direct data associations.

How to keep this up to date? Well, that's where Model Driven Configuration Management comes in...

All for now, I know this is a little dense. If you have a question, please post it to the Yahoo email list (link from the front page of www.erp4it.com).

Entire series:

Part 1: Delving into the concept of IT "system"

Part 2: Tracing the integration spiderweb

Part 3: Software deployment

Part 4: An integration metamodel

Charlie

Comments

Copyright © 2007 PMToolbox :: Tools and Resources for Project Management