Governance

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...
referenceswhere the Master Data is stored
providesvisibility to data between zones and adaptors
contains
  • policies that get applied by the Data Governance Steward (DGS) as regards to the data taxonomy of the tenant
  • data content managed by the Zone Data Steward, who is designated by the DGS to:
    • ensure their zone's data accuracy
    • provide domain modeling input to the DGS
    • assign Access Control Lists (ACLs) and zone access
    • works with adaptor developers and implementors
    • manages error notifications from MDM, and,
    • resolves duplicate data detected by MDM

ACLs and ACL Chains

 ACLs are a key component of YOUnite and are different from permissions in that they control where data flows through the system. Permissions control who can manage zones, users, groups, permissions, and roles.

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 MDM ecosystem.

ACLs

An access control list, or ACL, is a list of properties that when combined, create a policy that controls data flow between zones and adaptors. The list of ACL properties includes:

  • Source Zone - The zone the data originated from
    • Source Adaptor - The adaptor the data originated from
  • Destination Zone - The zone the data is flowing to
    • Destination Adaptor - The adaptor the data is flowing to
  • Domain Version - The data domain the ACL applies to
    • Domain Version Properties - One or more properties in the data domain that are applied to the ACL
  • Data Records - One or more data records that are applied to the ACL
  • Allow/Deny settings for an ACL control which operations are either allowed or denied:
    • GET
    • PUT
    • POST
    • DELETE

Data events in YOUnite parallel the HTTP requests GET, PUT, POST and DELETE.

Not all ACL types use all of the ACL properties.

ACL Chains

ACLs are linked together to form ACL chains. They behave similar to network firewall chains but apply to an organizations data entities linked to YOUnite. When a data event occurs to a source entity, the change is transmitted to the YOUnite Router and the appropriate ACL chains are consulted and data is propagated (allowed) or restricted based on the ACLs in the ACL chains. Care must be taken to order the ACLs on a chain properly since the first ACL match is applied to a data event.

Types of ACLs

There are three types of ACLs:

  • Inbound ACLs
  • Outbound ACLs
  • Operational ACLs

Each zone has both an inbound and outbound ACL chain which are controlled by the zone data steward.

Operational ACLs control which zones can create or delete a federated data record for a specific domain version. Operational ACLs are controlled by the Data Governance Steward.

Outbound ACLs

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

OperationData Event Description
PUTWhen the source zone allows or restricts the changes that occur inside the source zone from flowing outbound to destination zones.
POSTWhen the source zone allows or restricts new data that is created on adaptors in the source zone from flowing outbound to destination zones.

DELETE

When the source zone allows or restricts "deletes" that occur inside the source zone from flowing outbound to destination zones.
GETWhat destination zones are allowed or restricted from using the source zone's data when assembling data.


Polices can be set on the following:

EntityDescriptionDefault Value
Source AdaptorThe adaptor in the source zone where the data event originates.ALL
Destination ZoneThe destination zone where the data event can be delivered (i.e. it has adaptors that are capable of handling the event)ALL
AdaptorAn adaptor in the destination zone capable of handling the data event.ALL
Domain VersionThe data associated with a data event will contain data that belongs to one or more domain versions. ALL
DROne or more federated data records that belong to the Domain VersionALL
Domain VersionData events contain a federated data records that belong to one or more Domain Versions.ALL
Domain Version PropertyThe union of all instances of a specific domain property stored on adaptors inside of the Source zone (unless constrained to a subset of adaptors)ALL
Allow GET / Restrict GETAllow or restrict GET data events.neither is set
Allow PUT / Restrict PUTAllow or restrict PUT data events.neither is set
Allow POST / Restrict POSTAllow or restrict POST data events.neither is set
Allow DELETE / Restrict DELETEAllow or restrict DELETE data events.neither is set


Inbound ACLs

Inbound ACLs can be thought of as policies on in-bound data. By default, all ACLs are open. Inbound ACLs are the controls a Destination Zone sets on Incoming data requests from Source Zones:

OperationData Event Description
PUTWhen the destination zone allows or restricts changes that occur in source zones/adaptors from flowing into the destination zone.
POSTWhen the destination zone allows or restricts new data that is created in source zones from flowing into the destination zone.
DELETEWhen the destination zone allows or restricts deletes that occur in source zone/adaptors from flowing into the destination zone.
GETWhat source zone/adaptors are allowed or restricted (ignored) by the destination zone when assembling data.

Policies can be set on the following - the zone data steward in the destination zone, creates the ACL on behalf of the destination zone:

EntityDescriptionDefault Value
Source ZoneThe originating source zone.ALL
Source AdaptorThe originating source zone's adaptor(s).ALL
Destination AdaptorThe data associated with a data event will contain data that belongs to one or more domain versions. ALL
Domain VersionThe 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.ALL
Domain Version Property

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)

