The importance of data integration, whether for analytics, mergers/acquisitions, outsourcing arrangements, third party interfaces, etc., is easy to understand but extremely difficult to realize. The technical aspect of data integration is the (relatively) easy part. The hardest part is bridging the semantic divide and agreeing on business rules – i.e., communication. The Conceptual Data Model can be an invaluable tool to help bridge the gap.
A Conceptual Data Model is a technology, application, and (usually) business unit neutral view of key business objects (data entities) and their relationships, and should be the framework for information systems. It is a business model, from a business object perspective, where we’re identifying what data is of interest to the business rather than how the data is used. It is not a process model, and is stateless in nature (all states of a relationship must be expressed to provide a longitudinal perspective). Relationships can express many business rules. A Conceptual Data Model typically takes the form of an ERD, UML Class Diagram, or ORM diagram.
The Conceptual Data Model provides a framework for information systems. However, in order to craft the framework the Enterprise Data Architect and/or Data Modeler must meet with and understand the business. You wouldn’t hire a housing architect to design a model for you without meeting with you and coming to alignment before proceeding to laying the foundation and framing the house, and similarly you shouldn’t build your information system before you have the conceptual data model in place.
After the housing architect meets with the customer and develops the model, he or she meets with the customer to review and fine tune the model. After the data architect or modeler crafts the model he or she must review it with the business. The amount of effort and time required making the models presentable and understandable by the business should not be underestimated, as you want the business to sign off:
- Names – Do the names of entities resonate with the business and does the business agree to the proposed standard name? Be sure to identify synonyms and homonyms to provide context to the business.
- Definitions – Do the entity definitions conform to business understanding for the term / entity name?
- Relationships – Are the relationships at the right level of granularity (e.g., does an entity relate to the claim header or to the claim line)? Is the business rule expressed via cardinality and optionality reflecting business reality over time (rather than at a specific state)?
I like to present my models to the business using a PowerPoint slide deck. This is harder and more time consuming for the modeler, but easier to present and easier for the business to focus on. Focus on a small set of entities and relationships in a single slide (the rule of 7 +/- 2 works here). I export definition and relationship metadata onto separate slides. It is very important to write out the relationships in a formal sentence. Why?
- It removes the risk of business people getting confused or turned off by the notation
- It is much easier to get the business to review and approve the relationship
- It acts as a quality check for your modeling (often having to write out the relationships uncovers oversights when modeling)
Once you have your Conceptual Data Mode,l i.e., Information Framework, you are ready to build upon that framework. Whether you’re building an internal data warehouse, preparing for a merger or acquisition, or have other integration needs, you can be more confident that you understand much more of the business and so integration can go off more smoothly.
