View Source

Governance refers specifically to data governance in MDM, and that governance is exercised via Access Control Lists (ACLs) for zones.

Governance: InboundAclEntries and OutboundAclEntries

Governance is what provide visibility to data between zones and adaptors. It is typically managed by the zone's data steward and is implemented with Access Control Lists or ACLs.

ACLs are different from permissions in that they control access to data. Permissions on the other hand control who can manage zones, users, groups, permissions and roles.
ACLs are a key component of YOUnite.

ACLs control both:

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

CCC Master Data Management > Governance > adaptorsIntroDiagramScopes@4x.png

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 Access Control Lists (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

Operation	Description
PUT	When the source zone restricts the changes that occur inside the source zone from flowing outbound to destination zones.
POST	When the source zone restricts new data that is created on adaptors in the source zone from flowing outbound to destination zones.
DELETE	When the source zone restricts "deletes" that occur inside the source zone from flowing outbound to destination zones.
GET	What destination zones are restricted from using the source zone's data when assembling data.

Restrictions can be set on the following:

Entity	Description
Destination Zone	he destination zone
Adaptor	A Source Zone's adaptor(s)
DR	The union of all data for a specific DR stored on the adaptors (unless constrained to an adaptor) inside the Source Zone
Domain	The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the Source Zone that maps to a given Data Domain
DomainProperty	The union of all instances of a specific domain property stored on adaptors inside of the Source zone (unless constrained to a subset of adaptors)

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

Destination Zone → Source Adaptor → Domain → DomainProperty → DR

CCC Master Data Management > Governance > image2017-6-5_21-22-19.png

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:

ACLs	Description
ZoneX	Restrict all outbound data to ZoneX
ZoneX, AdaptorA	This would be useless since ZoneX is already restricted.
ZoneX, DR-123	Again, no need to restrict a specific data record from going to ZoneX since ZoneX is already restricted.
ZoneY, DR-123	OK
ZoneY, DR-456	OK
AdaptorB, Students.feeWaiver	Restrict the Students.feeWaiver property stored on AdaptorB from going outbound.
Students.ssn	Do not send Student.ssn out from source zone.

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.

Source of Data	Destination	Priority
Zone[1]	Zone[2]	1
Zone[1].Adaptor[x]	Zone[2]	2
Zone[1].DR[i]	Zone[2]	3
Zone[1].DR[i].DRproperty[X]	Zone[2]	4
Zone[1].Adaptor[x].DRproperty[X]	Zone[2]	5

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.

Operation	Description
PUT	When the destination zone restricts changes that occur in source zones/adaptors from flowing into the destination zone.
POST	When the destination zone restricts new data that is created in source zones from flowing into the destination zone.
DELETE	When the destination zone restricts deletes that occur in source zone/adaptors from flowing into the destination zone.
GET	What source zone/adaptors are restricted (ignored) by the destination zone when assembling data.

Entity	Description
Source Zone	The source zone of data flowing into the destination zone.
Source Adaptor	The source zone's adaptor(s).
Destination Adaptor	The destination zone's adaptor(s).
Domain	The union of all data stored on adaptors (unless constrained to a subset of adaptors) inside the zource zone that maps to a given data domain.
DomainProperty	The union of all instances of a specific domain property stored on adaptors inside the source zone (unless constrained to a subset of adaptors).
DR	The union of all data for a specific DRs stored on the adaptors (unless constrained to an adaptor) inside the source zone.

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.