Governance refers to Data Governance in MDM.

What is Governance?

Governance describes the act of managing data access (i.e. who accesses certain data sets based on role, application, etc.).

Governance: InboundAclEntries and OutboundAclEntries

As mentioned above, governance provides visibility to data between zones and adaptors. This is typically managed by the ZDS, implemented with Access Control Lists (ACLs). ACLs are a key component of YOUnite. ACLs are different from permissions in that they control access to data. Permissions control who can manage zones, users, groups, permissions, and roles.

ACLs control both:

• Permissions on outbound data
• Controls on what inbound data a zone or adaptor should receive

ACL and Governance Example

The image below represents an example of MDM domain-related permissions and operational, outbound, and inbound ACLs (traveling left to right). Additional text below the image describes the process in addition to the embedded in-image text.

• On the diagram's left side is a source zone’s single Source Adaptor (abcd-1234) that sends data changes (data records) in its domain(s) to the router.
  • Note: A zone can have many adaptors.
• The data records sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed from the source zone’s adaptor(s) and adaptor domain(s) and are defined by the zone's DGS.
• Next, the data records from the source zone’s domains/adaptors are linked to YOUnite Data Records to avoid data record duplication. 
  • Note: The data records published by the source adaptor could be updates, deletes, or new records.
• Outbound ACLs then get applied to the source adaptor’s data records. The Outbound ACLs are defined by the source zone’s ZDS and define what data the Zone can send out (i.e .restricting data, or elements of data, of certain domains from flowing out of certain adaptors in the zone to other zones).
• After Outbound ACLs are applied the data records are published to the YOUnite Data Hub and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.
• Any destination zone that has subscribed to data records from the source zone has Inbound ACLs in place to define which data operations are allowed in the source zone and its adaptor(s). Inbound ACL is defined by the destination zone’s ZDS. Any data or operations that are configured to be ignored are filtered out. The Destination Adaptor (zyxw-9876) in the image above is shown receiving data records and/or operations it has subscribed to, as filtered by its zone’s Inbound ACL.

ACLs

ACLs can be thought of as a series of filters that get applied to a data operation.

For example, if an update (PUT or PATCH) operation is performed on data under YOUnite control, ACLs would control:

• What zones and adaptors would have visibility to the change (outbound ACLs)
• Which zones and adaptors receive (or reject) the change (inbound ACLs) e.g. a zone may be granted ACLs to a change but the ZDS for the zone may choose not to accept it.

Outbound ACLs

Outbound ACLs provide data record visibility between zones and adaptors. ACLs are a key component of MDM and are part of what is often referred to as the router.

Outbound ACLs can be thought of as permissions on out-bound data. By default, all ACLs are open. Outbound ACLs are the restrictions a Source Zone sets on a Destination Zone's:

• access to source data (GET) inside the Source Zone
• data operations (PUT, POST and DELETE) inside of the Source Zone

Restrictions can be set on the following:

Outbound ACLs are applied from left to right in the following order:

    Destination Zone → Source Adaptor → Domain → DomainProperty → DR

Example Outbound ACLs for GET

These example ACLs are combined to create the effective outbound governance for a zone. DR-XXX represents a specific data record:

After applying all of the above, the end result is:

• ZoneX gets nothing
• Zone Y is restricted from seeing the two DRs listed above
• Student.feeWaiver on AdaptorB is not shared with any other zone
• Student.ssn is never shared with another zone (for all adaptors in the outbound zone)

Out-bound data permission is controlled at various levels. See an example of the data access, below.

• At the highest prioirty level (Priority 1), Zone[1] can shut off all outbound data record changes to Zone[2]. At the lowest priority level (Prioirty 5), Zone[1] can shut off sharing a single attribute on a single adaptor (that it owns) to Zone[2].
• Sharing precedence is based on the priority e.g. If Zone[1] has turned off access to Zone[2] (Priority 1), then all other sharing actions are null.
• Permissions for each element are based on REST operations GET, PATCH, POST and DELETE. An additional operation is added for PUSH, where a zone allows another zone to receive real-time changes. However, it may be determined that GET will include PUSH.

Inbound ACLs

By default, all ACLs are open. Inbound ACLs are restrictions a Destination Zone sets on Incoming data requests (GET) and operations (DELETE, PUT, POST) from Source Zones.

Inbound ACLs are applied from left to right in the following order:

    Source Zone → Source Adaptor → Destination Adaptor → Domain → DomainProperty → DR

Operational ACLs 

Operation ACLs are not part of zone data governance but should be mentioned briefly here. By default, the DGS has permission to modify ACLs to data records (DRs) to zone users and adaptors to create new DRs. Operational ACLs control operations to the underlying DRs are granted by the DGS to Zone Users and Adaptors; typically the ZDSs.