Federation of master data management systems

Federating master data management systems may include a network-aware adapter configured with a host master data management node. The network-aware adapter may establish one or more links with other master data management systems to allow the system to work together and leverage each other's data.

FIELD

The present application relates generally to computers and applications, and more particularly to master data management systems and federating the master data management systems.

BACKGROUND

Master data refers to facts that describe the core of entities, for example, an organization's employees, customers, suppliers, partners, organizations, products, materials, accounts, medical records, locations, and others. Such master data are of high value information that an organization uses repeatedly across many business processes.Enterprise Master Data Managementby Allen Dreibelbis, Eberhard Hechler, Ivan Milman, Martin Oberhofer, Paul van Run and Dan Wolfson, IBM Press, 2008 provide background on master data management.

Managing master data faces challenges in that the data is usually scattered throughout the enterprise without consistent view of the master data. Fragmentation occurs as a result of the data being trapped inside enterprise resource planning (ERP), customer relationship management (CRM) and other commercially available off-the-shelf (COTS) packages. Factors such as mergers and acquisitions, experiments in new markets, decentralized businesses, and legal requirements across geographical boundaries also may contribute to fragmentation and inconsistency in master data.

Master data may be managed as objects and attributes, and by defining transactions over and access control to the objects and attributes. Data governance procedures may be also defined for functionalities such as conflict resolution, data import and data integration. An MDM system or server should ensure consistent master information across transactional and analytical systems, address key issues such as data quality and consistency proactively rather than “after the fact” in the data warehouse, decouple master information from individual applications, become a central, application independent resource, and simplify ongoing integration tasks and new app development. An MDM system can be implemented with different styles. For instance, in “consolidation” implementation style, data is periodically replicated to the MDM server. In “registry” implementation style, an MDM server knows where to find the data. In “transactional hub” implementation style, an MDM server becomes the system of record for master data. Applications should be appropriately architected to use this style of MDM implementation.

InfoSphere™ MDM is an MDM product from International Business Corporation (IBM), Armonk, N.Y. InfoSphere™ MDM product family includes Master Data Management Server with data model that include three domains (party, product, account), Master Information Hub that allows a user to make user's own domain and data models, and Master Data Manager for Product Information Management, which is a web-based collaborative authoring environment for a product domain in a data model. The party domain of the MDM Server manages the entirety of data related to parties such as customers, vendors, and suppliers, people and organization. The product domain of the MDM Server manages the definitions of products, category hierarchies, bundles, and equivalences. Its collection of products makes up a product catalog that is accessible throughout the enterprise. The account domain of the MDM Server manages business relationships and agreements with other parties, such as billing, claims and contracts. MDM functionalities include suspecting duplicate processing (also referred to as “data stewardship”) that prevents inadvertent creation of duplicate parties and products, for instance, using matching techniques; managing history of data modifications (also referred to as “point-in-time history”), which includes a full audit database that contains the full modification histories of all data objects and a set of query options for the audit database; keeping track of the source of all data and when it was added (also referred to as “source value”); maintain links to documents stored in a Content Management System (CMS) (also referred to as “document attachments”); and allowing administrators to define what elements and sub-elements users and user groups can see based on defined constraints (also referred to as “rules of visibility”).

To date, conventional use of master data management includes managing a single physical and logical MDM system for an entire enterprise, in which the scope of the applications and organizations of MDM is determined in the design stage. However, in many organizations, there may be requirements for multiple and multiple-level (hierarchical) MDM systems.

BRIEF SUMMARY

Federating master data management systems may be provided. A system for federating master data management systems, in one aspect, may include a network-aware adapter configured with a host master data management node, the network-aware adapter including at least. A network manager may be operable to maintain link information associated with the network-aware adapter and store master data management network information associated with the host master data management node. A transaction coordinator may be operable to coordinate distributed transaction between the host master data management node and one or more of second master data management systems. A transaction resource manager may be operable to interact with the host master data management node to commit or rollback a transaction. A reference change detector may be operable to detect a reference modification made in the host master data management node. A reference change sender may be operable to send a reference modification request to one or more of the second master data management systems. A reference change receiver may be operable to receive the reference modification request from one or more of the second master data management systems and populate the modification into the host master data management node. A master data request interceptor may be operable to intercept a master data read request made to the host master data management node. A master data request handler may be operable to forward the master data read request to one or more of the second master data management systems that are implemented in registry style, and receive in response returned master data from said one or more of the second master data management systems that are implemented in registry style node, and further forward the returned master data to a requestor.

A method of federating master data management systems, in one aspect, may include maintaining link information associated with a network-aware adapter and storing master data management network information associated with a host master data management node, and coordinating distributed transaction between the host master data management node and one or more of second master data management systems in a network of master data management systems. The may also include interacting with the host master data management node to commit or rollback a transaction, and detecting a reference modification made in the host master data management node. The method may further include sending a reference modification request to one or more of the second master data management systems, and receiving the reference modification request from one or more of the second master data management systems and populating the modification into the host master data management node. The method may yet further include intercepting a master data read request made to intercepting a master data read request made to the host master data management node, and forwarding the master data read request to one or more of the second master data management systems that are implemented in registry style, and receiving in response returned master data from said one or more of the second master data management systems that are implemented in registry style node, and further forwarding the returned master data to a requestor application.

