I believe this forum is the correct one for my question, based on the community guidelines but let me know if not. It seemed like the best fit.
I am performing a data modeling exercise to formulate a conceptual model of our business to support our requirements. An obvious step is discovering the entities.
My challenge is deciding if some of the concepts that exist in our existing tools are entities in their own right, and if they are, should we make a distinction between them. Or are they simply implementation details.
- An old fashioned newspaper would likely have entities like Publication, Article, Advert, Editor, Writer, Copy, Photograph etc etc.
- Now 50 years ago the technology to print those things would have included things like a matrix and castings
- Today perhaps it's a different technology with master plates
My question is are these implementation things (magazines and castings, or master plates depending on when you did the exercise) true entities or not?
They're clearly conceptual things. But they are also implementation details that can and will change over time (whereas articles and adverts are stable entities)
Our problem space is content management, and so the question becomes are implementation "things" in the CMS (like a "copy-asset") entities in the same way that webpages and footnotes are? Clearly if we replace the CMS those things won't exist anymore, but we'll still have webpages and footnotes!
---------- Additional Edits adding more context based on provided answers -----------
As mentioned context is key so adding additional detail to respond to some of the thoughtfully provided answers below.
- The problem space is a content management software for publications.
- There is a preexisting custom built (and dated) legacy system that does little to abstract the technical implementation from the users (content managers). For instance there is no concept of "Article" in the CMS, but there are things like "copy_asset", "document_segment", and "document" (which go as far as surfacing keys to the users) that the users must piece together together to form an article, or an advert, or an... etc etc
- We are planning to replace the existing CMS as it's overly complicated (people spend more time working around the nuances of the tool than actually managing content), inefficient and error prone.
- As part of our initial analysis we are modeling the existing workflow and "What" is done (free of "Who" and "How").
- Subsequent modeling will then identify "Who" and "How" those processes are performed today. Which we'll analyze before moving on to designing the future desired state.
- To support that workflow modeling exercise we are working towards identifying the data model related to this work (not written down anywhere today)
- And now to the question. And where I'm going back and forth. If we were to simply come up with a Conceptual Model from scratch based on "What" the business does (which in my mind reflects the entities that are truly important to the business) I wouldn't expect to see entities like "copy_asset", or "document_segment" as they are implementation details that this particular CMS happens to surface to the users. For instance if we happened to use a different CMS they would definitely not appear. But when we ask the users "What are the things you work with" then of course they raised these. And of course the things they implement, like "Article", "Advert", "Headline", "Byline" etc were raised as well.
- Essentially our (legacy) Physical Model — which was created years ago — does not align very well with the Conceptual Model of what the business does (hence why the tool is complicated to use)
- So the question becomes should we exclude these technical elements ("copy_asset", "document_segment") from our Conceptual Model? Which will then high-light the discrepancy between Conceptual and Physical model which we'll need to address.
- Or perhaps I'm overcomplicating this and I should just create the AS-IS data model and then, as with the workflows, come up with a "TO-BE" data model with entities that better reflect the true work that is done.