Case in point:
An article published back in 2000 about the semantics of data and why it is important to understand the meaning of the data in order to do business to business integration. The author, David McGoveran, argues the point that of the 2 of the 3 main ingedients that are required for an integrated information exchange have been adequately solved:
1) Connectivity
2) Timley capture and purveyance of data
3) Understanding the data
I agree with this premise, as well as the conclusion he draws that all "public data elements pertaining to a set of integrated applications, whether stored in a relational database or not, as though they were attributes of a formally designed relational database."
I disagree with the method by which we need to get there. According to the author, "maintainable business semantics...is worth a little formal design effort involving application vendors and developers." Yes, formal design is necessary, but I say it is insufficient.
Why? Because the tools for formal design and the method for maintaining the semantics after the formal design and managing change to these formal designs are fundamentally missing. It is like having CASE tools that don't do round trip. Sure, it's valuable the first time, but the value degrades exponentially over time, and in fact, I would argue that the uncertainty that is caused by the lack of integrity of the documentation versus the acutal causes the documentation to be virtually worthless right off the bat.
If I don't have assurances that I have the right version of the documentation for the system that I'm using, I'll probably spend extra time verifying it...and thus I've lost a good amount of the value of having the documentation even if it is a small fraction of the documentation that is actually invalid. I use the term documentation to refer to any artifcats regarding the semantics of the information, its relationship to other information and the methods by which I can gain access to and/or manipulate the information.
I would also point out that much of the metadata about an actual data model is embedded in databases, contained in their system catalogs. And yet this information is not easily accessible to most humans, it's not easily exchanged, nor is it sufficient to specify the semantics of the information.
We need more, and it can't be solely dependent on the actions of the few, the proud, the "data architects." We are dealing with living systems that evolve over time. They can't rely on rigid constructs and upfront knowlege. They must be able to adapt, grow, expand, connect and self-correct over time.
I regard this as the challenge.
Kipp
nuBridges, LLC - www.nubridges.com
eBusiness is Business
cell: 404.213.9293
work: 770.730.372
No comments:
Post a Comment