DETAILED DESCRIPTION

The present disclosure in one aspect provides for federation of master data management (MDM) systems, for instance, in organizations where there may be requirements for multiple and multiple-level (hierarchical) physical MDM systems. In one aspect of the present disclosure, a single logical MDM view is provided for the multiple and multiple-level physical MDM systems. The MDM systems may be established in the bottom-up manner, and the MDM functionalities may be ensured in this federated MDM environment.

The systems and/or methodologies of the present disclosure allows for adding, modifying, and/or removing an MDM, as needed or desired, in a platform (or network) containing a plurality of MDM systems, and federate it with the existing MDM systems to maintain a single logical MDM view in the platform. An example platform is a government data platform, for instance, operating on a municipal service cloud. In one aspect, the systems and/or methodologies of the present disclosure allows for defining the scope of the applications and organizations represented by the new MDM in view of existing MDM systems in the platform; leveraging (using) the existing MDM systems, which may be implemented in a different architectural style, to design and implement the new MDM system more efficiently; federating different (e.g., existing and new) MDM systems to make them work together and consolidate and share master data among different level of organizations and applications; handling different types of MDM addition, e.g., MDM system and a group MDM systems. At the same time, the systems and/or methodologies of the present disclosure may ensure MDM functionality (e.g., data stewardship, point-in-time-history, source value, document attachments, rules of visibility) to be performed properly in the federated MDM environment.

In one aspect, a methodology of the present disclosure may establish one or more links between new coming MDM system with existing MDM systems to make them work together and leverage each other's data. The methodology of the present disclosure in another aspect may manage the topology of MDM network and coordinate the MDM systems (also referred to as nodes) and links between them. Yet in another aspect, the methodology of the present disclosure may control the data flow in MDM network, while keeping with the MDM functionality such as data stewardship (suspect duplicate processing), point-in-time history, source value tracking, document attachments, and rules of visibility.

FIG. 1illustrates an MDM network model in one embodiment of the present disclosure. The MDM network model represents an autonomous MDM system (also referred to as a node, or an MDM network node). An MDM network node102may be structured into different components: organization level104, architecture style106, and application list108. Other structural definitions are possible. The organization level104may specify the levels118(e.g., parent, self, child) and names of the levels120(e.g., state, county, town). The MDM network node102manages data objects110, which may be implemented with three possible MDM “architecture styles” as shown at112. The MDM network node102also manages applications that access the data objects110, for instance, via an application list108. The application list108may include the names of the applications114and one or more objects those applications write to as shown at116.

A link may be established between two autonomous MDM systems, for instance, between a server or application of one MDM system to another MDM system's server or application. A link is established, for example, by allowing an MDM to access another MDM's data. The model shown inFIG. 1may be used to identify the architecture of a new MDM node and links that should be established between the new node and one or more existing nodes in order to leverage them. The model may be also used to define the scope of the applications and organizations involved in the new MDM.

FIG. 2shows different link types of a link in one embodiment of the present disclosure that may connect the autonomous MDM systems. As described above, data objects may be architected or implemented in different architectural style. Depending on the architectural style, different links may be established. For instance, if a data object of a node206is implemented as “registry” style, that node206accesses data by a reference link202from another node (which may be implemented in any of the shown styles, e.g., registry, transaction or co-existence)208. Accessing data by reference refers to accessing it by address rather then by value. As another example, if a data object of a node210is implemented as “transactional hub” style (also shortened and referred to as “transaction” style), another node may access data from that node210by operation link204from another node (which may be implemented in transaction or co-existence style)212. In operational link, the original transaction node210handles the distributed transaction committed to it.

In a traditional MDM system, a transaction style MDM system has all the data objects stored locally with an MDM server of the system, and when an application submits a read or write request to the MDM system, the MDM server manages the transaction. In a usage scenario (MDM network) of the present disclosure in one embodiment, a transaction style MDM system (210) does not own all the data locally, e.g., some data may be distributed among other MDM systems (212). Thus, when an application submits a read or write request to the MDM system210and if servicing this request includes accessing data from other MDM systems (210and/or212) in the network, the MDM system210(which initially received the request) performs a distributed query to the other MDM systems and manages the distributed transaction. In one embodiment of the present disclosure, an operational link204is established or exists between MDM nodes if the source MDM node of the link is implemented as a transaction style MDM system210and manages the distributed transaction between the source node210and the target node of the link212.

In one embodiment of the present disclosure, an MDM system or node may be implemented in different architectural styles. For example, if an MDM system manages different data object types, the system could be implemented in different architectural styles according to the different data types. MDM systems are implemented to improve the quality of master data and to provide consistent, managed use of this information in what is often a complex and somewhat tangled environment. There are a variety of ways to support these requirements, for instance, to accommodate a range of methods of use and implementation requirements. Implementation requirements may dictate if the MDM system is to be used as a system of record or system of references; if the system is to support operational environment, decision support environments, or both; if it is important for the MDM system to push clean data back into existing systems; and if geographic distribution is required. Different combinations of implementation and usage requirements may dictate different MDM implementation styles. Thus, hybrid implementations that combine multiple implementation style are possible.

