-
Andrew… We’ve been thinking about the business use of the ontology quite a lot. As you suggested, it’s going to seem pretty esoteric to the vast majority of HE staff. Indeed, we had a bit of a running joke within the modelling team that every other day of building the Ontology brought on a existential crisis.
Where I’ve got to is that the Ontology should act as a force for conformance across the organisation, but may not often be used directly. Rather, most of the time if will exert its influence by providing structure to other artefacts (e.g. logical data models, data catalogues, low level designs etc.).
I find that in HE very often systems are designed without aligning to any business logic. For example CRM systems are designed without clear definitions of ‘customer’, mutually incompatible network models are created without common definitions. I hope that if we ensure that system design can be traced by to a common set of definitions of the data entities that the organisation manages, then it will be far easier to share and align data both within and outside of HE.
Part of this means being a little circumspect about how much detail to include in the Ontology. If we try to capture and define 1000s of data entities it will be very hard to maintain the Ontology or align with physical systems. But if we aim to capture and maintain the top ~100 data entities, and the crucial relationships sitting between them, then this should be sufficient to guide the organisation without creating crippling bureaucracy! This is also why it’s important to have clear hierarchies, not just of entities but also of relationships (e.g. what are the use cases associated with the relationships that we are mapping).
I like the sound of your capturing meta deta in your Data Lake, we’ve been debating how best to do this ourselves.