YOUnite Adoption Plan
Once you have an understanding of YOUnite you can begin to plan the steps 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, an 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.
If you haven't read it already, you may want to read the Design Phase: Data Analysis Principles of the Federated MDM Process overview. By following the step in the overview, MDM can be eased into your organization.
Adoption Plan
The steps below outline the YOUnite MDM implementation. These phases include the design, development and implementation phases required to fully integrate the YOUnite ecosystem into an organizations IT infrastructure.
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 |
|---|---|---|
| DESIGN PHASE | ||
| 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 taxonomy for the tenant. Please note that actual content control lies with the Zone Data Steward (ZDS). See step 10, below. |
| 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. Equally important in this phase is 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 Data Hub. | Formalize the findings from step 2. |
| 4 | Identify the MDM Admin. | An initial root zone will be created with an MDM Admin and DGS (mentioned above). These users are tied users in your organization's IDP. 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 Design Phase: Data Analysis Principles of the Federated MDM Process. Step 12 can be started in parallel with the following steps. |
| 7 | Plan for the implementation of the YOUnite Ecosystem in a test environment. | Review steps 8-11. |
| DEVELOPMENT PHASE | ||
| 8 | Implement a test YOUnite Ecosystem System. | Configure the YOUnite Data Hub, which includes the MDM Admin and DGS information. When the system initializes it automatically configures the MDM Admin and DGS 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 Data Hub. |
| 9 | DGS Models data domains using the YOUnite UI. | Follows 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. For further details, see: |
| IMPLEMENTATION PHASE | ||
| 13 | Configure the production YOUnite Ecosystem System. | See Step 8 above. |
| 14 | Bring federated data Under YOUnite control. The DGS and ZDS collaborate to map entities in the systems attached to YOUnite adaptors under YOUnite control. | Leverage the 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. |
| 15 | The DGS and ZDS apply appropriate in-bound and out-bound governance (i.e. Access Controls Lists, or ACLs) to the data to be managed. Other data designations as master data and level two data are defined at this time. | The DGS allows you "in-the-door" to the data domain and data record level (federated data record - reference pointers). The ZDS owns the data at the adaptor and determines inbound/outbound ACLs for the zone and the adaptors in the zone. (The DGS owns the reference to the data or data stored in YOUnite Data Hub. The ZDS owns the actual data inbound/outbound ACLs). |
| 16 | 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. |