Briefly, in “consolidation” implementation style of an MDM system, an individual application linked to the MDM system stores its own data, for instance, in its own database. The data is periodically replicated to the MDM server from each application's data. Thus, in this style, MDM server uses its own local copy of the data for operations.

The consolidation implementation style focuses on bringing together data from multiple sources for purposes of a central reference or reporting analysis. This can be compared to a typical data warehouse. The data collected is not used to update other systems. The system of record of the data belongs to the individual source systems. The consolidation implementation style brings together master data from a variety of existing systems, both database and application systems, into a single managed MDM hub. Along the way, the data is transformed, cleansed, matched, and integrated in order to provide a complete “golden” record for one or more master data domains. This golden record serves as a trusted source to downstream systems for reporting and analytics, or as a system of reference to other operational applications. Changes to the data primarily come in from the systems that feed it; this is a read-only system. The basic consolidation style has reads and writes going directly against the existing systems and the MDM system receiving updates from these existing systems. The integrated and cleansed information is then distributed to downstream systems (such as data warehouses) that use, but do not update, the master data.

In “registry” implementation style of an MDM system, an individual application linked to the MDM system stores its own data, for instance, in its own database. The MDM system accesses the data in the individual application's database, by reference, and does not operate on a local copy. For example, the MDM system may store references to the data physically stored in the individual application's database. Virtual consolidated view is assembled dynamically and is often read-only. Authoring remains distributed.

The registry style creates a skeleton record with minimum amount of data required to identify the master record and to facilitate the linking of accounts across multiple source systems. The data collected is not used to update other systems. The system of record of the data belongs to the individual source systems. The registry implementation style can be useful for providing a read-only source of master data as a reference to downstream systems with a minimum of data redundancy. The outside systems are existing sources of master data. The MDM system holds the minimum amount of information required to uniquely identify a master data record; it also provides cross-references to detailed information that is managed within other systems and databases. The registry style implementation is able to clean and match this identifying information and assumes that the source systems are able to adequately manage the quality of their own data. A registry style of MDM implementation serves as a read-only system of reference to other applications. Queries against the registry style MDM system dynamically assemble the required information in two steps. First, the identifying information is looked up within the MDM system. Then, using that identity and the cross-reference information, relevant pieces of information are retrieved from other source systems.

In “coexistence” implementation style of an MDM system, the MDM system physically stores consolidated view of master data.

The coexistence style implements all the features of the registry style, and also provides data elements that the client wants to track at the party level. Master data can be updated in source systems or in MDM Server, in which case the data is fed back to source systems. IBM® InfoSphere™ Rapid Deployment Package (RDP) for Master Data Management (MDM) facilitates the process of feeding an MDM server with master data from source systems in batch fashion. The coexistence style may be considered as being one step closer than the Registry style to becoming the system of record, but the existing source systems still remain as the system of record.

The coexistence style of MDM implementation involves master data that may be authored and stored in numerous locations and that includes a physically instantiated golden record in the MDM system that is synchronized with source systems. The golden record may be constructed in the same manner as the consolidation style, e.g., through batch imports, and can be both queried and updated within the MDM system. Updates to the master data can be fed back to source systems as well as published to downstream systems. In a coexistence style, the MDM system can interact with other applications or users.

An MDM system implemented in the coexistence style is not a system of record, because it is not the single place where master data is authored and updated. It is a participant in a loosely distributed environment that can serve as an authoritative source of master data to other applications and systems. Because the master data is physically instantiated within the MDM system, the quality of the data can be managed as the data is imported into the MDM system.

The transaction hub style implements centralized management of master data. All data updates happen directly in the MDM system and can be distributed to other applications and MDM systems in MDM network, which implement read-only access. The MDM repository becomes the system of record for master data. The transactional hub implementation style provides a centralized, complete set of master data for one or more domains. It is a system of record, serving as the single version of the master data it manages. A transactional hub is part of the operational fabric of an information technology (IT) environment, receiving and responding to requests in a timely manner. This style often evolves from the consolidation and coexistence implementations. The fundamental difference is the change from a system of reference to a system of record. As a system of record, updates to master data happen directly to this system using the services provided by the hub that is the MDM system. As update transactions take place, the master data is cleansed, matched, and augmented in order to maintain the quality of the master data. After updates are accepted, the system distributes these changes to interested applications and users. Changes can be distributed as they happen via messaging, or the changes can be aggregated and distributed as a batch.

FIG. 3is an architectural diagram showing a plurality of MDM systems and links according to one embodiment of the present disclosure. In the example shown, there are three organizations that are hierarchically related. For instance, the organizations may be government organizations. A county-level organization may have its own MDM system302. Applications running on this county-level organization's computer systems (or information technology (IT) systems) may access or use the services of the MDM system302. At a lower level of the organization hierarchy, there may be town-level organizations, each with its own MDM system304and306. Applications running on the respective town-level organization's computer systems (or information technology (IT) systems) may access or use the services of the respective MDM systems304and306. In one embodiment of the present disclosure, an application of the county-level organization may want to access the data maintained by an MDM system304of a town, e.g., a data object describing a parcel, which the MDM system304has implemented in registry style. The application for the county-level organization may access this data via its MDM system302by a reference link308. Similarly, the application of the county-level organization may want to access the data maintained by an MDM system306of another town, e.g., a data object describing a citizen, which the MDM system306has implemented in transaction style. The application for the county-level organization may access this data via its MDM system302by an operational link310.

