Top Ten Best Practices for Data Integration
Use these guidelines to help you achieve more modern, high-value and diverse uses of DI tools and techniques.
I've been debating for some time now whether or not it's appropriate to talk about data models. Data modeling is getting more attention in the trade press these days as a means of delivering business value, and yet, it's just so ... techie.
I stepped in that mess with SOA, advocating that IT talk with the business about service-oriented architecture. I contended they could understand it, and, in fact, you <em>should</em> explain SOA to them - after all, it's strategic, right? And if I - a simple English BA - could understand how it contributed to the business, why not the business user?
Boy, was I wrong on that one. What I neglected to consider is why anyone outside of IT would really care to understand it. And sure enough, as Anne Thomas Manes of the Burton Group pointed out, it wilted on the vine as a business topic, although it's thriving today as a practice.
Well, first, what is a data model? Well, the name tells you a good bit - like any model, a data model seeks to be a standard for imitation or comparison - a representation in miniature form of what you will eventually build or have built. Think of it as a flow chart or blueprint, if you prefer, for putting data in the database.
Sounds pretty techie, doesn't it? And it is, but here's why data models matter to the business: A data model is where the translation begins between IT's databases and business' goals - a data Rosetta Stone that attempts to say the same thing in both IT and business.
It's actually a critical part of integration, particularly if you want to be smart and business-savvy about it. <span>Jill Dyche explained</span> <span>how a data model can help and how IT can better engage the business in data integration</span>:
... the unit of integration is not the data warehouse. The unit of integration is the data model, so the right thing to do is translate those requirements into data requirements that you then update the data model with. The data model is what actually links all that information in the business-driven way so you understand the relationships between data, so you understand the relationships between customers and products.
It's also a key part of enterprise data management, which in turn "promotes better data integration and project coordination while reducing project risks," according to a recent Information Management article.
"Enhanced communication and increased confidence in the IT organization are crucial to meeting business needs, especially those imposed by external sources," the article notes. "Reduced cost and faster response to change are natural products of taking an enterprise approach to data management."
The article focuses on data models, contending they are a key corporate asset and as such, should be seen as "corporate assets to be managed by a partnership of modelers and the business." The article then warns, "If they are portrayed as just technical specifications that can be understood only by developers and database administrators, they will not provide the benefits of an enterprise data architecture."
The article identifies seven mistakes organizations make with data models, but pretty much all seven boil down to two themes:
That sounds great, but will it pass the "eyes glazing over" test? I doubt it. So while it may be true to say the data model is useful to business users, I'm not sure they'll be willing to bother ... at least, not if IT talks about data models in the way it wants to talk about it with words like "data model," "tables," "databases" and other techno-terms.
"There's a lot of technical people that love to preach the data modeling gospel to business users," Dyche said. "Business users don't care; they just want to be able to analyze their campaigns. So it's about the what and not the how."
So what should you do? Remember the first rule of "Fight Club": Don't talk about Fight Club. Likewise, let the first rule of the data model be that you don't talk about the data model - at least, not as you would among your technology cohorts.
"I don't actually talk to business people about data models," Dyche said. "I'll talk to business people about data requirements. 'Your business requirement is you want to track the profitability of your campaigns and promotions for the last year, that's a great business requirement. What data is necessary to do that? So you need customer data, you need profitability data, you need promotion data, you need product data. Okay, so those are your data requirements.'
"Now in the back room we go and we say, 'Okay, here are the data requirements, let's model these so we understand the relationships between them,' and we can come up with these logical constructs that will form the basis for the physical tables on the data warehouse."
So my advice? Share the data model, certainly. Share the metadata, absolutely. Just be sure to translate it into business-speak first. If the experts are right, it could immensely simplify your integration projects.