Thanks for a very clear and good answer, @markbodman .

It is actually the devops teams that are delivering Master Data as a Service that have brought up this question. For instance the Supplier Master Hub that delivers data both to TPRM, S2P, Accounting, ESG, CRM, ERP, etc. They have a data model describing how the information objects they provide should be used and understood. For example, some information objects within the Supplier Master data model, such as the Third Party contact, belong to the PII data domain, whereas the Supplier Carbon Footprint score belong to the ESG Data Domain. There's also a relationship, maybe even many, between these information object which they need to describe. This is done in relation to what they call their "Data Products". In other words, using just the Data Domains as an entity will not solve all of their needs. So I have trouble dedicating ownership to the Supplier Master as a Data model without something to pin it to. Of course, they deliver a set of service offerings, basically in the shape of various APIs and API scopes one may subscribe to, but if the data model itself were to change, this would also impact the usage of those. 

The Common Service Data Model is another good example. In version 5 a set of new artifacts turn up, such as the Value stream. Then I need to create descriptions on what to put in the value stream table, what it is for, and what columns we are currently using. We may also need to add some norms around the governance of the records in this table, like we have done for BusApps, BusCaps, etc. Should the understanding of a Value stream change in the future, this needs to be versioned. 

The catalog items that could be related to a Data Product Model as you suggest, can in our case either be solved by the new Digital Integration Management solution, and be catalog items under each service offering we have for our BusApps. Or: ensuring that all those who subscribe to APIs on the previous Data Product Model version are notified when there is a change, and to let them stay on the old version until they are ready to move to the next, could be a good use case for having data product model-based catalog items for those API-types of service offerings. 

I do dread the user adoption side of introducing Data as a Product, as well as Data as Assets, but at the same time I want to be able to provide something that makes sense to these highly specialised, highly skilled architects who knock on my door. So I think we will give it a try ;-). 

Cheers,

Kristine