FIG. 4is a diagram illustrating an MDM network-aware adapter of the present disclosure in one embodiment. In one embodiment of the present disclosure, an MDM network-aware adapter402resides with each MDM node or system. The MDM network-aware adapters talk to one another to establish one or more links between them and to synchronize the MDMs. Within an MDM node, the adapter402acts as an application, for example, for data objects implemented in registry style. The adapter402may also act as MDM storage, for example, for data objects implemented in co-existence or transaction style. To another adapter, the adapter402may act as an MDM server. The adapter402in one embodiment may include functionalities such as a MDM network manager404, reference synchronization manager406, master data request proxy408, transaction manager410and transportation layer412.

The MDM network manager404may maintain link information associated with the adapter402and store the MDM network information of the master data. Link information associated with the adapter402may include the topology information of the MDM network within which the adapter402functions, for example: which node the adapter402resides with; which adapters are linked with this adapter402and which nodes these adapters reside with, and the type of the links. The MDM network information of the master data may include the data distribution information and the architecture style information, for example: the architecture style of each node; and the data object instance list managed by each node.

The reference synchronization manager406may include a reference change detector functionality414that may detect the reference modification made in the host MDM node. The host MDM node refers to the MDM within which the adapter402resides or with which the adapter402is associated. The reference synchronization manager406may also include a reference change sender functionality416that may send the reference modification request to one or more other adapters associated with one or more of other MDM nodes. The reference synchronization manager406may further include a reference change receiver functionality418that may receive the reference modification request from one or more other adapters associated with one or more of other MDM nodes, and further populate the modification into the host MDM node. In this way, the reference synchronization manager406keeps track of what is modified in the host MDM and requests the same modification be made in other MDMs, and further receives information about the modifications made in other MDMs and makes the same modifications in the host MDM node.

The master data request proxy408in one embodiment may include master data request interceptor functionality420that may intercept the master data read request to the transaction and coexistence style MDM nodes. The master data request proxy408in one embodiment also may include a master data request handler functionality422that may forward the master data read request to other one or more registry MDM nodes, receive the returned master data from the node and forward it to the requester.

The transaction manager410in one embodiment may include a transaction coordinator that may coordinate the distributed transaction among the nodes using two-phase commit (2PC) protocol, a type of atomic commitment protocol. The transaction manager410in one embodiment further may include a transaction resource manager functionality426that may interact with the host MDM node to commit or rollback the transaction.

The transportation layer412in one embodiment performs the transferring of the data between the MDM nodes. The transportation layer is in charge of transferring the data and the control information. For example, a hypertext t transfer protocol (http) layer or a WebSphere™ massage queue layer.

In one embodiment of the present disclosure, the MDM network-aware adapter402is configured to handle communications with different types of links, for instance, to support the communicating between and among MDM nodes that are implemented in different styles, for instance, registry style, co-existence style and transaction style, for example, by establishing the appropriate links.

FIG. 5illustrates an example of a network of MDM nodes (502,504,506) with corresponding MDM network-aware adapters (508,510,512, respectively) in one embodiment of the present disclosure. Each MDM node may have one or more applications linking to it to access and handle the master data for that node. For instance, “APP5”512may link to “MDM Server1”502for accessing (e.g., read and/or write) the master data on that node; “App1”514and “App2”516may link to “MDM Server2”504for accessing data (e.g., read and/or write) the master data on that node; “App3”518and “App4”520may link to “MDM Server3”506for accessing data (e.g., read and/or write) the master data on that node. An MDM network-aware adapter (e.g.,508) acts as an ordinary application to an MDM server (e.g.,502), which linked to it with the desired architecture style. An MDM network-aware adapter may also acts as an application to the MDM server, which logically may represent all the applications which are not directly linked with the node. For example, “MDM network-aware adapter1”508may act as an application to “MDM Server1”502that represents “App1”514, “App2”516, “App3”518or “App4”520, or any combinations thereof. As a result, in one aspect, a new MDM node being added into a network of the MDM nodes, appear as if another application is added to an MDM node.

FIG. 6is a diagram illustrating an MDM network-aware adapter handling a reference change notification on a reference link. In this example, MDMs are connected by a reference link. For instance, the network-aware adapter604of “MDM node1”602is connected by a reference link606with the network-aware adapter608of “MDM node2”610. An application612connected to “MDM node2”610accesses (reads and/or writes) to a storage or database614. At616, an application linked to “MDM node2”610adds a new master data entry to “MDM node2”, for example to its database614. As a result, at618, a new reference is added into “MDM node2”610. A reference change detector functionality620of the adapter at “MDM node2”610detects a reference change in the node at622. At624, the reference change detector functionality620calls a reference change sender functionality626to send the change. The reference change sender functionality626, in turn, at628calls an MDM network manager630of the MDM network-aware adapter608of the node610to filter the reference change by node. In one embodiment, the MDM network manager630may filter the reference change by node, by performing a search in its storage for the topology information and data distribution information, and deciding to which node it should send the new master data information. For example, the information may be sent to only those nodes that use or access the data. For instance, if the data distribution information shows that this data type is not managed by MDM node1602, this data change is not sent to node1. On the other hand, the MDM node1602may be determined to be one of the nodes managing this data, in which case the new master data and/or reference information about the new master data is sent to that MDM node1602.

