Once the user has an understanding of YOUnite they can begin to plan the steps needed to implement it.
Most organizations have selected multiple vendors for various solutions for good reasons. Divisions often pick the best solution to meet the needs of their operations. For example, the sales organization may select one CRM while accounting uses a different CRM from a different vendor. Both selected the best solution for their own individual needs.
YOUnite has focused on making the processes and implementation of data integration and MDM as intuitive as possible and allows organizations to ease into the process with features like data domain versions. With data domain versions, the organization can start with a small set of data to be shared between systems and organizations and can organically grow the set with new versions of the same data domain. Before starting read the quick overview Data Analysis Principles of the Federated Master Data Management Process. By following the step in the overview,, MDM can be eased into your organization.
It is assumed that the appropriate stakeholders in your organization have committed to the process of integrating data with a cohesive solution (see step 4 below):
| Sequence | Step | Summary |
|---|---|---|
| 1 | Identify the Data Governance Steward (DGS). | The DGS is a person or person's designated as the Data Steward by the governance organization of the tenant. This person or person's are assigned the Data Governance Steward role in the YOUnite MDM system and is responsible for applying the Data Governance Policies primarily as regards to the data taxanomy for the tenant. Please note that actual content control lies with the Zone Data Steward (see #10. |
| 2 | Identify integration use cases that need to be addressed and the associated Zone Data Stewards (ZDS). | Identify data integration/synchronization use cases, systems and stakeholders that have MDM needs. Just as important this phase includes identifying governance and data event notification requirements. |
| 3 | Identify the data that needs to be integrated and the systems that need to connect to the YOUnite DataHub. | Formalize the findings from step 2. |
| 4 | Identify the MDM Admin. | A root zone is created with a MDM Admin and DGS (mentioned above). These users are tied users in your organization's IDP. Its important to note that the MDM Admin is responsible for permissions to the system and the DGS's role is related to data governance. Another key point is that by default, the DGS is NOT in control of the data at at the adaptors in the zones. |
| 5 | Set expectations and insure absolute buy-in from all parties responsible for those systems. | Expediting the YOUnite deployment is critical since there are many moving components that need to converge for the overall success of the project. A single stakeholder can stall the effort so its important to get complete buy-in from all parties involved. |
| 6 | DGS determines which data domains that need to be modeled | See the Data Analysis Principles of the Federated Master Data Management Process. Step 12 can be started in parallel with the following steps. |
| 7 | Plan the implementation of the YOUnite Ecosystem. | See steps 8-11. |
| 8 | Implement the YOUnite Ecosystem System. | Configure YOUnite Datahub which includes the MDM admin & DGS information. When the system initializes it automatically configures the MDM admin and DGS it with this information. Configuration includes configuring and deploying YOUnite's message broker, logging systems and integrating with the organization's SSO ID with the YOUnite DataHub. |
| 9 | DGS Models data domains using the YOUnite UI | From Step 6 |
| 10 | Create Zones and Users/Roles in the YOUnite UI | Includes Zone Admin and Zone Data Steward or each zone. |
| 11 | Load data into the YOUnite Data Store if any of the domains are defined to use YOUnite Data Store. | This is generally reference data available to everyone across the system |
| 12 | Develop the adaptors using the YOUnite adaptor SDK | Design and write the appropriate GET/PUT/POST/DELETE methods that map, and often transform, data records in the organizations source systems. The entities in the source systems map to the YOUnite data domains. This includes detecting changes in entities in the source system and sending them to YOUnite. Adaptors are written with the YOUnite Adaptor SDK. This step can be started after step 6. |
| 13 | Bring Federated Data Under YOUnite Control. DGS & ZDS collaborate to map entities in the systems attached to YOUnite adaptors under YOUnite control | Leverage YOUnite API to map existing entities in the source systems to YOUnite Data Hub data records. This phase includes data cleaning and de-duplication of source entities. |
| 14 | DGS & ZDS apply appropriate in-bound and out-bound governance (ACLs) to the data to be managed. Other data designations as master data and level 2 data are defined at this time. | DGS allows you "in-the-door" to the data domain and data record level (federated data record - reference pointers). ZDS owns the data at the adaptor and determines inbound/outbound ACLs for the zone and the adaptors in the zone. (DGS owns the reference to the data or data stored in YOUnite data hub. ZDS owns the actual data inbound/outbound ACLs) |
| 15 | New and legacy applications become MDM aware. | Users and New and/or legacy applications can use YOUnite as an operational store and can register to receive notifications when change occur to data records mapped to YOUnite. |