Meta Data Repository Interface Processes

Every meta data repository must have two interfaces in order to function: a tool interface to accept meta data from other tools and an access interface to interact with business people and technicians. If the meta data repository is built in-house, the processes to provide both types of interfaces must be developed (Figure 14.2). If a meta data repository product is licensed, the access interface will be provided as part of the product, but a tool interface process must still be developed.

Figure 14.2. Meta Data Repository Interface Processes

The Tool Interface Process

Most of the business meta data and the technical meta data is not entered directly into the meta data repository but is extracted from the tools that capture it and use it to support their own functionality. In order to exchange this meta data, the meta data repository and the tools where the meta data originates need to communicate with each other using common meta data standards. Unfortunately, these tools do not interact with each other very well outside of rudimentary import and export capabilities, and common meta data standards have not yet been agreed upon and ratified by the meta data repository vendors . Therefore, it is necessary to develop a tool interface process with several interface programs to extract the meta data from the various tools.

Meta data repository vendors are recognizing the lack of tool integration as a problem, and meta data standards are being debated by two authoritative groups: the Meta Data Coalition (MDC, influenced by Microsoft) and the Object Management Group (OMG, influenced by Oracle). At this time it is unclear which meta data standards will be adopted as the industry standards.

The Access Interface Process

A meta data repository must also have a common access interface for the people who need to access it. Business people and technicians will want to retrieve information (meta data) about the business data in the BI target databases, the load statistics from the ETL processes, and other process- related meta data. Because business people and technicians may have different requirements, some access interface screens and programs may have to be designed slightly differently for these two constituencies. Technicians and "power users" may also get authorization to access the meta data repository directly without going through the access interface.

If you have only one centralized meta data repository, building a common access interface process for it seems like an obvious requirement and relatively easy to do. But if you are implementing a decentralized meta data repository solution, or even a distributed one, building a common access interface process to all meta data repositories or tools may not be such an obvious requirement. It is definitely a lot harder to build a common access interface process for a decentralized or distributed meta data repository ”with or without the help of Extensible Markup Language (XML). However, without that common access interface, everybody who wants to access meta data from multiple meta data repositories or tools would have to learn to use a different access interface for every meta data repository and tool. To avoid having to use multiple access interfaces, business people may well end up insisting on duplicating common meta data into their own "preferred" repositories. This can rapidly lead to redundant meta data repository silos , which is precisely what must be avoided.