Inmon vs. Kimball Part II: Applying the Patterns to a Complex Environment
We recently revealed how the debate between the Inmon and Kimball methodologies provided a false choice. While both methods represented significant advancements in data structure thinking for their time period, to meet the needs of today’s complex data environment, industry data models are needed to take the approaches to the next level.
Organizations across most industries use data models and consider them an integral part of business operations. For example:
- Electric utilities have the IEC Common Information Model (CIM), which Xtensible Solutions has successfully adopted for its gas and water clients.
- Telecommunications applies the Shared Information and Data (SID) model.
- Insurance uses the Association for Cooperative Operations Research and Development (ACORD) framework.
Industry frameworks exist for almost every industry and domain area, and every organization should investigate the topic areas impacting their unique activities. For example, a typical consumer-oriented electric utility would most likely seek input on the IEC CIM for electrical grid operations, a different model for customer care, and a human resources model for personnel management. The complexity of the data environment would indicate one model alone may not be enough to meet an organization’s needs.
The purpose of the industry data model is to scope out the initial entities, the attributes of those entities, and the relationships between those entities. Most models at this level are conceptual, which can be applied to any of the layers noted in Figure 1.
Figure 1 – Complex Reference Architecture
The conceptual models will naturally influence the structure of a normalized physical data model and NoSQL document, or data in motion through the creation of XSD or JSON. The models could also impact the development of data marts, and even the servicing of data for third party partners. At this point, the conceptual model has not indicated data storage should be created, but rather the beginning constructs for the creation of data storage or data in motion. An organization can use the Inmon and Kimball approaches to influence how both the data ecosystem and data warehouse are created.
Applying Kimball’s methodology
Creating the complex reference architecture should start with the immediate business questions and needs. As irrelevant data is discovered along the way, it can be classified and initially reconciled – or, at the very least – categorized. The conceptual data model makes this possible by providing definitions which can be used to match the discovered data.
The data won’t necessarily be used, but it can be recorded and potentially captured as a source to process later, as new business questions arise. The complex reference architecture found in Figure 1 would still be built out using those questions. In this example, the customer billing address could be captured in an address structure as part of the customer set-up process. The customer service location address could also be captured as part of a work management process. An organization may even be able to uncover that the customer billing address and customer service location address are the same and can be managed using a sub-process involving the consumption of U.S. Postal Service data. This type of process-centric approach can still leverage the commonalities, incorporate process efficiencies and show how the data is processed in the ecosystem, as indicated in Figure 1.
Inmon in action
The Inmon approach still starts from an enterprise, or an information topic. The conceptual information model allows each application, business unit, or business partner to contribute data incrementally against a known structure. This doesn’t mean the conceptual data structure wouldn’t be extended, but that the data could be managed and added incrementally. An organization could take U.S. Postal Service address information, customer billing address from an internal system, and service location information from a second internal system, and correlate them together using the industry standard definition of the location. The enterprise could then make a decision as to where this will be stored in the complex reference architecture found in Figure 1. (For more on this, refer to part one of this series.)
The end results
Instead of the project premise being discovery – such as defining and refining the process or topic area – and then the development and implementation of the conceptual model, the process becomes one of discovery, and extending the conceptual model as needed, and implementing or extending already implemented physical models. This can be done in any of the complex reference architecture target areas noted. Using the existing conceptual model to support the breaking up of activities is a gamechanger.
For a Kimball, or process-oriented methodology, the question is not “what needs to be in an address?” but instead, “we have an address construct—does it already support our process, or what modifications are needed?”
For an Inmon, or enterprise data perspective, the question ceases to be “how do we define our address data structure?” and becomes “what are all the sources of address data, and how do we want to reconcile them?” The presence of a conceptual data model supporting multiple physicalizations can entirely alter the fundamentals of the process.
A step even further
The presence of a conceptual data model allows an organization to use a hybrid Inmon-Kimball philosophy for data management and storage. Very few project or information architectures strictly adhere to only a bottom-up or top-down approach. Sometimes, a project starts with a bottom-up approach and then turns into an enterprise top-down program through corporate acceptance by key stakeholders. Using a conceptual data model helps ensure data definitions aren’t limited to one governance approach and that development activities can support shorter cycles to further organizational capabilities.Back To Blog