Advanced Metadata Architecture

The vast majority of metadata repositories are unidirectional. Modeling tools that extract, transform, and load information into the repositories are responsible for capturing both business (business metadata) and IT (technical metadata) meta information flow in only a single direction. A bidrectional metadata architecture allows information contained within the repository to be altered, and this information is then subsequently fed to its original source. For example, if a user could connect to the repository and alter the name of a property in an enterprise data warehouse, this change could be propagated back into the supporting data-modeling tool to update the physical model for the data warehouse.

This allows for metadata to become effective in that it allows for different vendor tools to share metadata information. This functionality provides a lot of benefit for decision support systems. The major problem with making this a reality is the simple fact that many enterprises have built their decision support systems using best-of-breed software rather than using integrated tool sets provided by a single software vendor. This approach has some merit but prevents integration at the tool level. Some tools do allow for integration but require jumping through complex hoops just to share this type of information and may require writing code to exchange meta information. A metadata approach that takes this into consideration would allow for enterprises to make global changes in their metadata repositories and have those changes propagated through all the tools within the organization.

The Object Management Group (OMG) is working on a Common Warehouse Metamodel (CWM) standard. Additional information is available at www.omg.org.

Many enterprise tool vendors are trying to solve this particular problem, but several common organizational prerequisites must be considered before this can become reality. An organization would need to fully embrace the metadata repository approach for it to work and could not adopt it in bits and pieces. The repository will be required to store the latest version of the metadata source in which it will propagate changes. Concurrency issues will also arise in this situation. For example, if a user of the repository is updating information that needs to be propagated and another user is updating the schema at its source, collisions will occur. Finally, integration interfaces will have to be constructed to map and move metadata repository information back and forth to the metadata source.

For more information on industry standard approaches to metadata, visit the Metadata Coalition and the Open Information Model (OIM) standard. http://xml.coverpages.org/mdc-oim.html.

This type of approach can help solve many of the issues that enterprises are struggling with today. The most obvious business problem solved using this approach is with customer relationship management (CRM). The primary business driver for creating a customer relationship management system is the need for organizations to get single views of their customers. This statement is simple, but the work behind it is at best difficult as it requires integrating operational systems (orders, claims, customers, invoices, inventory, and so on) with business intelligence systems to provide a unified view. The ultimate goal is to enable customer-related information to be shared throughout the enterprise so as to provide higher levels of customer service (relations). Additionally, in industries such as banking, insurance, retail, and financial services, users want their systems to make certain business decisions for them without human interaction.

Using a Service-Oriented Architecture is also a viable approach to solving the customer relationship management data integration challenge. This is discussed in Chapter 3, Service-Oriented Architecture.

Applying Metadata to Business Problems

Canaxia would like to expand its operations into selling aftermarket parts and accessories to owners of its automobiles. The company has expressed a desire for consumers to visit its Web site (www.canaxia.com) and to search for accessories that are appropriate for the vehicles they own. When an accessory is selected, the program interface will communicate with the customer relationship management system, will check for additional related accessories, will determine if any product recalls pertain to the vehicle, will locate auto dealers that could install parts, and will calculate applicable charges. Additionally, if the customer has never communicated using any channel (phone, fax, email) with Canaxia, it could offer the customer an online discount. Once the customer has completed the order, an additional request could be sent to the customer care center scheduling a follow-up call in 2 weeks to ensure that the customer was successful in installing the purchased accessories.

You may be wondering why you would not simply maintain this information in the operational system that is responsible for processing orders rather than separating it into distinct systems and services. The answer lies in whether your organizational philosophy allows for best-of-breed or single sourcing and whether a single system can support all your business requirements in an adaptable manner. Best-of-breed solutions would encourage a service-oriented approach, but this does not solve the decision support aspects. We have noted that a clear separation between operational and decision data is essential. By leveraging a metadata approach, you can access the best of all worlds.

By closing the loop, we can take metadata from the repository and feed it back into the enterprise operational systems. The use of a bidirectional approach allows for implementation of such business rules as when discounts apply to be fed to all systems in one global change.