At632, the MDM network manager630returns one or more nodes that need to receive the change, for instance, by looking up a database of links of nodes and data objects to determine which nodes also use or need to be synchronized with this changed reference. In this scenario, the MDM network manager630may return “MDM node1”602.

At634, the reference change sender626calls a reference change receiver636of the MDM network-aware adapter604at “MDM node1”602, the node returned by the MDM network manager630, with the reference change. At638, the reference change receiver636of the MDM network-aware adapter at “MDM node1”602populates (e.g., processes and stores) the reference change at “MDM node1”602in MDM node1. For example, MDM server602establishes a reference to the entry added in node2610. Note that this is not a normal reference, it is a “reference of reference” because of the entry added in node2(610) itself is also a reference.

At640, “MDM node1”602notifies its reference change receiver636of the update. In turn, at642, the reference change receiver636notifies the reference change sender626of the MDM network-aware adapter at “MDM node2”610of the status of the update.

FIG. 7illustrates a process of handling a read request forwarded on reference link by an MDM network-aware adapter in one embodiment of the present disclosure. In this example, an application (e.g., APP1)702linked to an MDM node (e.g., MDM node1)704requests a read on a data object. Unlike the processing in the traditional transaction style node, in which the read request only invokes a query to the local storage for result, the methodology of the present disclosure as shown inFIG. 7intercepts the request and distributes the request among the linked nodes.

At716, an application702sends a master data read request to its MDM node. At718, master data request interceptor functionality720of the adapter706associated with the MDM node704intercepts the master data request. At722, the master data request interceptor functionality720of the adapter706associated with the MDM node704calls a master data request handler724of the adapter706associated with the MDM node704to forward the request to a linked MDM node. At726, the master data request handler724of the adapter706associated with the MDM node704calls an MDM network manager728of the adapter706associated with the MDM node704to determine the linked MDM node information. At730, the MDM network manager728returns the linked MDM node information. This information may be retrieved by looking up a database of linked nodes. At732, the master data request handler724calls the linked MDM node returned by the MDM network manager728, for example, MDM node2at710, to get the master data. The called node710then returns the master data at734to the master data request handler724. The master data request handler724returns the master data to the application702at736.

FIG. 8illustrates a process of writing or reading a data request based on the operational link in an MDM network-aware adapter in one embodiment of the present disclosure. In this example, all three MDM nodes802,804,806are implemented in transaction style, and two operational links808,810are established between node1, node2and node3to form a MDM network. An application (e.g., APP)812linked to an MDM node (e.g., MDM node1)802requests a modification on a data object. For example, at814, the application812sends master data modification request to its MDM node802. At820, a transaction coordinator functionality816of the adapter818associated with the MDM node1(802) calls a MDM network manager functionality822to get the adapter list which is involved in the transaction. The MDM network manager822searches in its storage for the topology information and data distribution information, and retrieves the adapter list involved in the transaction. At824, the MDM network manager822returns the adapter list to the transaction coordinator816. The rest of the steps in this example may involve a two phase commit process. For instance, at826, the transaction coordinator816of MDM node1(802) sends a message including the modification request to the transaction resource manager828of MDM node2(804) to confirm if the node2(804) is ready for committing a modification transaction; at830, the transaction coordinator816of MDM node1(802) also sends a message to the transaction resource manager832of MDM node3(806) to confirm the readiness to commit a modification transaction. At834, the resource manager828of MDM node2(804) returns an agreement or abort status to the transaction coordinator816of MDM node1(802). At836, the resource manager832of MDM node3(806) also returns an agreement or abort status to the transaction coordinator816of MDM node1(802). If the returned status of node2and node3are both agreements, the transaction coordinator816of MDM node1(802) will send corresponding commit message to the resource managers828,832of MDM node2and3at838and840, and resource managers828,832of MDM node2and3commit the transaction locally at842and844. If the returned status of node2and node3are not both agreements, the transaction coordinator816of MDM node1sends corresponding rollback message to the resource managers828,832of MDM node2and3at838and840, and resource managers828,832of MDM node2and3perform rollback the operations locally at838and840, respectively. Then, at842, the transaction coordinator816of MDM node1returns a message indicating success or failure of the master data modify request to the application812that requested the modification.

In one embodiment of the present disclosure, an MDM network-aware adapter also enables for adding, modifying and removing an MDM.FIG. 9illustrates a method of adding a new node to an existing network of MDM nodes. At902, MDM requirement is obtained. The MDM requirement may include information about the MDM system and the data objects it manages, for instance, as specified by an entity (or customer) owning and using the data collected during the traditional MDM implement. Examples of such requirements may include what data types should be managed by the MDM system, what is the preferred architecture style of the MDM system, and other information.

