- Introduction
- Architecture Overview
- Component Model
- Component Interaction Diagram
- Subject-Oriented Integration
- Conclusion
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
Subject-Oriented Integration
With an understanding how the Social MDM Reference Architecture works, we want to now investigate how we can make master data available from a consumer standpoint. Provisioning the subset of information based on consumers’ social context requires the capability to perform subject-oriented integration for Social MDM solutions. Let’s look at some examples:
Ubiquitous Internet availability anywhere anytime on mobile devices allows people to interact with corporate IT in novel ways. The salesperson meeting a customer’s contact person wants to refresh his memory on that person’s current social context by doing a lookup from a mobile device in the car just a few minutes before entering a meeting at the client’s site. A member of the support organization looking at a product defect reported by someone from the customer’s site would like to know if that person is possibly already deeply frustrated. In this case, the support engineer would like to see if that person who opened the product defect report already posted negative statements online about the product or posted questions in forums related to the problem reported. Having that context available might affect the support engineer’s style of communication with the person who opened the product defect report and may reduce the time of analyzing the problem (there is no need to explore causes and possible solutions that have been identified as not helpful by the person opening the product defect report in forum discussions). These are just two examples illustrating how different consumers in different social contexts have different perspectives on the same 360-degree complete social master data based on their role.
Before we can integrate information, we need to understand it first, and this also applies to subject-oriented integration. Although information integrations have been built for a long time, in many cases this has been done in an ungoverned way. For example, an extract-transform-load (ETL) developer might have looked at source and target models and just built an ETL program based on a mapping of source to target attributes. The semantics of each field of the source and target data models, the relationship of these models to certain business entities and functions, and user roles consuming the data on the target are not captured in many cases. For a while, an inhibiting factor was the lack of appropriate metadata software to manage business, technical, and operational metadata and data lineage; and impact analysis functionality was not part of enterprise information integration platforms. This changed in the past several years with commercial metadata management solutions now available, fully supporting the creation of enterprise glossaries where technical (for example, logical and physical data models, mappings, and data profiling rules) and operational metadata can be attached to business metadata (for example, terms and policies). With this metadata functionality available through an enterprise glossary, it’s now possible to seamlessly define a subject composed of:
- A term describing the subject from a business perspective
- An assigned owner (for example, an information steward) who is responsible and accountable for the data asset described in the term
- Policies governing how the information asset related to the term has to be managed in terms of data quality, security, retention, privacy, and so on, and implementation rules linked to these policies used for enforcement
- Technical metadata linked to the term expressing how and where the data asset is stored, how it is related to other assets (for example, mappings), and permissible value ranges (for example, through linkage of applicable reference data tables)
- Operational metadata such as results of enforced security constraints, measured data quality, and so on
With the subject defined, it’s now possible to provide a catalog for information assets in the enterprise. Various users in the enterprise looking for information assets can now use this catalog of information assets. However, on a high level, we see two very distinct use cases. First, based on requests from the business, technical users can develop the integration to deliver the necessary subject considering all constraints attached to it for the consuming users from a consumption point of view. Second, business users can browse the catalog of information assets by subject, and if state-of-the-art self-service capabilities provided through the enterprise information integration platform are available and enabled, they can generate the integration for the subject of interest to the desired consumption point without having IT personnel involved.
More details on this topic of subject oriented integration can be found in [2].