ALL
DROne or more federated data records that belong to the Domain Version.ALL
Allow GET / Restrict GETAllow or restrict GET data events.neither is set
Allow PUT / Restrict PUTAllow or restrict PUT data events.neither is set
Allow POST / Restrict POSTAllow or restrict POST data events.neither is set
Allow DELETE / Restrict DELETEAllow or restrict DELETE data events.neither is set


Operational ACLs 

Operation ACLs are not part of zone data governance. Operational ACLs set policies that set forth for a given data domain version:

  • What zone can or can't  POST or DELETE  data records (DRs). 
  • What adaptors or can't  POST or DELETE  data records (DRs).

There is a single system-wide chain for Operational ACLs that is controlled by the DGS.  By default all zones and adaptors can POST and DELETE data records but POST and DELETE polices for data records can be controlled by the DGS.

Operational ACL policies can be on the following:

EntityDescription
Domain VersionThe domain version an operational ACL applies to.

Source Zone

The zone that is allowed to or, restricted from POSTing a data record (DR).
Source AdaptorThe adaptor that is allowed to or, restricted from POSTing a data record (DR).
Allow POST / Restrict POSTAllow or restrict the source zone or adaptor from creating a data record for the given domain version.
Allow DELETE / Restrict DELETEAllow or restrict the source zone or adaptor from deleting a data record for the given domain version.

ACLs Illustrated

A very simple example it illustrate this point:

  • There are three zones: Zone-X, Zone-Y and Zone-Z each with two adaptors. All adaptors are capable of storing/retrieving data entries for the Customer domain
  • Zone-X has the following Outbound ACL Chain

Source ZoneDestination ZoneDestination AdaptorDomain VersionPolicy
1Zone-XZone-YALLALLALLOW ALL 
2Zone-XALLALLALLRESTRICT ALL 

ALL = GET, PUT, POST, DELETE

  1. A Customer PUT data event is raised on adaptor1 in Zone-X
  2. YOUnite can see that the adaptors in ZoneY and ZoneZ are all capable of consuming this data event
    1. YOUnite attempts to route the data event to Zone-Y
      1. YOUnite inspects Zone-X's outbound ACL chain and gets a match on the first ACL in the chain and routes the  event to the two adaptors in Zone-Y
    2. YOUnite attempts to route the data event to Zone-Z
      1. The first ACL does not match but the second does restricting the event, so the data event is NOT routed to Zone-Z


Following is more involved example using the zones and adaptors from above. ACLs are evaluated from first to last, the first match is applied to an incoming data event:


Source ZoneSource AdaptorDestination ZoneDestination AdaptorDomain VersionData RecordsPolicyNotes
1Zone-XALLZone-YALLALLALLRESTRICT ALL

Restricts all outbound data events to Zone-Y

2Zone-XALLZone-YAdaptor1ALLALLRESTRICT ALLThis ACL is useless since ACL #1 already restrict all events to Zone-Y
3Zone-XALLZone-ZALLCustomer v1DR-123, DR-456RESTRICT ALLRestricts the data records (DR-123 and DR-456) from going to Zone-Z.
4Zone-XAdaptor2ALLALLALLALLRESTRICT ALLRestricts data events from flowing out of Zone-X's adaptor2 to all zones.
5Zone-XALLALLALLCustomer v1Customer.ssnRESTRICT ALLRestricts a customer's SSN from flowing out of of Zone-X.
6Zone-XALLALLALLALLALLALLOW ALLAllow everything else out i.e. if a data event can be delivered to many adaptors in the YOUnite ecosystem it will be delivered to all adaptors except for the restrictions placed by the above ACLs. ALLOW ALL is the default so in reality, this ACL is unnecessary. 

ALL = GET, PUT, POST, DELETE

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

  • Zone-Y gets nothing
  • Zone-Z is restricted from seeing the two DRs listed above
  • No data from Zone-X's Adaptor2 flows to any zones or adaptors
  • Zone-X never shares the Customer version 1 Domain property Customer.ssn  (for all adaptors in the outbound zones)

Complete ACL Data Flow Illustration

The image below represents the components involved as a data event is detected at an adaptor and flows through the YOUnite ecosystem.


  • On the diagram's left side a source zone’s single Source Adaptor (Zone-X, Adaptor 1) detects a data event in the source system (ERP) and sends a data event (data record for a given domain version)  to the router.
  • The data record sent from the source adaptor to the router have Operational ACL applied to them. Operational ACL limits which data operations are allowed (create/delete YOUnite Data Records)  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 record (Zone-X, Adaptor 1). 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).
  • Destination zones have Inbound ACLs in place to define which data operations are allowed from source zones and their adaptor(s). Inbound ACL is defined by the destination zone’s ZDS. Any data or operations that are configured to be restricted are filtered out. 
  • After Outbound ACLs are applied the data records are published to the YOUnite Data Hub Router and subscribing/desitnation zones and their adaptors (on the diagram's right side) are notified of the updated data.