Transaction Hub
UTA Authoritative Data is designed to use a transaction hub implementation style[1], wherein the database can be considered to be the definitive system of record (with the exception of :Employee parties). All writes to authoritative data must flow top-down through the "hub" and all downstream systems, including finance systems, are read-only and must query the authoritative data service for the latest information.
This hub is exposed to other downstream systems as the ADM Service.
The transaction hub implementation style allows us to deliver up-to-date data to downstream systems, as well as a single governance point for the data management office to steward incoming data.
This implementation style does not mean that downstream systems must always query the API in real-time. Some downstream systems may need to store local copies of read-only authoritative data. To implement this, a one-way integration would be created for the downstream system which "pulls" authoritative data on whatever schedule makes sense.
Implications for UTA downstream systems
UTA authoritative data is the system of record and must govern the relevant data used in all downstream systems.
All downstream systems must not create authoritative data (clients, buyers, etc) locally, but instead use the authoritative data service APIs, thus ensuring routing through the hub.
For downstream systems that already exist, such as NetSuite or Salesforce, this choice likely means a change of workflow and procedure for some users, as well as a authoritative data integration project executed by the technology team. We do not mean to ignore the trade-offs of this approach: it will be challenging to get buy-in from, for example, a Salesforce user when they are told they cannot simply "create a client" directly in Salesforce. But this is an essential change which will allow UTA to create an always up-to-date system of record.
Our approach is influenced by the practices as described in Enterprise Master Data Management. Refer to table 1.2. ↩︎