Scratch any large enterprise and you'll usually find some kind
of group focused on enterprise-wide conceptual modeling. Most
commonly this will be a data management group, occasionally they may
be involved in defining enterprise-wide services. They are
enterprise-wide because rather than focusing on the efforts of a
single application they concentrate on integrating multiple applications.

Most such groups tend to focus on creating a single comprehensive
enterprise model. The idea is that if all applications operate based
on this single model, then it will be much easier to integrate data
across the whole enterprise - thus avoiding stovepipe
applications. Much of this thinking follows the shared database
approach to enterprise integration - where integration occurs
through applications sharing a single logical enterprise-wide database.

A single conceptual model is a tricky beast to work with. For a
start it's very hard to do one well - I've run into few people who
can build these things. Even when you've built one, it's hard for
others to understand. Many times I've run into the complaint that
while a model is really good - hardly anyone understands it. This
is, I believe, an essential problem. Any large enterprise needs a
model that is either very large, or abstract, or both. And largeness
and abstractness both imply comprehension difficulties.

These days many integration groups question the shared database
approach, instead preferring a messaging based approach to
integration. I tend to agree with this view, on the basis that while
it's not the best approach in theory, it better recognizes the
practical problems of integration - especially the political problems.

One of the interesting consequences of a messaging based approach
to integration is that there is no longer a need for a single
conceptual model to underpin the integration effort. Talking with my
colleague Bill Hegerty I realized that

You can have several canonical models rather than just
one.

These models may overlap

Overlaps between models need not share the same structure,
although there should be a translation between the parts of models
that overlap

The models need not cover everything that can be represented,
they only need to cover everything that needs to be communicated
between applications.

These models can be built through harvesting, rather than
planned up-front. As multiple applications communicate pair-wise, you can
introduce a canonical model to replace n * n translation paths
with n paths translating to the canonical hub.

The result breaks down the modeling problem, and I believe
simplifies it both technically and politically.

So far, however, it seems that the data modeling community is
only beginning to catch on to this new world. This is sad because
data modelers have a tremendous amount to offer to people building
canonical messaging models. Not just are skills not taking part,
many also resist this approach because they assert that a single
enterprise-wide model is the only proper foundation for integration.

Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement