Glossary

An ACL chain can be thought of as a series (chain) of policies (ACLs) that can be applied to a data event that occurs in the YOUnite Data Fabric. There are inbound and outbound ACL chains for each zone and they are applied to incoming and out going data events. They operate similar to firewall rules and restrict or allow data to flow to and from adaptors between zones.

Inbound ACL is defined by the zone data steward (ZDS) and identifies what data events a zone will allow in.

Outbound ACL is defined by the zone data steward (ZDS) and identifies what data events a zone will send out.

An Adaptor is software located within a system that shares data through the YOUnite Data Fabric and acts as the connection point between a source system and the Data Fabric. An adaptor focuses on 1) detecting data changes in the source system it is connected to and routing the changes to the YOUnite Server as data events. 2) Accepting data events routed from the YOUnite Server that are targeted for the source system the adaptor is connected to. It also ensures that the outbound data from the source system meets the format requirements of the data domains defined in the YOUnite Server 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 YOUnite server. See the Adaptors document for more.

The default adaptor priority when performing a Federated GET. See Gold Adaptor, Silver Adaptor, Data Virtualization and Adaptor Priority.

Upon adaptor initialization, adaptor capabilities adaptor declares to the YOUnite Server what 1) data domain versions are supported in the underlying source systems attached to the adaptor , 2) What data events are supported for the given data domain(s) (i.e. GET, PUT, POST, and/or DELETE) at the adaptor.

The adaptor(s) whose data would be preferred when performing a Federated GET. See Silver Adaptor, Bronze Adaptor, Data Virtualization and Adaptor Priority.

An adaptor that only accepts data events from the YOUnite Server, performs any required transformations and updates the source system. See Adaptor.

An adaptor that only detects changes in the source system, performs any required transformations and sends them to the YOUnite Server so that the can be routed with the appropriate governance. See Adaptor.

Priorities are the levels that a zone data steward gives to adaptors to which it has access. There may be multiple sources of the same data. By assigning a priority (gold, silver or bronze) to the domain, the YOUnite Server knows in which order it should seek to obtain the data giving the zone its own unique view of data. If the source system that contains the highest-priority adaptor is not available then the YOUnite Server attempts to get the data from the next highest-priority adaptor that contains the same data. Priority levels can be set on a per request basis as well.

The adaptor SDK is a Java library for creating adaptors.

The adaptor(s) whose data would be preferred over all adaptors but gold adaptors when performing a Federated GET. See Gold Adaptor, Bronze Adaptor and Adaptor Priority.

Most YOUnite off-the-shelf adaptors can perform inbound and outbound transformations provide utilities for performing data transformations in the DB adaptor on payloads originating from:

See Adaptor, Bronze.

See Parent Zone.

See Data linking, Data discovery.

See Domain.

Create (POST), update (PUT) or delete events in source systems detected by adaptors or, federated GET requests initiated by API requests. A data event is associated with a domain version. The events get forwarded to the router service in the YOUnite Server and delivered to subscribed adaptors as directed by governance. 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.

See Data Issues.

Managing data access (i.e. who accesses certain data sets based on role, application, etc.; defining where the Fedreated Data is stored). More specifically, governance is used to describe if a consumer (API consumer or adaptor) of the YOUnite Data Fabric has access to data in a zone through inbound/outbound ACLs. Governance includes what data movement between applications in a particular zone is allowed, as specified by a zone user for the zone. Governance 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 specific adaptor at another zone, etc.).

A managed role defining 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 system and is/are responsible for applying the Data Governance Policies primarily as regards to the data taxonomy (Data Domains) for the tenant. The Data Governance Steward is a zone user in the root zone.

An architectural framework that allows for the flexible, resilient integration and management of data across various platforms and environments, including on-premises and cloud systems.See YOUnite Data Fabric.

Data Integration (DI) is the process of keeping data up to date between disparate systems.

Data issues are issues that may or may not require resolution, similar to a helpdesk ticket. Typically, whomever manages these issues will review them, resolve them (if necessary) and then close them. This can all be done in the YOUnite UI. This documentation also describes the API calls to manage data issues. See Data Issues and Data Event Exceptions for more.

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 lineage (tracing) includes the data origin, what happens to it and where it moves over time. Data lineage gives visibility for data compliance while greatly simplifying the ability to trace errors back to the root cause in a data analytics process.

The capacity to manage all the federated data records (DRs) in the YOUnite Data Fabric is a key YOUnite feature. In order to manage  the data domains and DRs, YOUnite needs to know where the source entities live. Data linking is the process of mapping source entities to the source systems where they reside. See Standard Data Linking and Data Discovery, Data Linking.

Data discovery is the process of synchronizing and applying data quality rules to federated data managed through YOUnite for a given data domain version by scanning a source systems for source entities and linking them to data records in YOUnite before putting the adaptor in "PLAY" mode. Data records discovered while an adaptor is in data discovery mode are not routed to other adaptors but merely linked to the federated data records maintained by the YOUnite server. See The Data Catalog - Linking YOUnite Data Records to Entities in Source Systems.

The process of synchronizing and applying data quality rules to federated data managed through YOUnite as data events occur (for a given data domain version) at the source systems. The alternative method of aligning data is the process of data discovery. See the document The Data Catalog - Linking YOUnite Data Records to Entities in Source Systems.

Programmatic setting of data access.

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.

There are multiple levels of data quality including format, duplication checking and cross-referencing other elements. Data quality in the YOUnite Data Fabric includes carefully defining data domain versions, domain version properties and, performing data transformations at the adaptor level. Prior to mapping data records into data cleaning/prep or similar tools should be employed to clean the data and look for common patterns used to clean data which can be employed inside of an adaptor and applied to real-time data events detected at an adaptor.

JSON objects that follow the data domain model schema of the YOUnite Data Fabric implementation.

An API request’s view of truth for a given data record belonging to a domain. In a federated model this would entail assembling one or more source entities from one or more source systems attached to adaptors with the highest priority. An API request can override the zone’s data record view.

A zone’s view of truth for a given data record belonging to a domain. In a federated model this would entail assembling one or more source entities from one or more source systems attached to adaptors with the highest priority.

The YOUnite Data Virtualization Service is an optional service that is integrated with the router and data governance services. It provides an API that assembles federated data records by querying adaptors for their data and compiling their results, taking into account ACLs and user permissions. See request data record view and zone data record view. Also known as Federated "GET".

Data Record Key (DrKey) are properties of a Data Domain version and identify those fields that, when combined, are used to detect whether the data record is unique. Refer to Domain Uniqueness, De-Duplication and Matching Algorithms for more.

The adaptors, Message Bus (bus), and router portion of the YOUnite Server that make up the "Data Synchronization" layer of the YOUnite Layers. This layer’s primary task is to synchronize source entities throughout the entire YOUnite Data Fabric.

See Data Record Assembler.

A structured source of data that can be used to generate data marts and reports and analytics to meet end-user needs.  

De-Duplication refers to the responsibility of the YOUnite 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 federated system is in a unique position to help clean up duplicate data. For many organizations, the effort for de-duplication will be limited to reporting duplicate data so that the Data Governance Steward or Zone Data Steward can resolve the issue manually. Refer to Domain Uniqueness, Data Record Key and Matching Algorithm for more.

The initial phase for an organization is to understand the data synchronization 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.

Create data domains, adaptors, clean/map source entities, and all other tasks required to make the YOUnite technology stack work within the customers IT ecosystem. See Design Phase and Implementation Phase.

A domain refers to a data model, such as student or customer, and is defined by the parties responsible for data governance. The goal is to have universally-adopted domains across the organization’s digital ecosystem. Domains are defined via versioned JSON schemas that are specific to the domain version. Schemas constitute the design for Data Records (DRs). Domains can be configured in any way that is necessary to meet the business needs of the organization 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. See Domain Version and the Data Domains document for more.

Identifies a domain as representing data stored in one or more source systems (Federated) or data stored in the YOUnite Server (YOUnite Data Store). YOUnite Data Store domain represents reference data used to validate an element of a record. An example would be a list of valid postal codes. However, reference data is typically stored in federated data domains.

One of the functions of a federated data discovery, cataloging and synchronization platform 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 YOUnite. For example; there should only be one student DR for any given student. Refer to Data Record Key and Matching Algorithm for how YOUnite manages uniqueness.

Domain model entities, such as a customer, in YOUnite that are derived from the various source systems across the YOUnite Data Fabric. While not frequent, there are times when the schema on source systems for these source entities changes, such as an upgrade to the software for a system is applied. It is important that these changes do not break YOUnite’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 YOUnite 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.

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. Vendor selection committees need to be aware of these requirements to create an optimal YOUnite Data Fabric. See the "Selecting Enterprise Applications and Services That Can Meet Your Organization’s Governance Requirements" in the Adaptors document.

YOUnite’s Federated data model refers to a model in which the data handled through YOUnite is not stored centrally in the YOUnite Server but instead references to the data are stored that point to the source systems where YOUnite can retrieve the data (source entities). This model is used primarily for the following reasons:

Federated data unification unifies and presents single pane views to the structured data across an enterprise data tier by:

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 type.

Synonym for Data Record Assembly. Handled by the See Data Virtualization Service for more information.

The ability to delete all or a subset of the physical source entities linked to a Federated data record throughout the entire YOUnite Data Fabric.

Each each object in YOUnite, most notably a data record, has a UUID (Universal Unique Identifier) that is a 128-bit number used to uniquely identify the object or entity. 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 3,400 A.D.

See Adaptor, Gold.

See Data Governance.

A Group, in the context of YOUnite, provides a mechanism for zone administrators to combine zone users and policies (roles) 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 zone users can be assigned to the group and inherit the permissions for that group.

Configuring and deploying the YOUnite Data Fabric so that it can be monitored, managed and maintained in production inside the customer’s IT ecosystem. Refer to Design Phase and Development Phase.

See ACL, Inbound.

The Data Domains in the Federated system. Data in source system databases and data stores is called the physical view of the data. Different source systems typically have different physical views of the same data and the logical view provides an agreed upon structure for transforming the data between source systems.

A Managed role is an immutable role whose permissions are defined by YOUnite. See Root Zone Administrator, Data Governance Steward, Zone Administrator and Zone Data Steward.

Data in a particular domain or a particular element that has been declared by the data governance steward or zone data steward as the Record of Truth. See Data Record. ACLs and adaptor priorities allow zone data stewards to create zone specific zone views of master (golden) records. Adaptor priorities can also be set on a per API request basis (see Request Data Record View).

Matching algorithms are used to determine uniqueness and match Data Records in a Domain Version. The default matching algorithm performs an exact match on all DR Key properties. Custom matching algorithms may be defined that use rules along with a combination of DR Key properties to determine how a match should be determined.

An "exception" occurs when a Data Event cannot be processed due to ambiguity defined by the domain version’s matching algorithm. There are several reasons why an exception might occur when a data event is received:

See Message Bus.

YOUnite uses a JMS message bus (ActiveMQ) for communication between the YOUnite Server, YOUnite Data Virtualization Service, YOUnite Data Notification service and the adaptors. For more see Message Bus Service and router.

Model Schema refers to the attributes (properties), format and other metadata that defines how a specific domain version should expect to store the data, 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.

Applications register and receive notifications of data changes through the YOUnite API. Additionally, applications can request data via the YOUnite API including data that YOUnite does not store locally (federated). See Federated GET.

