We don't have a "standard" naming of our data terms objects per se. But it does follow a structure. From an architectural and data governance perspective, we identify the "subject areas" of our industry and have established those as our initial primary data domains...we go from broad to more specific as the need arises.
We have a tool we use for Architectural relationships (LEANix), that allows us to link together the relationships between applications, integrations, data objects, business capabilities, technologies, suppliers, user groups and projects. It IS a metadata tool - though unfortunately it doesn't go down to the level of database/schema/tables or fields
For the data objects we start with the high level name of what could be collected as a subject area..first focusing on master data: eg. Groups, Members, Providers, Claims, Vendors, Product, Benefits, Workers, Reference Data, then focusing on transactional - eg. Claims, Clinical, Finance, HR, Sales, Service.
THEN we break those down as required... eg: Member/Demographic, Member/Eligibility, Provider/Demographic, Provider Credentials, Claims/Medical, Claims/Medical/Commerical, Claims/Medical/Medicare, Claims/Prescription, Claims/Dental, Claims/Vision.
Much of what drives the expansion of these objects are either -
- the need to capture who is responsible for what in the company (for DG purposes),
- the need to identify high level contents of integrations or applications.
Though we have thousands of business terms defined in our glossary (Informatica's "original" business glossary... not a fan), our data objects currently only have about 250 objects - which is enough to describe the high level contents of over 2000 applications and 2100 integrations.
One of my goals is to eventually be able to link the data objects to a true data focused metadata repository or data catalog.