Monday, May 22, 2006

Metadata repository integration conundrum

There is a lot of hype and buzz over metadata repository and management.
The main concern or rather an imperative requirement that is becoming commonplace is to come up with a strategy for implementing a centralized metadata repository solution that integrates the enterprise-wide business and technology metadata through a consistent and standard format.

For companies that are trying to develop such a metadata integration strategy and implementation, the most common solution is to partner with or buy a metadata repository solution that is capable of realizing the metadata integration dream.

But unfortunately enough, various efforts to logically or physically consolidate metadata descriptions into a single, shared and common view is met with the real-world issues of semantic inconsistencies and differences that exist both at the business as well as the technology level. These differences makes it hard if not practically impossible to find a common ground for metadata integration through a repository consolidation.

The Business semantic inconsistencies mainly arise from the lack of metadata management policies, procedures and standards that are implemented across the various Lines of Business (LOB's). This is further aggravated by a lack of ownership of the policies and standards by LOB owners and hence the reusability of metadata information is seriously thwarted.

The Technology semantic inconsistencies are easier to understand and comprehend. The varied array of technologies e.g. databases, datawarehouses, application servers, business process modeling techniques, business intelligence, etc which are further augmented by the ever-increasing number of vendors offering products and solutions, makes it a real tall order to standardize on an all-technology-encompassing standard for metadata integration.
Althogh efforts have been made by Standards bodies e.g. OMG to standardize on an information model for metadata exchange like XMI, it is almost an impossible chase towards attending technology standardization for metadata integration. Consider the commonplace occurrence of competitive vendors trying to provide differentiating solutions through proprietary extensions of the standards and specifications. This alone makes the dream of achieving a semantic consistency between metadata for technologies, impossible to realize.


Bobby said...

This whole SOA thing is just a bunch of hype. I've been working on computers for 30 years and this crap is just the same as a multiplexed hub and spoke. I mean get real this is just a scam by the big software vendors to sell services. It's not going to help any company become save money. Bah Humbug!!!

tsom said...

Bobby, thre is a fundamental paradigm shift. XML is the first technology that allowed allmost pure semantic description (the synatx of tree structure is universally understood and can be ignored) - that is why it took off so quickly. That is what led to WebServices / Services. Services are like sign boards that can be moved anywhere without inconveniencing the visitor. Think about giving directions to a Barnes and Noble book store - I can tell you that go to XYZ plaza and you wil see the sign board. Or I can tell you that go to XYZ plaza, the 3rd door on your left is Barnes and Noble. With the first method / signboard, you have immense flexibility in finding the store within the plaze (as long as you can underatnd th emeaning of written words and read english - two separate capabilities actually). With the 2nd option you will always need detailed insructtion to reach the door that leads to barnes and Noble (no sign board). If one does not understand the fundamental distinction between these two models, he / she will never understand why SOA is so important.

Nilanjan Dey said...

It's good to see that you have listed DVC as your favourite book. We have in recent times written a lot about DVC in The Hindu (the sister publication of Business Line,which employs me). Hope u can find the Hindu link and read what Indian writers (mainly) have written about DVC...Nilanjan

Joseph said...

It's good to see that you have listed DVC as your favourite book. We have in recent times written a lot about DVC in The Hindu (the sister publication of Business Line,which employs me). Hope u can find the Hindu link and read what Indian writers (mainly) have written about DVC...Nilanjan

Aravind said...

I agree with Bobby.Its all marketing bluff by big players to push their product. ESB would be SOA's granddad!

harry said...

Building loosely coupled systems is resultant of dynamic nature of business and changing patterns of markets. Contribution from governing bodies and IT Vendors has been towards providing appropriate frameworks, standards to businesses in adapting to this agile nature of systems. SOA is just one way of dealing with this problem. I still want to see more on how companies would address to aspects of effective integration of enterprise level legacy systems in Banking, Telecom domains during merging, takeovers. This need to be in a seamless, secured fashion without affecting the operations, retail services and end customers.

Anonymous said...

One issue against SOA is the reusability argument that SOA uses.
While for very large applications,
it does make sense (to reuse it), for smaller applications you are introducing additional dependency on the application being up continuously. It would be much better to go for code reuse in that case. This is a point I haven't seen too many vendors talk about.

Tilak said...

The point is not about small applications or large scale applications. The way we need to think about it is that, it is whether the application has business relevance and is going to help the business increase their ROI. SOA is as much as a business imperative as it is for IT. Such IT projects should be funded which has direct relevance to the realization of the business goals of the company. If we look at applications through that business lens, we can determine which applications should be SOA-enabled and which should not.