At904, the organization scope is identified. This step identifies what is the organization scope in which the new MDM system will be used, for example, under a multi-level organization. For example, when a new MDM system is introduced to the network of MDM system, for example, in a municipal context, it may be decided what government organizations will directly use this MDM system, for instance, a town's government, or a county's government and all the towns' governments which belongs to the county, or a city's government, or other government organizations, or any combinations thereof.

At906, the existing MDM network (network of MDM nodes) related with the organization scope is identified. For instance, when adding a new MDM system for a specific organization scope, this step finds the MDM network to which the new MDM system should be added. Because of the organization structure most likely reflects the relationship of different MDM systems, the method of the present disclosure may find the existing MDM system or MDM network in the upper level or lower level organization of the identified organization scope.

At908, it is determined whether there is any new master data type which is not included in the existing MDM network or nodes. At902, the master data types that will be managed in the new MDM system were determined. In addition, the list of the master data types already managed by the existing one or more MDM nodes may be determined from the configuration information of the one or more MDM nodes. The master data types to be managed by the new MDM system and those that are already managed by the existing one or more MDM systems may be compared to determine if there are new data types in the new MDM system, which are not managed by the existing MDM systems. For example, the new MDM system may manage “Product, Citizen, Parcel”, and there are two existing MDM nodes which are managing “Product” and “Party, Parcel” respectively. In this example, the new data type “Citizen” is identified or discovered.

Because the architecture style of the new data types, will not affect other existing MDM nodes since the existing MDM nodes have not used the data, the design of the architecture style for the new data types need not consider the existing MDM network as shown at910.

For existing data types at912, because the architecture style will affect and be constrained by the other existing MDM nodes, the design of the architecture style in one embodiment of the present disclosure depends on the requirement of the new node as well as the consideration as to whether the one or more of the new data types' architecture style would be feasible in light of the other existing nodes. If it not feasible, the architecture style of one or more new data types may be changed to a feasible one. At910, if there are no new master data types, the architecture style for the new node to be added is decided using the MDM requirement obtained at902. At912, if there is one or more new master data types, a new MDM system for new data type is designed without considering the existing MDM network.

At914, it is determined whether the architecture style for new data types in the new MDM system is feasible for leveraging the existing MDM network. For example, a map or chart of which architecture style is compatible or feasible may be stored in memory and accessed to determine the feasibility. The following is an example of such map which shows that new nodes that are implemented in transaction or coexistence style are not compatible with existing nodes that are implemented in registry style.

Architecture style of an existing MDM nodeRegistryCoexistenceRegistryArchitectureTransactionInfeasibleFeasibleFeasiblestyle ofCoexistenceInfeasibleFeasibleFeasiblenewly addedRegistryFeasibleFeasibleFeasibleMDM node

At916, if it is determined that the architecture is not feasible for leveraging the existing MDM network, a new MDM system is designed for existing data type without considering the existing MDM network. In this case, the new MDM node cannot be added into the existing the MDM network, for instance, if the designer insists on the architecture style which is infeasible (or incompatible) for use with the existing MDM network. The new MDM node may be designed alone without considering the existing MDM network.

At918, if it is determined that the architecture is feasible for leveraging the existing MDM network, the link type is decided for use between the new node and the existing nodes. Link type may be determined based on the architecture style of the new node. For example if a feasible register style has been decided for the new node, and the new node should hold a logical holistic view for the master data within the organization without having to modifying the existing nodes. By establishing proper links between a new node and existing nodes, the user of the new node is enabled to see a holistic view for the master data of his organization even though some of the real data physically reside in the existing nodes.

Table 1 explains what links should be established when a new node that is implemented in registry style is added to a network of MDMs. For example, if the architecture style of an existing node with which the new node should link is Registry, and if the user or application who will use the new node may modify the data (not read only), then the link between the new node and the existing node should be Bi-direction Reference link (one reference link from the new node to the existing node, and another reference link from the existing node to the new node). If the architecture style of the existing node with which the new node should link is Registry, and if the user or application that will use the new node can access the data as read only, then the link should be one reference link from the new node to the existing node. Other cells in this table provide similar explanation. The “Coexistence” and “Transaction” column in Table 1 may be interpreted similarly.

FIG. 10Aillustrates what links should be established if a new node's architecture style is registry style.FIG. 10Ashows an example MDM network with two existing MDM nodes. MDM node of Town A1002manages two data types for town A, Citizen and Parcel. These two data types are managed in a registry style. MDM node of Town B1004manages two data types for town B, Citizen and Parcel. These two data types are managed in a transaction style. One new incoming MDM node, for example, MDM node for County1004is designed to be registry style by customer specified (or other designer specified) requirement. In this example, two applications1008,1010will directly use this MDM node1006. App1(1008) has its local data storage1012and will read and/or write data from the local storage1012, app2(1010) has no local data and will only read data from this MDM node1006. Because the new MDM node1006is used in the county level, this node1006may be configured to supply a logical holistic view for the master data within the county. That is, from this MDM node1006, an application should be able to read Parcel and Citizen information, which belongs to the county including those in towns A and B. To accomplish this, in one embodiment of the present disclosure, the methodologies of the present disclosure may leverage the existing MDM nodes of town A and town B1002,1004, without modifying them, for instance, by establishing links between the new node and existing nodes based on the table 1. Referring to Table 1, since the new node will be registry style and the app1(1008) using this node1006will modify the master data, registry links may be established from the new node1006to the existing nodes1002,1004, and also the reverse links from existing nodes1002,1004, to the new node1006.

