Hi @BenAvdicevic, I have made some progress in this space, and I thought I'd share changes I'm making to my approach.
The layers of our data framework are:
- Domain
- Sub-domain
- Business Entity
- Data Object (instance of data in an application - these data object names include the application code)
- Physical data (we don't model this at the moment)
This diagram shows our current HOPEX object mapping.
It seems that HOPEX diagrams for Concepts are classification/hierarchy models, not meant for traditional ER modelling, hence the lack of crow's foot notation.
To solve my problem, I have (am currently) reassessed the HOPEX objects I'm using to deliver our data framework. The change here is that I am trialling the Data Entity object instead of Class (this is the level we attach data to applications and application flows). I have also introduced a "parent" Data Entity that encapsulates those application-specific Data Entities. That parent Data Entity can then be used to construct Data Diagram (I.E.) models to provide an enterprise subject areas. These differ from application data models (which we currently don't draw in HOPEX).
Although the additional layer may seem like more work, I am now able to produce meaningful logical data models.
It also seems to be lowering the required number of Concepts, as the Concept "Student" can encapsulate a number of logical Data Entities that describe a student, meaning those Data Entities would inherit the same Data Steward and have the same default Data Categories defined at the Concept level. The current inventory count of Concepts in our incomplete enterprise data model sits at about 350. I'd imagine this new approach will adjust that figure closer to 250 for the completed model.
This approach is still being worked on with Mega, but I'm liking the results so far.
Happy to discuss (and happy new year!)
Ant
