Our data models, in reflecting a specific business, must accurately portray the essence of each business. The unique reality within each organization drives the shape of every data model. The logical meaning of each data element originates with what is actually done and how it is accomplished within that particular organization.
How a function or task is accomplished, by other organizations or individuals, is fairly meaningless in a data modeling context. The idea of an industry data model, or a business function data model, is only useful in providing a fuzzy outline from which to start. Standardized data models that may be purchased off-the-shelf are not useful as a finished product for a business to consume. Using such a standardized approach would be the same as trying to define an individual person by listing group-based statistics, or stocking a clothing store based solely on a population’s average size. Defining things at that statistical/averaging level leaves a wide range of uncertainty about the resulting applicability to any specific individual person. Therefore, applying a standard model to a given business leaves many rough edges that do not fit comfortably. Solution vendors attempt to account for some of this roughness via generic-thing/type expansions within their off-the-shelf tools that certainly attempt to help, but at a fairly significant maintenance cost.
Data modeling is a semantic process, focused on finding the meaning of the important objects and transformations within an organization, and the information systems supporting that organization, or a specific sub-area within the organization. This acquired understanding is then applied by designing a specific solution-area-focused database model, generally using a form of entity-relationship diagramming. Precise data modeling efforts will be influenced by such concepts as linguistic anthropology, sociolinguistics, or pragmatics, even when the data modeler may not consciously invoke explicit “ology-derived” checklists.
As people enter their work environment, they learn to engage in code-switching, as their speech flips back and forth between their usual language and the unique language of the business. The only visible sign of this may be if people are told to “not use company terms” when speaking with customers or acquaintances outside of work. People experience it every day as they navigate a veritable landscape of organizational-unique three-letter acronyms. A data modeler must learn this organizational dialect in order to probe the various rabbit holes that allow for a developed data model to truly capture the spirit and direction of the business.
Just like any language group, even within common business functions or common industries, new organizational-delineated dialects arise. We are influenced by the language we use, and the language is influenced by us. Influxes of new employees from various cultures or past experiences will drive change within the organizational dialect. Terms and even operational approaches to mundane tasks will vary. And as they diverge, the data models that might express the same solution area across organizations will become more distinctive to each business. Adding further fuel to the fire of change, IT-implementations can be so semantically forceful that their usage drives yet more linguistic change. And occasionally, when the semantics of those solutions are off-base, they end up creating more chaos, or even organizational cognitive dissonance. Despite all of the semantic variety and conceptual diversity that is clearly on display within every organization, time and again, people attempt to approach data modeling as if the world were one-size-fits-all. Perhaps it is through hubris, or simply through very narrow perceptions, these one-sizers truly believe that each industry and business function should map to a single model of objective truth. It is said that what one sees is based on where one looks. Opening one’s eyes to the world around can be very mind-expanding; please take an opportunity to do so.