The YOUnite Notification Service has two functions: 1) To notify consumers (typically a web hook) of metadata events (such as creation of a new zone or domain) and data events (a data record moving through YOUnite) and; 2) Delivering real-time updates to the clients using the YOUnite UI so that the pages can react to changes in underlying metadata. The YOUnite notification service notifies API consumers of events in the YOUnite Data Fabric that they have subscribed to. See the document on Notification Service.

See ACL, outbound.

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.

The object inside of a data event that is transported between Adaptors and the YOUnite Server and that carries the information assets used by the YOUnite processes and activity.

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 administrator or other users that have been given control over a zone’s permissions. Permissions are broken out into two properties:

The way data is physically stored and processed in a source system’s database or data store as opposed to the logical view which is defined by Data Domains in YOUnite. Different source systems typically have different physical views of the same data and the logical view provides an agreed upon structure for transforming the data between source systems.

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 YOUnite resources.

An instance of a record that has been designated as the version of truth for the API consumer or zone data steward. YOUnite’s federated features include giving each zone and/or request the ability to define which adaptors have highest priority. This allows each zone or request to have its own unique view truth for a record. See Zone Data Record View.

See Data Record View, Request.

A named set of permissions that can be assigned to a zone user. There are Managed Roles (Zone Administrator and Zone Data Steward) that manage system permissions and features as well as custom roles that are defined by the zone administrator.

The root zone that is automatically created upon initialization by the YOUnite Server. When a root zone is created, zone users with the Root Zone Administrator and Data Governance Steward managed roles are also created.

The root zone Administrator (root admin) is a managed role within YOUnite performed by a person responsible for the configuration of the root YOUnite zone. The root admin’s primary tasks as the ultimate parent zone is creating child zones and the assignment of roles to the child zones.

The router is the service internal to the YOUnite Server 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. The router communicates with source systems through adaptors using message bus as a means of communication. The router is integrated with the data record assembler and governance services internal to the YOUnite Server.

See Adaptor SDK.

See Parent Zone.

See Adaptor, Silver.

A data record that is contained in a source system such as a database table or object data store.

An application or service that is connected to the YOUnite Data Fabric through a YOUnite adaptor that contains source entities.

Any user of the YOUnite Data Fabric. Everyone must be authenticated through an authorization application. A single SSO user may have multiple zone users associated with them.

See Adaptor Transformations.

The highest-level zone in a YOUnite Data Fabric implementation. At this level, data governance, data domain creation, and domain storage-type decisions are made.

A REST application programming interface that allows developers to access administrative resources and view/modify data records under control of the YOUnite Data Fabric. The API should be used for any business logic while a message bus interface is used for keeping data synchronized. See the YOUnite API for more.

See YOUnite Server.The term "YOUnite API Server" may be used to describe the YOUnite Server in scenarios where it interacts with other services utilizing the YOUnite API.

The scalable web services and micro-services that Adaptors and the YOUnite Server communicate through. These collectively are also referred to as the YOUnite Stack in deployment/IT contexts. A diagram and further descriptions can be found in the YOUnite Data Fabric document. .

A centralized store natively connected to the YOUnite Server that holds data records that are treated as reference data and are infrequently modified. However, reference data is typically stored in designated source systems that are part of federated data domains.

See Data Record Assembler.

All the systems and services that when connected make up a cohesive, orchestrated federated data discovery, catalog, synchronization and governance. This includes the YOUnite Stack, adaptors and source systems. A diagram and further descriptions can be found in the YOUnite Data Fabric document.

Any noun or object in the YOUnite Data Fabric that can be accessed via the YOUnite API e.g. zones, adaptors, data domains, data records, zone users, groups, permissions etc.

An abstract, bottom-up, layered description of the services that the YOUnite Data Fabric Platform provides. This description of YOUnite helps analysts and decision makers quickly understand YOUnite concepts. The first layer is data synchronization between source systems through adaptors and routing. Once data is routing through a YOUnite Data Fabric (and more specifically the YOUnite Server), data governance can be applied. Once data governance is applied, then YOUnite features such as data lineage, Global DELETE, data virtualization and notifications can be leveraged.