FIG. 10Billustrates an example of leveraging Table 2 to determine what links should be established if a new node's architecture style is transaction style.FIG. 10Bshows an example MDM network with two existing MDM nodes. MDM node for Town A1020manages two data types for town A, Citizen and Parcel. These two data types are managed in a coexistence style. MDM node for Town B1022manages two data types for town B, Citizen and Parcel. These two data types are managed in a transaction style. Two new MDM nodes, MDM_County and MDM_County_Registry nodes are added to the network. MDM_County node1024is designed to be transaction style by its implementation requirement, for instance, following a customer or other design specification. As transaction style, this node1024has local storage1028on the MDM node1024. Two applications1030,1032will directly use this MDM node1024, and will write data on this MDM node1024. A write request from app1(1030) or app2(1032) can include writing data which are managed by MDM node of Town A1020or MDM node of Town B1022. The methodology of the present disclosure leverages the existing MDM nodes1020,1022to support this functionality without modifying those nodes1020,1022, for instance, by establishing links between the new node1024and existing nodes1020,1022based on Table 2.

Referring to Table 2, since the existing nodes1020,1022, are coexistence and transaction style respectively, operational links may be established from the new node1024to MDM node of Town A1020and MDM node of Town B1022.

FIG. 10Bshows another new node1026added to the MDM network. For instance, if it is desired to supply a read only logical view for the master data within the county so that an application can read data managed by lower-level organizations (e.g., town A and town B), a new node may be created and added. MDM_County_Registry node1026, for example, may be created at a county level node and added to the network. This node1026may be implemented in registry style and have a reference link from this node1026to other three MDM nodes1020,1022,1024.

The second row of Table 2 specifies a link type when a new transaction MDM node is added in to a MDM network based on existing node's architecture style. The third row of Table 2 specifies a link type when an extra registry style MDM node (e.g.,1026inFIG. 10B) is added which is accompanied with the above new transaction MDM node (e.g.,1024inFIG. 10B).

TABLE 2Architecture styleof existing nodeCoexistenceTransactionLink between a newOperational link fromOperational linknode and annew node to existingfrom new nodeexisting nodenodeto existing nodeLink between a registryReference link from aReference linkstyle MDM nodenew node to anfrom a new node toand other nodesexisting nodean existing node

FIG. 10Cillustrates determining and establishing links for a new node implemented in coexistence style of architecture. Establishing links for a new node implemented in coexistence style is similar to establishing links for a new node implemented in transaction style shown inFIG. 10Band Table 2. The difference is in the ability to directly link an application to an extra registry style node. For instance, when establishing a reference link from the new extra registry style node to the new coexistence style node, the link could actually points to the application associated with the coexistence node. This is because in the coexistence style, the data residing with the application is the system of record, and when the extra registry style node is added accompanied with the new coexistence style node, the new coexistence style node can be bypassed to directly link to the application, e.g., without needing to use the coexistence node as the intermediary.

FIG. 10Cshows an example MDM network with two existing MDM nodes1040,1042. MDM node for Town A1040manages two data types for town A, Citizen and Parcel. These two data types are managed in a coexistence style. MDM node for Town B1042manages two data types for town B, Citizen and Parcel. These two data types are managed in a transaction style. Two new MDM nodes, MDM_County and MDM_County_Registry nodes are added to the network. MDM_County node1044is designed to be coexistence style by its implementation requirement, for instance, following a customer or other design specification. As coexistence style, this node1044has local storage1052on the MDM node1044that stores synchronized data. Two applications1048,1050will directly use this MDM node1044. A synchronization request from app1(1040) or a read request for app2(1032) can include synchronizing or reading the data which are managed by MDM node of Town A1040or MDM node of Town B1042. The methodology of the present disclosure leverages the existing MDM nodes1040,1042to support this functionality without modifying those nodes1040,1042, for instance, by establishing links between the new node1044and existing nodes1040,1042based on Table 3.

TABLE 3Architecture styleof existing nodeCoexistenceTransactionLink between a newOperational link fromOperational linknode and ana new node to anfrom a new nodeexisting nodeexisting nodeto an existingnodeLink between a registryReference link from aReference linkstyle MDM node andnew node to anfrom a newother nodesexisting nodenode to anIn this case, aexisting nodereference linkactually points to theapplication linkedwith the coexistencenode

Referring to Table 3, since the existing nodes1040,1042, are coexistence and transaction styles respectively, operational links may be established from the new node1024to MDM node of Town A1040and MDM node of Town B1042.

FIG. 10Cshows another new node1046added to the MDM network. For instance, if it is desired to supply a read only logical view for the master data within the county so that an application can read data managed by lower-level organizations (e.g., town A and town B), a new node may be created and added. MDM_County_Registry node1046, for example, may be created at a county level node and added to the network. This node1046may be implemented in registry style and have a reference link from this node1046to the child level MDM nodes1040,1042.

