Meta-data repositories have always been perceived as the magical solution to integrate tools and apps in a heterogeneous environment. Any exchange of information implies in some form or shape the exchange of data that describes the information structures and its meaning.

While the benefits of meta-data exchange and repositories are relatively easy to see their design and integration problems are numerous and hard to crack. Repositories suffer from a cold start problem since it makes only sense to integrate with one if it already contains data that can be shared.

When I joined Microsoft I took over responsibility for the Microsoft Repository and Visual SourceSafe (a version control system) and their development teams. The first release of Microsoft Repository with the Open Information Model (OIM) allowed external tool vendors such as Popkin’s System Architect or CA Erwin to integrate with Visual Basic.

OIM is a set of metadata specifications to facilitate sharing and reuse in the application development and data warehousing domains.

Successive versions of the repository engine and OIM shipped with Microsoft Visual Studio and Microsoft SQL Server and offered deeper integration with several of their components. Microsoft Repository’s COM (Component Object Model) based architecture has been engineered to offer versioning in COM – it basically persisted COM objects and created them on the fly.

The enthusiasm of small tool and application vendors to gain access to Microsoft’s server and tools metadata always outstripped the pace in which Microsoft internal partner teams shared such data. This seems to be a general rule for repositories and similar exchange technologies.

With the web and the pervasiveness of XML meta-data management became much more a model-mapping problem than that of access. You can find an interesting starting point to this problem in Phil Bernstein’s work, e.g. Panel: Is Generic Metadata Management Feasible?