The Kalido business model is central to our core technology. Model-driven automation facilitated by the Kalido Information Engine manages data sourcing, business rules validation, data integration, physical storage and presentation for both master data and warehouse instances.
It is no secret that an effective and robust business model will have direct influence on the success of an implementation. In our advanced modeling course, we cover several key tenets that should apply to every business model:
- Reflect the true nature of the business and the relationships between contributing components
- Provide business understanding beyond the development community
- Allow easy additions of new business concepts
- Be reusable
- Support multiple views of the business
- Permit changes of sources without significant changes to the core model
- Allow production of new reporting views, using existing data, without significant changes to the core
As part of these principles, we also have to consider the balance between modeling generically versus being more specific or verbose. Generic models tend to be more robust but lose business meaning when compared to a more verbose approach. So when making modeling decisions, we have to consider the audience. Quite often various data consumers within an organization view business context and activities quite differently than other areas of the company. For example, a collections department within a retail bank evaluates customer and accounts quite differently than the marketing team. In pharmaceutical sales, long-term care sales reps are more interested in a prescriber’s activities within a nursing home than for the same prescriber within a primary care setting.
The challenge is that our business models must not only cater to a harmonized view of the business, but also we have to consider multiple audiences. In addition, it is also not unusual for an audience to reference operational systems as part of the business rules discussion. To address this requirement, we have to retain supporting information based on origin; in other words, explicitly capture the context within the operational systems.
To illustrate, let’s continue with our retail banking example and consider four operational systems for checking, credit cards, personal loans and investments; where each system has its own record of customer. We can harmonize data from all four systems to produce a single “golden record” for customer with the most current address, etc. The problem is that the single address along with other harmonized attributes and associations may not satisfy all end-users of the data. More realistic scenarios might include:
- The marketing team must identify customers within a certain demographic based on the most recent customer address
- Risk analysts want to evaluate customer attributes captured at loan origination
- The collections team must consider all available addresses in order to locate a customer
Again, the underlying challenge is that source priority and/or harmonization rules may not be the same for all groups of data consumers — we have to consider the audience.
So with that challenge, how do we capture these requirements in a business model? The most effective approach we have found is to establish three reference (or context) layers within the model:
- Source Layer: Classes of Business Entities (CBEs) in this layer hold reference data from operational systems and/or external data sources. An example might be “CRM Customer,” “Credit Card Account” or perhaps in the case of external data, “Nielson Product”. Note that you would normally expect transactions to be associated to CBEs in this layer.
- Harmonized Layer: This layer will contain the global or conformed view of our reference data. Think of a typical hierarchy, the further up the hierarchy, reference information becomes more general and less specific. Also note that in a three-layered model, associations become much more important so the objects in this layer tend to focus more on name and a set of identifiers.
- Consumer Specific Layer: This layer provides an audience-specific view of the company’s reference data. These audience members have very specific rules for harmonization/integration and the objects should be quite verbose. A representative CBE at this level might be “Collections Customer” or “Promotion Candidate”.
This approach has been quite effective in terms of both implementation and reporting. There are some concerns regarding redundancy and storage inefficiencies but some of that can be offset using modeling structures such as supertype/subtypes, etc. Regardless, any additional cost is usually offset when compared to the benefits of providing a more-representative view of the business.
In summary, adopting these three layers to our business models embraces several of the core principles listed earlier. This approach not only supports multiple views of the business and provides better business understanding, it enables faster sources updates and additions without disturbing the core model. Plus we have the side-benefit of additional transparency for the underlying data along with the capture of associations across layers — all of which is more representative of the business.