Glossary

Term	Definition
Access Control List (ACL)	Data controls that control inbound/outbound messages.
Active Data Management	When a provider uses YOUnite API to notify MDM of an event.
Adaptor or Bi-Directional Adaptor	An Adaptor is software located within a system that shares data through the YOUnite Data Hub and acts as the connection point between that system and the Data Hub. An adaptor focuses on ETL (Extract, Transform, and Load) and CRUD functions, ensuring the outbound data from that system meets the format requirements of the Data Hub and transforming the inbound data from the hub into what any other system requires. It may have additional business logic such as filtering for specific data from the Data Hub. An adaptor
Adaptor, Inbound	An adaptor that only accepts data events from the Data Hub, performs any required transformations and updates the source system. See adaptor.
Adaptor, Outbound	An adaptor that only detects changes in the source system, performs any required transformations and updates the source system. See adaptor.
Adaptor Capabilities List	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.
Adaptor Layer	Pub/Sub, Message Bus, Adaptors, Routers.
Child Zone	See Parent Zone.
Configurable Data Policy	MDM system allows for the configuration of data rules and policy such that the clients can enforce their data management and regulations. YOUnite allows defining access programmatically so data can flow through the routers as data management policies dictate.
Coexistance MDM	The features of a federated system allows for the Coexistance MDM model. A Coexistence style allows for maintaining a master data record in the same way as the YOUnite Data Store, but your master data is stored in a system connected to YOUnite via an adaptor and is recognized as a golden store for one or more data domain versions for all or a subset of systems in the ecosystem. The standard YOUnite governance resources are used to control the flow of master data out of the golden store system. It is incumbent for the data stewards to insure that all of the properties of the data domain model is normalized for all subscribing systems and that the master data is clean before publishing out to the ecosystem.
Data Event	Create, update or delete events in source systems detected by adaptors or, federated GET requests initiated by API federated GET requests. The events get forwarded to the router in the data hub and delivered to subscribed adaptors as directed by the governance ACLs. In the case of federated GETs, the adaptors respond and deliver additional data events in response to the router and the payloads of the data event are assembled and delivered to the API consumer initiating the federated GET.
Data Governance	Managing data access (i.e. who accesses certain data sets based on role, application, etc.; defining where the Master Data is stored).
Data Governance Steward (DGS)	Any person or person's designated as the Data Steward by the governance organization by tenant. This person or person's are assigned the Data Governance Steward role in the YOUnite MDM system and is/are 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.
Data Integration (DI)	Data Integration (DI) is the process of keeping data up to date between disparate systems.
Data Lake	A storage repository for source data that can be persisted as it comes from the source and then used for data mining and auditing purposes.
Data Management Layer	Programmatic setting of access.
Data Mart	A data mart is a subset of a data lake and is defined by a unifying theme, such as application or department. End users with specific needs to access and report on the data can then have access to that limited data set, employing permissions.
Data Quality	Need to define data quality as it pertains to MDM including answering "Where does data quality take place?". Adaptor? Conductor? Consider multiple levels of data quality including format, duplication checking and cross-referencing other elements. here's a run at it (Data quality in the YOUnite ecosystem starts includes carefully defining data domain versions, domain version properties and, performing data transformations at the adaptor level.)
Data Record (DR)	JSON objects in motion that follow the data domain model schema of the MDM ecosystem.
Data Record Assembler	Lives inside the YOUnite data hub and is part of a router. Assembles the inbound data and presents an effective data record for an API consumer or adaptor based on their access/permissions.
Data Warehouse	A structured source of master data that can be used to generate data marts and reports and analytics to meet end-user needs.
De-Duplication	De-Duplication refers to the responsibility of the MDM system to identify and then either report and/or resolve duplicate Data Records (DRs). As something of a centralized clearing house for shared data across the organization, the MDM system is in a unique position to help clean up duplicate data. For CCCTC the effort for de-duplication will be limited to reporting duplicate data so that the Zone Data Steward can resolve the issue manually. Refer to Domain Uniqueness, Determinstic Uniqueness, Probablistic Uniqueness, and Fast Duplicate Detection Properties for more.
Design Phase	The initial MDM phase for an organization,. Understand the data integration/MDM needs, identify stakeholders, organizational department/division boundaries — which leads to overall system deployment strategy, data domains, adaptor requirements, and implementation plans. See Development Phase and Implementation Phase.
Development Phase	Create data domains, adaptors, clean/map source entities, and all other tasks required to make the product work within the customers IT infrastructure (e.g. with products and services such AWS, OAuth, Zuul, Conductor, etc). See Design Phase and Implementation Phase.
Deterministic Uniqueness	Deterministic Uniqueness is an MDM approach to detecting whether an MDR is unique for it's domain (refer to Domain Uniqueness). When a transaction through MDM attempts to POST (add) a new record, Deterministic Uniqueness combines one-to-many individual attributes (fields) that make up the MDR and queries the MDM stored values for that domain to make sure that they do not already exist. If they do then a process is initiated to resolve and/or report the duplication.The attirbutes that collectively define uniqueness for that domain are identified by the Zone Data Steward. The CCCTC MDM implements Deterministic Uniqueness.
Domain	A domain refers to a data model, such as student or course, and is defined by the parties responsible for data governance. The goal is to have universally-adopted domains across the CCCs. Domains are defined via versioned JSON schemas that are specific to the domain version. Schemas constitue the design for Master Data Records (MDRs). Domains can be configured in any way that is necessary to meet the business needs of the CCC, colleges and districts when it comes to sharing data. For instance, a domain may be a "Student" that includes data definitions (properties) such as student name, address, etc.
Domain Type	Identifies a domain as representing data stored in a local system (Federated) or data stored in the YOUnite Data Hub (YOUnite Data Store). Typically a YOUnite Data Store domain represents reference data used to validate an element of a record. An example would be a list of valid colleges.
Domain Uniqueness	One of the functions of an MDM system is to detect, resolve, and avoid duplicate data, which is a significant problem in an organization dependent on many disparate systems. Uniqueness refers to a Data Record's (DR's) state as being the only representation within that domain across the systems managed by MDM. For example; there should only be one student DR for any given student. Refer to Deterministic Uniqueness and Fast Duplicate Detection Properties for how CCCTC MDM manages uniqueness.
Eventing	In terms of adaptors and the source systems they interact with, eventing is the ability of a source system to notify adaptors of source entity changes typically through the source systems APIs. Source systems with robust APIs allow developers to implement adaptors that can register for change event notifications that map to a data domain version's data records and optimally, to data record properties. See Adaptors.
Fast Duplicate Detection Properties (FDDPs)	Fast Duplicate Detection Properties are attributes of a Domain and identify those fields that, when combined, MDM should use to detect whether the DR is unique. Refer to Domain Uniqueness, Deterministic Uniqueness, and De-Duplication for more.
Federated	Federated refers to an MDM model in which the data handled through MDM is not stored centrally in the Data Hub but instead a reference to the data is stored there that points to the the source system where the data hub can retrieve the data. This model is used primarily for two reasons. Often it is an interim approach when organizations are not ready to migrate data to a centrally stored location and commit to updating the software on many systems to then point to the data stored in the data hub. Instead of implementing duplicate data storing an organization may choose a Federated approach. While this is true for CCC it is also a model that accommodates the college sensitivity to not having full control over the storage of their data, especially as it pertains to very sensitive student personal data (PII).
Federated Data Record/Effective Data Record (FDR)	Any data that is assembled from one or more systems (connected through adaptors) by the router based on the combination of inbound and outbound ACLs in response to a request for data. Applicable only to a domain identified as a federated storage type.
Federated GET	An API request for a federated data record. The request is actually made using HTTP POST since the data hub makes requests to all appropriate adaptors (based on governance), waits for their reply, assembles the data and then delivers it to the API consumer's callback handler.
Globally Unique Identifier (GUID)	A UUID (Universal Unique Identifier) is a 128-bit number used to uniquely identify some object or entity on the Internet. Depending on the specific mechanisms used, a UUID is either guaranteed to be different or is, at least, extremely likely to be different from any other UUID generated until 3400 A.D.
Group (MD Group)	A Group, in the context of MDM, provides a mechanism for Zone Administrators to combine Zone Users and Policies together making it easier to assign Permissions. For example, a group can be defined that has permission to certain systems within a zone or multiple zones. Then users can be assigned to the group and inherit the permissions for that group.
Hub (Router)	The Hub, also referred to as the Router, is the Enterprise Service Bus component of the MDM system. It is responsible for receiving and accurately transmitting the data to be shared to the proper systems that have registered to be updated when changes to a given domain are received.
Implementation Phase	Configuring and deploying the YOUnite ecosystem so that it can be monitored, managed and maintained in production inside the customer's IT infrastructuire. Refer to Design Phase and Development Phase.
Inbound ACL	Inbound ACL is defined by the Zone Data Steward (ZDS) and identifies what data a Zone will allow in.
Master Data	Data in a particular domain or a particular element that has been declared by the DGS or ZDS as the Record of Truth.
Master Data Management (MDM)	MDM is the process of describing and cataloging data inside of an organization and understanding which stakeholders value which sources of data. Gartner's Definition: "Master Data Management (MDM) solutions are software products that: • Support the global identification, linking and synchronization of master data across heterogeneous data sources through semantic reconciliation of master data. • Create and manage a central, persisted system of record or index of record for master data. • Enable delivery of a single view of one or more subject areas to all stakeholders, in support of various business initiatives. • Support ongoing master data stewardship and governance requirements through workflow-based monitoring and corrective-action techniques. • Are "agnostic" with regard to the business application landscape in which they reside; that is, they do not assume or depend on the presence of any particular business application(s) to function." The YOUnite DataHub MDM is an MDM Data Management system that supports Notifications through either a Publish/Subscribe methodology or a Request/Respond methodology. In addition, it provides element-level authorization through a feature called ACLs in which both Inbound ACL and Outbound ACL can be defined for data Consumers and data Providers. At the center of the YOUnite is the Data Hub which consists of a Router for directing data traffic. Depending on the implementation approach to security either an Adaptor resides on the MDM side of the Consumer/Provider firewall and directly monitors the Consumer/Provider system for changes to outbound ACL data or, for a more secure approach, an Agent residing inside the firewall of the Consumer/Provider monitors for outbound ACL data and communicates this to the adaptor.
MDM Resources	Any noun or object in the MDM eco system that can be accessed via the YOUnite API e.g. zones, adaptors, data domains, data records, users, groups, permissions etc.
MDM Root	The root zone that is automatically created upon initialization of the YOUnite Data Hub. When a root zone is created, the Admin and Data Governance Steward roles are also automatically created.
Model Schema	Model Schema refers to the attributes (properties), format and other metadata that defines how a specific Domain should expect to store the data (either in the YOUnite Data Store or Federated), for the purposes of standardizing on how to exchange data between systems. The Data Governance Steward is responsible for configuring and maintaining domain model schemas.
Notification & Data Access Layer	Applications register and receive notifications of data changes. Applications can request data via MDM API that the application does not store locally.
Notification Manager	Notifies API consumer when events occur that they've subscribed to
Organic Data Mapping	The process of synchronizing and applying data quality rules to data managed through MDM as data events occur to the data (for a given data domain version) such as a create or update. The alternative method of aligning data is to synchronize and check data quality of all the data for a given data version immediately after the data domain version is created and then organically mapping new entities as they are detected.
Outbound ACL	Outbound ACL is defined by the Zone Data Steward (ZDS) and identifies what data a Zone will send out.
Parent Zone	A Parent Zone describes the relationship of a zone to other zone's that it encompasses. A parent zone may contain systems and/or other zones called child zones that in turn define a subset of zones and/or systems of the parent zone. Through this hierarchy, administrators can implement higher levels of fidelity over the permissions for access to systems and data. Zones that have the same parent zone are called Sibling zones
Passive Data Management	When a Provider uses a YOUnite adaptor to notify MDM of an event.
Payload	The object, usually in the JSON language, that is transported between Adapters and the Data Hub and that carries the information assets used by the MDM processes and activity.
Permissions	YOUnite users can be granted or denied access to resources by setting appropriate permissions. Permissions do not stand on their own but are grouped into roles. Generally permissions are managed by the Zone Admin or other users that have been given control over a zone's permissions. Permissions are broken out into two properties: Resource URI: The YOUnite resource that is part of the user's zone. If the zone user has the appropriate permissions, they can allow other users to access a resource such as a domain, MDRs, logs, adaptors, etc. Actions: These are the actions the user can perform on the resource. They include GET, PUT, POST, DELETE, PATCH (and ALL). https://younite.atlassian.net/wiki/display/KBASE/Zones%2C+Users%2C+Groups%2C+Roles+and+Permissions
Preferred Zone	A preferred zone is an abstract concept. A single SSO user may have multiple zone users spread across multiple zones. An application developer can ask the SSO user that has multiple zone users which zone they prefer to operate under before making requests to MDM resources.
Priorities (Levels)	Priorities are the levels that a ZDS gives to adaptors to which it has access. There may be multiple sources of the same data. By assigning a numeric priority (or Level) to the domain, the MDM system knows in which order it should seek to obtain the data. If the system that contains the highest-priority adaptor is not available then MDM attempts to get the data from the next highest-priority adaptor that contains the same data.
Probabilistic Uniqueness	Probabilistic Uniqueness attempts to go further than Deterministic Uniqueness in identifying duplicate transactions by assigning a priority to each of the attributes that collectively define what is a unique Master Data Record (MDR). As an example: uniqueness for a student may consist of the student first and last name, street, city, state, zip code and phone number. It may be that all the fields match an existing record except for the street name which is only off by a few characters. This may indicate a spelling error when the street was manually entered. While the first and last name must match exactly and so were defined as a high priority when identifying duplicates, the street may have been defined as a low priority so, in this case, MDM would assume the existing MDR is a "probably" a duplicate and would act accordingly. See Deterministic Uniqueness for contrast. The CCCTC MDM does not implement Probabilistic Uniqueness.
Record of Truth/Source of Truth	An instance of a record that has been designated as the Master Data.
Role	A named set of permissions that can be assigned to a user. There are Managed Roles (Zone Admin and Zone Data Steward) that manage system permissions and features as well as Custom Roles that are defined by the Zone Admin.
Router	The component that is responsible for routing data throughout the ecosystem. It is comprised of the Data Record Assembler and ACL Manager.
Scope	A governance-related term to describe if a consumer or user of the system has access to data in a zone through inbound/outbound ACLs. Scope includes what data movement between applications in a particular zone is allowed, as specified by a zone user for the zone. Scope also can be applied through granular access control for a zone's data record properties (allowing/disallowing data record properties from leaving a zone or going to a a specific adaptor at another zone, etc.).
Sibling Zone	See Parent Zone.
Source Data Record or Source Entity	A data record that is contained in a container such as a database table or object data store.
Source System	An application or service that is connected to the YOUnite ecosystem through a YOUnite Adaptor.
SSO User	Any user of the YOUnite Data Hub. Everyone must be authenticated through an authorization application. A single SSO user may have multiple zone users associated with them.
Tenant	The highest-level zone in the ecosystem. At this level, data governance, data domain creation, and domain storage-type decisions are made.
Version (Domain Version)	Domain's model entities, such as a student, in MDM that are derived from the various systems across CCC that MDM manages. While not fequent, there are times when the schema on the Source System for these entities changes, such as an upgrade to the software for a system is applied. It is important that these changes do not break MDM's ability to share data with other systems that rely on it. It is also not feasible to expect all of the systems that rely on this data to update their Adaptors to handle the change in parallel. For that reason a Domain is assigned a Version. When a system collaborating with MDM registers to be notified of any changes in a domain or registers to be able to update a domain, the system specifies a version that it is expecting to work with. Ultimately, all system adaptors should be updated to work with the most current version but versioning allows them to do this on their own schedule.
YOUnite API	A RESTtful 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.
YOUnite Data Hub	The scaleable web application that handles the API and message broker requests that adaptors and the YOUnite API consumers communicate through.
YOUnite Data Store	A centralized store natively connected to the data hub that holds data records. The domains configured for this data store are locked in as the source of master data for that domain in the Tenant.
YOUnite Ecosystem	All the components that make up the YOUnite system. This includes the Data Hub, Message Bus, Notification System, etc.
YOUnite Runtime Stack	The components of the YOUnite ecosystem that are used during runtime to provide the core MDM services. This includes: 1. The YOUnite Router, Message Bus, and Adaptors to create a data synchronization runtime engine 2. Data management handles publish/subscribe actions 3. Event Notification: applications can register for source data change events. This also includes using YOUnite as an operational data store when a YOUnite consumer requires data that it does not store itself.
YOUnite UI	An administrative browser interface that leverages the YOUnite API for managing the ecosystem of the data hub. It provides a window for the Data Steward to view the Master Data.
Zone	A zone refers to a collection of systems/applications owned by groups inside of an organization. Zones are defined within MDM by the MDM Administrator for each zone. They act as a boundary for which permissions may be defined so that a college and/or district can control what data is accessible in their systems from other colleges/districts. All resources within MDM belong to a zone and some resources, such as users, can belong to multiple zones. Each zone has, at a minimum, two Zone roles: a Zone Admin and a Zone Data Steward.
Zone Administrator	A Zone Adminstrator is a role within MDM performed by a person responsible for the configuration of the zone(s) under their authority. Zone Administrator tasks include: creating Zone Users, assigning Permissions, and creating child zones.
Zone Data Steward (ZDS)	The Zone Data Steward is a role within MDM performed by a person responsible for the accuracy of the data being handled by MDM for the zone(s) that they are responsible for. Tasks include providing domain modeling input to the Data Governance Steward, assigning ACLs, working with adaptor developers and implementors, managing error notifications from MDM and resolving duplicate data detected by MDM. Any person or persons designated as the Data Steward by the governance organization for a zone. This role includes the management of the ACLs and access in the zone.
Zone Source Data Record	A Zone's source of truth for a given data domain. In a federated model this would typically be a system attached to an adaptor.
Zone User	Zone Users can either be systems that publish and/or subscribe to data to be shared through MDM, or roles performed by either a Zone Administrator or a Zone Data Steward.