This chapter is from the book
This chapter is from the book
This chapter is from the book
Component Model
The architecture overview in the previous section is useful to provide enterprise architects, IT managers, and business users a conceptual perspective of key capability areas for a Social MDM architecture, however, it is not detailed enough to understand how the components in this architecture interact with each other. For this, a component model is necessary.
In the following sections, we explore the Social MDM RA on a functional component level using a component relationship diagram. A component relationship diagram provides a static view of the relationships between the components. We then walk through a sample component interaction diagram to demonstrate the dynamic interaction of the components. Component interaction diagrams will be used in subsequent chapters to describe various angles of the Social MDM RA from different architectural perspectives.
Component Relationship Diagram from an Enterprise SOA Perspective
You may have read [1], which provides an enterprise Master Data Management reference architecture aligned with an SOA-based enterprise architecture blueprint.2 Figure 4.6 shows an updated version of the component relationship diagram published in [1].
)
Figure 4.6 Social MDM component relationship diagram from an SOA perspective
The major differences are as follows:
Simplification: Since the previous component relationship diagram was published as part of the MDM RA, roughly six years have passed. Working with many clients during this time, we found that many components have become commoditized as SOA has matured. Following are some examples:
- The DMZ zone with a reverse proxy pattern, firewalls, and so on has been collapsed into a single network security component.
- Different types of LOB systems have been summarized into a single component.
- The subcomponents of the MDM component are not explicitly shown anymore. They are well understood and common knowledge in the MDM practitioner community at this point.
- Various messaging gateway components and the interconnectivity and interoperability component have been merged into a single ESB component.
- Changes in data domains: At the time the previous MDM RA was created, reference data was subsumed as part of master data. With the lessons learned since then, we see it now as a separate domain with domain-specific functionality to be appropriately managed, thereby justifying a component in its own right.
- New third-party data sources: Over the years, we have worked with enterprises that expressed some degree of dissatisfaction with commercial third-party vendors. Examples of issues include lack of completeness, cost, and and to some extent staleness of the data. Social media sources are perceived to address some of these aspects better but at the same time with the risk of some uncertainty and fuzziness. Also, additional processing is required to make these sources usable from an MDM standpoint. For these reasons we moved this into a different component.
- New use cases: The expansion of banking services to support mobile devices is one of several drivers for Mobile MDM—a capability that also requires new components, which we added to the component model.
- The impact of Big Data for analytics: As indicated with the data domain introduction, Big Data use cases broaden the scope of analytical capabilities, which we represent with a functional processing capability set with dedicated components.
Component Relationship Diagram for Social MDM from an Information Architecture Perspective
Although the SOA-centric component relationship diagram of the MDM RA remains a very useful reference architecture, for Social MDM, we felt the urgent need for a more information-centric view. Figure 4.7 shows the Social MDM RA component relationship model from an information-centric perspective. As you will notice, most of the important components from the MDM RA remain but some components have been removed or combined to allow us to focus on Social MDM. For example, network components have been removed and others have been combined such as portal, Web, and eCommerce.
)
Figure 4.7 Social MDM component relationship diagram from an information architecture perspective
On the left side of the figure, you can see the key operational data sources—traditional ones like CRM, HR, and marketing systems as well as new sources like social media platforms. The Master Data Hub and the Reference Data Hub are enterprise-wide (and in some cases, cross-enterprise) shared information assets. Through the information virtualization layer and the ESB, they are connected to all relevant IT systems to provide seamless access to these critical information assets. The information virtualization layer provides technical capabilities for information access, consolidation, replication, and so on. In industries such as banking, the digital transformation brings new banking services on mobile platforms like Android or iOS for smart phones. The ESB has been extended to include a mobile gateway that exposes services to mobile platforms. A mobile gateway provides the ability to map a Web service interface to a REST service interface to make the service consumable for Android devices. Additionally, the mobile gateway provides Mobile MDM capabilities independent of the target device environment—thereby supporting native Android, iOS, or even HTML5-based applications. Within the analytical sources zone, the landing area enables data harmonization prior to analytical use in other components such as the DW and data mart. A new component is the MapReduce engine, which we will explore in depth in Chapter 5. The information in the analytical sources is consumed as analytical data through technical capabilities such as reporting, prediction and forecasting, and enterprise planning.
For a Social MDM solution to work, additional common infrastructure components are necessary. The information governance, risk, and compliance component, for example, provides capabilities for data quality (for example, address standardization services) and a metadata catalog (for example, to manage business terms for master data entities alongside logical and physical data models of the Master Data Hub). The Internet and Intranet portal and web application component delivers functionality to surface master data such as employee or intranet employee dictionary applications or customer master data self-service functionality for being able to notify an organization about address or contact detail changes. The business process management component delivers business process functionality for authoring and stewardship processes of master data. Typical master data process examples include new product introduction, hierarchy maintenance, account creation, or duplicate suspect processing. Like other IT solutions, Social MDM depends on appropriate security and business continuity infrastructure. An MDM solution usually has very demanding requirements regarding availability (after all, master data is required by many of the mission-critical operational and analytical applications) as well as security (for example, enterprises need to protect their customer master data or face reputational damage as well as possible legal consequences).