If you are new to Master Data Management (MDM) you will need to be familiar with the concepts on the page What is Master Data Management?.
YOunite is a robust, configurable federated data integration system with master data capabilities. YOUnite allows an organization to gently transition to the goal of Master Data Management without forcing them into an "all-or-nothing" approach. It provides tools that allow data governance to:
- Describe data models
- Group applications/services into organizational boundries
- Manage access control to the data (governance)
- Decide which applications/services contain master data
- Integrate and transform data between applications/services
YOUnite includes a user-facing tool (YOUnite UI) that gives customers the ability to secure and control data flow both into and out of a company's departments or divisions "zones." A "zone" in YOUnite, is a grouping of resources for a given entity. For example, a college district may have a "parent zone" for accessing data across its district colleges. Each college within that district would have its own "child zone," providing access to data for only that college. There is more on zones below.
YOUnite addresses the issue of "What is the record of truth?" for a resource in any given context. That source of truth is called a "master data record" and the resource might be a customer, a product order, a college, or a course. MDM provides multiple points for updating these resources and ensures that the master record is always updated, but allows each zone to determine where those updates are applied. For example, a student address in an application system is updated by the student. YOUnite receives this change and updates the address data record. The college zone scope ACLs will then determine if this updated address is applied to the Student Information System, Learning Management Systems or any other application that stores the student address.
Data Domains
Data domains are the heart of MDM. In traditional database parlance, data domains are a collection of fields (values) that are encompassed by an attribute (database column). For example, using a Customer table example below, the timeZone attribute has data domain of A, P, M, C, E, or null. In other words, the data for timeZone is limited to this data set.
The timeZone data for customer records might appear as in the following example:
In MDM, domains are schemas that refer to the specific table (i.e. the domain would be Customer, using the first example above). The actual data stored (such as each row in the second example above) represents what is called the Data Record (DR).
The MDM data architect's goal is to:
- create data domains that will normalize data across many systems
- manage access to their organization's disjointed data sets (referred to as governance)
Some MDM solutions have fixed or rigid data domains that are generally tied to a given vertical (e.g. manufacturing or finance) but YOUnite allows data architects to:
- create data domains that reflect their organization's requirements (referred to as Multi-domain MDM)
- version their data domains to accommodate new applications and application versions
Once a domain is created and its data loaded, it can be referenced by other data domains, data stewards, and by API consumers as a source of truth. YOUnite domains are defined with JSON.
YOUnite Data Store vs Federated Domains
Each record within the domain is referred to as a data record or DR.
DRs can be stored in a "YOUnite Data Store" domain (inside YOUnite) or a federated domain.
If a domain is stored inside the MDM (YOUnite) Data Store, the DRs are stored inside YOUnite and can be retrieved, in whole or in part, by applications. Domains that are either not sensitive to an organization (e.g. a list of courses in a college system) or are reference material that doesn't generally change (e.g. list of states, countries, etc) are good candidates for MDM data store domains.In a federated domain, the DRs are NOT stored inside YOUnite but are created in real-time by referencing the elements (or properties) as they are stored in the multiple systems. If customer data is sensitive in an organization where one division (e.g. sales) spends a great deal of time managing it, they may not feel comfortable migrating their customer data to a MDM data store such as YOUnite but will continue to maintain and manage it themselves. However, the organization may mandate that the Sales division share their customer data with other organizations. This is a candidate for a federated domain.
In the federated domain model, YOUnite stores information about where the customer data is stored, when it was last updated, and who it is shared with but the customer data is physically located only in that organization's various systems. The data stored by YOUnite in this scenario is extraneous information and is referred to as the metadata. The permission-related information (who the data is shared with) is called the scopes. Federated MDM has added latency that is often offset by the way it handles updates to DRs. Changes can be thought of as diffs. Instead of sending the entire DR metadata to YOUnite when a change is made to its data, only the actual changes are sent.
Domain Property Types
Standard primitives types (integer, floating point numbers, strings and enumerations) are supported as well as arrays and cross-references between domains.
For more a more on domains see the Data Domains guide.
The Operational Side of YOUnite: Zones
One of the key design goals of YOUnite is the ability to group an organization's master data resources by the organization's structure (e.g. divisions, departments, districts, schools, etc.) and then create relationships within that organization. YOUnite calls these groupings zones. A zone example might be the California Community College (CCC) system, where a zone could be the CCC Chancellor's Office, Butte College, and the Los Rios Community College District.
Zones contain domains, adaptors, logs, scopes, and other resources. Zones are associated with each other in a hierarchical structure with parent, sibling, and child zones. In the example of the college school district, the schools within that district might be considered child zones, for example.
Zone Users
When a zone is created, two distinct users are defined:
Zone Admin: The admin is responsible for operational tasks, such as:If you are new to MDM you will need to be familiar with the concepts on the page What is Master Data Management (MDM)?.
YOUnite is a robust, configurable, federated data-integration system with master data capabilities. YOUnite allows an organization to gently transition to the goal of MDM without forcing it into an "all-or-nothing" approach. It provides tools that allow the organization to:
- Describe data models
- Group applications/services into organizational boundaries
- Manage access control to the data (governance)
- Decide which applications/services contain master data
- Integrate and transform data between applications/services
YOUnite includes a user-facing tool, YOUnite UI, that provides:
- An administrative interface for managing the YOUnite ecosystem.
- A Data Steward interface for managing Governance and Master Data.
With YOUnite you can create zones to group the resources for a given entity. A single zone refers to a collection of systems/applications owned by groups inside of an organizations. Zones are defined within MDM by the MDM Administrator for each zone. They act as a boundary for which permissions and governance may be defined so that an one group in an organization can control data flowing in and out between other groups. For example, an educational institution may have a college district office responsible for many colleges within the district. You can create a "parent zone" for the college district office for accessing data across all of its district colleges. Each college within that district could then be grouped into a "child zone," with YOUnite securing and controlling data flow into and out of each. Read more on zones below.
YOUnite addresses the issue of "What is the record of truth?" for a resource in any given context. That source of truth is called master data. The resource might be a customer, a product order, a college, a course, etc. MDM provides multiple points for updating these resources. It also ensures that the master data record is always updated while allowing each zone to determine where those updates are applied. For example, if a student updates their address in the college application system, YOUnite receives this change and consults the college zone's Adaptor Capabilities Lists then determine if the updated address is applied to the Student Information System (SIS), Learning Management Systems (LMS), or any other application that stores the student's address. Adaptor Capabilities Lists consist of the capabilities an adaptor declares to the YOUnite Data Hub upon initialization that 1) link records in the underlying application/service to YOUnite data records, 2) POST entries in the underlying application/service that link to YOUnite data records, and 3) manipulate data in the underlying service.
Layer 3 - Data Access and Notifications
Users and applications can use YOUnite as an operation data store for Data Access.
Layer 3 - API Access, Data Access, and Notifications
Users and applications can make requests and gain data access through the YOUnite API. YOUnite becomes an operation data store when accessing data records through the API.
Note: The YOUnite API is a RESTful application programming interface that allows developers to access administrative resources and view/modify data records under control of the YOUnite Data Hub. The API should be used for any business logic while the message bus is used for keeping data synchronized.
Notifications allow events to be generated and delivered to legacy applications to trigger business logic. If, for example, an employee is promoted, and the HR system updates the employee's record – record, the adaptor attached to the HR system can detect the change and pass it on to YOUnite where it can then notify other systems that have registered interest in employee status changes.
Layer 2 - Data Governance
Defines what zones choose Data governance defines what data a zone chooses to share and receive (inbound and outbound scopes, outbound, and operational ACLs) with other zones and adaptors. For example, the HR Zone may choose to restrict changes it receives (inbound) from a system that is part of the Manufacturing zone or, from all systems in a Zone that represents an organization that has been spun off to another company. part of the Manufacturing zone. Or, the HR Zone may restrict changes it receives from an entire zone representing a company spin-off subsidiary and all its systems. Or, the HR zone may apply governance ACLs on its own system, preventing personal information from being shared outside of the system (outbound).
Layer 1 - Data Synchronization
The Adaptors adaptor makes the connections between YOUnite and the legacy systems in the organization's ecosystems. Adaptors extract, transform, read and write load data in into and out of the legacy systems. Business logic is generally not part of an adaptor.