The second row of Table 3 specifies a link type when a new coexistence style MDM node is added in to a MDM network based on existing node's architecture style. The third row of Table 3 specifies a link type when an extra registry style MDM node (e.g.,1046inFIG. 10C) is added which is accompanied with the above new coexistence MDM node (e.g.,1044inFIG. 10C).

MDM nodes linked according to one embodiment of the present disclosure can differentiate which master data to be transmitted through a specific link. When a “reference of reference” is established through reference link, a low level reference change may be notified to the high level reference. A read request may be forwarded to a transaction and coexistence style node to a registry node. MDM nodes can also handle distributed transaction when using an operational link.

Referring back toFIG. 9, at920, it is determined whether the new node belongs to a higher level organization, for example, higher in the hierarchy than the existing MDM nodes in the network. For instance, organizations may be structured into a hierarchy of organizations or entities. A county government is considered a higher level compared to a town government, for instance, since the county includes the towns. For example, if a town's government which belongs to a county is using MDM systems, and now the county's government is developing a MDM system, then the new MDM node belongs to a higher level organization, i.e., county government.

At922, if the new node belongs to a higher level organization, a group MDM node is setup for the higher level organization. Group MDM node is described in co-owned patent applications entitled “Federation of Multi-level Master Data Management Systems” Ser. No. 13/117,370 and “Data Stewardship in Federated Multi-level Master Data Management Systems” Ser. No. 13/117,411, which applications are incorporated herein by reference in their entirety.

At924, the new MDM node is setup, which may include data model development, data cleaning, application side coding, software installation, testing, and others. At926, an MDM adapter is setup for the new node, for instance, depending on the link type.

Setting up the MDM adapter may include preparing the MDM network information, installing the adapter, configuring the adapter based on the MDM network information, and the link types.

FIG. 11is a diagram illustrating a process of removing a link between different MDM nodes with a reference or operational link from a disconnecting node. If a node that is being removed has reference link, the following steps may be employed. A MDM Network-Aware Adapter2(1104) determines the existing connections between the disconnecting node (i.e., one that is being removed)1102and all other nodes1106,1110. The MDM network-aware adapter1104of the disconnecting node1102and the other nodes1106,1110are notified of disconnection attempt. For example, the MDM network manager of the disconnecting node's MDM network-aware adapter1104notifies the MDM network-aware adapters1108,1112of the nodes1108,1112about the intention to disconnect (or remove). The MDM network-aware adapters1108,1112of the nodes1108,1112, each severs links. For instance, the MDM network managers of the remaining nodes' MDM network-aware adapters1108,1112transmit a request to all the components in the node and remove references to the disconnecting node. For instance, a message may be sent to all the components in the system, which components may perform appropriate clean up work. For example, the MDM network manager component may update its network information; the MDM server may remove the reference information. The MDM network manager of the disconnecting node1102removes the references to all other nodes. The system no longer recognizes applications or data associated with the disconnected node. The data from end node was only stored as reference, therefore no additional work is needed.

If the disconnecting node has operational link, the following steps may be taken to disconnect (remove) that node from the network of MDM nodes. The system determines the existing connections between the disconnecting node1102and all other nodes1106,1110. The MDM network-aware adapter1104of the disconnecting node1102and the other nodes1106,1110are notified of disconnection attempt. The MDM network-aware adapter1108,1112of each node removes the links. For instance, the remaining MDM system removes setting to update transactional details with the disconnected node1102. The system no longer recognizes applications or data associated with the disconnected node. Previously stored master data to/from the disconnected node remains. The remaining MDM system will no longer receive transaction updates from the disconnecting node. The remaining MDM system can keep stale data and maintain record of the disconnection date or date of the last transactions. Otherwise, the remaining MDM system may delete all data associated with the disconnected node.

Computer program code for carrying out operations for aspects of the present invention may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages, a scripting language such as Perl, VBS or similar languages, and/or functional languages such as Lisp and ML and logic-oriented languages such as Prolog. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

The systems and methodologies of the present disclosure may be carried out or executed in a computer system that includes a processing unit, which houses one or more processors and/or cores, memory and other systems components (not shown expressly in the drawing) that implement a computer processing system, or computer that may execute a computer program product. The computer program product may comprise media, for example a hard disk, a compact storage medium such as a compact disc, or other storage devices, which may be read by the processing unit by any techniques known or will be known to the skilled artisan for providing the computer program product to the processing system for execution.

The computer processing system that carries out the system and method of the present disclosure may also include a display device such as a monitor or display screen for presenting output displays and providing a display through which the user may input data and interact with the processing system, for instance, in cooperation with input devices such as the keyboard and mouse device or pointing device. The computer processing system may be also connected or coupled to one or more peripheral devices such as the printer, scanner, speaker, and any other devices, directly or via remote connections. The computer processing system may be connected or coupled to one or more other processing systems such as a server, other remote computer processing system, network storage devices, via any one or more of a local Ethernet, WAN connection, Internet, etc. or via any other networking methodologies that connect different computing systems and allow them to communicate with one another. The various functionalities and modules of the systems and methods of the present disclosure may be implemented or carried out distributedly on different processing systems or on any single platform, for instance, accessing data stored locally or distributedly on the network.