ABCDE
1
TERMDEFINITIONNotes from AlexNotes from RobbieNotes from YOUnite
2
Master Data Management (MDM)The CCCTC MDM is a Data Management system that supports Notifications through either a Publish/Subscribe methodology or a Request/Respond methodology. In addition it provides data element-level authorization through a feature called Scopes in which both Inbound Scope and Outbound Scope can be defined for data Consumers and data Producers.

At the center of the CCCTC MDM is the Data Hub which consists of a Router for directing data traffic. MDM provides an adaptor sdk that allows connecting to services such as SIS, LMS, Staff or database systems to the data hub.

From Anuj:
The CCCTC MDM is a 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 Scopes in which both Inbound Scope and Outbound Scope can be defined for data Consumers and data Providers.

At the center of the CCCTC MDM 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 scoped data or, for a more secure approach, an Agent residing inside the firewall of the Consumer/Provider monitors for outbound scoped data and communicates this to the adaptor.

From Mark and I think Alex:
MDM is not a thing but a PROCESS.

From YOUnite Confluence:
MDM is the process of describing and cataloging data inside of an organization and understanding which stakeholders value which sources of data. 		We need to lock down what the CCCTC wide view is opn the master record and how much is centrally stored- is it only IDM data? Or is it core demographics? How is this related to the warehouse which WILL be centrally storing and does the MDM have access to that central store?
3
ZoneIn practical terms for the CCCTC MDM a zone refers to a collection of systems/applications owned by a college, district or other organizations within CCC. Zones are defined within MDM by the MDM Administrator for each zone. They act as a boundary for which permissions and scopes 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 Data Steward.This isnt a bad definition In practical terms for the CCCTC MDM a zone refers to a collection of systems/applications owned by a college, district or other organizations within the CCC. Zones are defined within MDM by the an MDM Administrator. They act as a boundary for which permissions and pub/sub filters may be defined. Most resources within MDM belong to a zone and some resources, such as users, can belong to multiple zones. (NOTE TO TEAM: /mdrs , /domains, /token and /schemas don't belong to a zone but are managed by zone users with the appropriate permissions).
4
DomainIn the context of CCCTC MDM a domain refers to a data entity such as student or course and is defined by the parties responsible for data management. The goal is to have universally adopted domains across CCC. Domains are defined via JSON Schema's that are versioned. Schema's constitue the design for Master Data Records (MDR's). Domain's 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 (properties) such as student name, address, etc.I wouldn't use the word "data entity" as a domain might have multiple data entities within it. For instance "student enrollment " could be its own domain or be a subdomain of either student OR a school.... This taxonomy is one of the data archtiecture tasks we need to do very quickly for multiple CCCTC projects.I think I'd mention that the schema is specific to the Domain Version.In the context of CCCTC MDM a domain refers to a data model such as student or course and is defined by the parties responsible for data management. The goal is to have universally adopted domains across CCC. Domains are defined via JSON Schema's that are versioned. Schema's constitue the design for Master Data Records (MDR's). Domain's 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. (TO TEAM: this said "... that includes data (properties) such as student name...".
5
Data Record (DR)JSON objects in motion that follow the data domain model schema of the MDM ecosystem
6
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 scope in response to a request for data. Applicable only to a domain identified as a federated storage type.
7
YOUnite Data StoreA 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.
8
TenantThe highest level zone in the ecosystem. At this level data management, data domain creation and domain storage type decisions are made.
9
Master DataData in a particular domain or a particular element that has been declared by the DMS or ZDS as the Record of Truth.
10
Record of Truth/Source of TruthAn instance of a record that has been designated as the Master Data.
11
Data Management Steward (DMS)Any person or person's designated as the Data Steward by the management organization by tenant. This person or person's are assigned the Data management Steward role in the YOUnite MDM system and is resonsible for applying the Data management Policies primarily as regards to the data taxanomy for the tenant. Please note that actual content control lies with the Zone Data Steward.
12
Zone Data Steward (ZDS)Any person or person's designated as the Data Steward by the management organization for a zone. This role includes the management of the scopes and access in the zone.
13
RoleA named set of permissions that can be assigned to a user. There are Managed Roles which manage system permissions and features as well as a Custom Roles that are defined by the Zone Data Steward or admin.
14
Zone Source Data RecordA Zone's source of truth for a given data domain. In a federated model this would typically be a system attached to an adaptor.
15
PermissionsYOUnite 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		What about Publish and Subscribe? and all permissions need to reolve around verbs and objects right as a dyad? and what about function permissions that kick off a service that might involve multiple HTTP actions.Scope and permisisons aren't currently related to each other. Permissions are for the REST interface. Scopes are still yet to be defined, though some of the same terminology may be used.Permissions define what actions a user or system can perform on the resources that are part of MDM. The actions are based on REST and limited to GET, POST, PUT, PATCH and DELETE. This is in contrast to publish and subscribe filters (see accompaning definitions).
16
ScopeWithin MDM Scopes define which users and which systems have access to which data within a Zone. Scopes can cross zones. They are defined at the Domain level as well as down to the attribute (field) level.. In order to have scope to a domain's data the user or system must first have scope for the zone in which the domain belongs.
https://younite.atlassian.net/wiki/display/KBASE/Scopes		Scope is a terribly terribly overladen piece of semantics. It would serve us well to converge on a less confusing term for this. Perhaps "Authorization Scope" or "Access Frame"
17
Inbound ScopeInbound Scope is defined by the Zone Data Steward (ZDS) and identifies what data a Zone will allow in
18
Outbound ScopeOutbound Scope is defined by the Zone Data Steward (ZDS) and identifies what data a Zone will send out
19
Priorities (Levels)Priorities are the levels that a ZDS gives to adaptors to which it has scope. 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. We need an adjuective here- Level is way too genric. I might go with "Ownership Chain", "Data Providor Level". We also need to distinguish the idea of a "default Providor"
20
Parent ZoneA 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
21
Child ZoneSee Parent Zone
22
Sibling ZoneSee Parent Zone
23
AdaptorAn Adaptor is software that is located within a system that is participating in the sharing of data through the YOUnite Data Hub and acts as the connection point between the systema and Data Hub. It focuses on ETL ensuring the outbound data from the system meets the format requirements of the Data Hub and transforming the inbound data from the hub into what the system requires. It may have additional business logic such as filtering for specific data from the hub.Are they all Restful service adapters. Or is this truly a genric description? Is it only for MDM or could other projects share the Adapter.
24
FederatedFederated 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 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 interrim 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 storing of the data they choose a Federated approach. While this is true for CCC it is also a model which accomodates the sensitivity of colleges not having full control over the storage of their data, especially as it pertains to very sensitive student personal data (PII).We need to distinguish when we are defining a term- like Federated- or describing the feature sof the YOUnite MDM.
25
Domain UniquenessOne 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) 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.This needs a lot of work. Can't fully address all the problems with this right now
26
Deterministic UniquenessDeterministic Uniqueness is an MDM approach to detecting whether an MDR is unique for it's domain (refer to 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 than 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 Uniquenss.Sure
27
Probalistic UniquenessProbalistic Uniqueness attempts to go further than Determinstic Uniqueness in identifying duplicate transactions by assigning a priority to each of the attirbutes 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 Probalistic Uniqueness. Does MDM apply any "fuzzy" logic to evaluate how close an attribute is?
28
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 often there are times when the schema on the Source System for these entities change, 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.We may need to version at a far lower level than domain. What about field and controlled vocabulary changes?
29
Fast Duplicate Detection PropertiesFast 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 Uniqueness, Deterministic Uniqueness, Duplicates and De-Duplication for more.
30
Zone AdministratorA Zone Adminstrator is a role within MDM performed by a person responsible for the configuration of the zone(s) they are responsible for. Tasks include creating Zone Users, assigning of Permissions and creation of child zones.
31
Zone Data StewardThe 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 management Steward , assigning scopes, working with adaptor developers and implementors, managing error notifications from MDM and resolving duplicate data detected by MDM.
32
YOUnite UIAn administrative browser interface that leverages the YOUnite API for managing the ecosystem of the data hub. Provides a window for Data Steward to view the Master Data.
33
Adaptor Capabilities ListThe capabilities an Adaptor declares to the YOUnite Data Hub upon initialization that 1) link records in the underlying application/service to YOUnite Data Records (DR) 2) POST entries in the underlying application/service that link to a YOUnite Data Records (DR) 3) Manipulate data in the underlying service.
34
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 inheret the permissions for that group.
35
PayloadThe object, usually in the JSON language, that is transporeted between Adapters and the Data Hub and that carries the information assets used by the MDM porcesses and activity.
36
Passive Data ManagementProvider uses YOUnite adaptor to notify MDM of an eventDo we need this term?
37
Active Data ManagementProvider uses YOUnite API to notify MDM of an eventDo we need this term?
38
Domain TypeIdentifies 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.Need to wordsmith "data stored in a local system"
39
De-DuplicationDe-Duplication refers to the responsibility of the MDM system to identify and then either report and/or resolve duplicate Data Records (DR's). 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 Uniqueness, Determinstic Uniqueness, Probablistic Uniqueness and Fast Duplicate Detection Properties for more.This may need to clarity as the design/implementation effort is performed on de-duplication.
40
YOUnite APIA Restful application programming interface that allows developers to access administrative resources and view/modify data records under control of the YOUnite Data Hub. Per conversation with Mark, the API should be used for any business logic while the message bus is used for keeping data synchronized.
41
YOUnite EcosystemAll the components that make up the YOUnite system. This includes the Data Hub, Messaging Bus, Notification System, etc.
42
YOUnite Data HubThe scaleable web application that handles the api and message broker requests that adaptors and the YOUnite api consumers communicate through.
43
Data Record AssemblerInside YOUnite data hub. Part of router. Assembles all of the inbound data and presents a effective data record for an api consumer or adaptor based on their scope.
44
Scope ManagerInsidy YOUnite data hub. Part of router. This is what enables configuring of scope and enforces the ACL's
45
RouterThe component that is responsible for routing data throughout the ecosystem. It is comprised of the Data Record Assembler and Scope Manager.
46
Notification ManagerNotifies API consumer when events occur that they've subscribed to
47
Source Data Record or Source EntityA data record that is contained in a container such as a database table or object data store.
48
MDM RootThe root zone that is automatically created upon initialization of the YOUnite Data Hub. Along with it the Admin and Data management Steward roles are created.
49
SSO UserAny 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.
50
Access Control List (ACS)Data controls that control inbound/outbound messages
51
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.Doe sit have Queu mnagement as well? Is it a fully artuiculated Service Bus or strictly a Data Hub?
52
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, aUUID is either guaranteed to be different or is, at least, extremely likely to be different from any other UUID generated until 3400 A.D.This needs more definition
53
Community College Student Identier (CCID)Community College Student Identifer (CCID) is a code assigned to each student enrolled across CCC that is used to reference an individual student. Currently a student may enroll in multiple colleges across CCC and there is no easy way to determine whether it is the same student. With the adoption of MDM it is important to make sure MDM can apply uniqueness to students in order to ensure only one true record is maintained for any given student. The application of CCID is in process. There are still existing enrolled students who have not been assigned this unique code.
54
Model SchemaModel 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 management Steward is responsible for configuring and maintaing domain model schemas. Model Schema is way to generic
55
Preferred Zone
56
CE StudentCourse Exchange Student is a student who has been enrolled into a class at a Teaching College through the Course Exchange system. See Course Exchange, Teaching College and Home College for more.
57
Event
58
Source SystemAn application or service that is connected to the YOUnite ecosystem through a YOUnite Adaptor.
59
Data Lake
60
Data Mart
61
MDM Resources
62
Zone UserZone Users can either be systems that publish and/or subscribe to data to be shared through MDM, or Zone Users can be roles performed by either a Zone Administrators or a Zone Data Steward.Deferred at least until we identify what other users there would be besides admin and steward.
63
PolicyA Policy is made up of Permissions, Users and/or Groups of users and is assigned to a Zone. The purpose of a policy is to provide an easier way to manage the assignment of users and permissions without having to update each user with their appropriate permissions. Since most users will have the same permissions within a zone the administrator need only specifiy the exceptions after setting up the policy's for the majority. Policy's can be copied across zones for zones that the administrator has permissions to.This was deprecated in favor of Rolesmay be renamed to 'role'
64
CentralizedCentralized is an MDM model in which the data that MDM manages is stored in a central location managed by the MDM system. In a truly centralized model data identified as key data to be made available across the organization is migrated from the individual systems to a central store and local system's software is modified to point to MDM to access it. While some data may be centralized in the CCCTC MDM for the purposes of performance, CCCTC MDM is primarily a Federated MDM model.Deprecated as centralized is not planned for CCC
65
Configurable Data PolicyMDM system allows for the configuration of data rules and policy such that the clients can enforce their data management and regulations. YOUnite allows defining scopes programmatically so data can flow through the routers as data management policies dictate.
66
YOUnite Runtime StackThe 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/Scopes manages publish/subscribe actions
3. Event Notification - applications can register for change events of source data. This also includes using YOUnite as an operational data store when a YOUnite consumer requires data that it does not store itself.
67
Adaptor LayerPub/Sub, Message Bus, Adaptors, Routers
68
Data management LayerProgrammatic setting of scope
69
Notification & Data Access LayerApplications register and receive notifications of data changes. Applications can request data via MDM API that the application does not store locally.