Sean McGrath posted earlier
today a reply to
a message in the Service-Orientated-Architecture group that I think grasped a pretty
significant idea: Purpose-agnostic data representations, and their value in SOAs and
EAI (or just interoperability in general).
The key sentence was: "The real trick with EAI I
think, is to get purpose-agnostic data representations of business level concepts
like person, invoice, bill of lading etc., flowing around processing nodes. The
purpose-agnostic bit is the most important bit. OO is predicated on a crystal ball
- developers will have sufficient perfect foresight to expose everything you might
need via an API. History has shown that non of us have such crystal balls."
I happen to agree partly with his
ideas on OO also presented in the message, but that's another story :)
2 Comments
archived from WordPress — closedI do not believe in purpose-agnostic data as much as I don't believe in purpose-agnostic object models.
The problem is that concepts of person, invoice, etc. have different meanings to different people. The main reason is that different people with different roles have different views of the same object. People with different roles tend to use similar terms when talking about a certain object but tend to define these terms in different ways. This is bound to happen because they need different views of the same object to fulfill the tasks/responsibilities associated with their roles.
It is not realistic to expect everyone in an organisation to agree on common terms. So striving for purpose-agnostic messages is bound to fail.
Gerke,
I'm curious about what your definition of what a "purpose-agnostic object model" is. The common argument on objects goes for mixing behavior and data, and as soon as you include behavior, is hard to consider it "purpose-agnostic" in any way.
You do bring out what I consider an important point: Different people might interpret the data in different ways. But you know what? I think that as a fairly significant level of flexibility, rather than a problem per se. It does, however, hilight one important point: there's no ammount of pure mechanical description of the data that's going to help, so catering for the human element is still key. You still need (and will likely always need) to provide human level documentation and agreements on what the data is. Structure is only a part of the issue, and it's the easy one to deal with at a machine level. Expecting the machines to be able to also fully understand the semantics behind the data...well, I consider that a fairly unrealistic expectation... at least for now.