Promoting Standards With Data Model Templates

by Donna Burbank
July 8, 2008

Inconsistent Models

Let’s assume you have both a banking account and a credit card with a particular financial institution. You would think you can easily receive all your records on a single statement. But no! You receive a bank statement addressed to Jane W. Doe and a separate credit card statement addressed to Jane Doe. How can they not know you’re the same person? While there are many organizational issues that may lead to this mix-up (e.g., disjointed processes, employee error, and lack of communication), a common problem lies in the data model(s) used. Because the credit branch and banking branch each created their own “customer data entity,” there was no standard way for them to track your customer information. The banking “customer data entity” might be designed as shown in Figure 1 and the credit version might look like Figure 2.





The banking model contains a middle initial field; the credit model doesn’t. Seems like a harmless difference, but it can cause your banking and credit records not to be matched correctly, resulting in two statements. To a large financial institution, such errors can’t be found with a simple glance. Instead, they’re forced to “clean up the mess” with extensive data integration and master data management strategies involving analysis of both the data and structure of the data (metadata). These problems could be avoided by starting with a clean, consistently designed model.

We’ve seen how differences in data model structures can cause harmful results. What if the data definition is incorrect? Again, such standardization sounds boring, but another example brings it closer to home. You’ve probably received a credit card application from a company with which you already have a credit card. Again, there are many organizational reasons that might cause this, but one core reason lies in mixed definitions of customer. To sales and marketing, a customer is someone to whom you market; the person currently doesn’t own the product and you’re trying to convince them to buy it. To accounting and finance, a customer is someone who has already purchased a product and is an existing customer. Mixing these definitions into a single entity can cause an existing customer to be treated as a prospective sale, resulting in your receiving both a statement and a marketing pitch.

Unique and Universal

Many developers balk at the prospect of standard templates, thinking their organization or use-case is too unique to fit a boilerplate pattern. While it’s true that each organization has unique data attributes specific to a particular industry or function, there are common attributes across most industries, such as name and address.