Shadow IT is a bad, bad thing. In case you're not familiar with the term, Shadow IT refers to people or even entire teams residing within the business community who have the means and the capability to create programs, procure software, or even purchase and manage IT and IT-related hardware.
One classic example that comes to mind was Wal-Mart where, the neglected Real Estate division who hadn't gotten any love from IT, decided to take matters into their own hands. Imagine the CIO's surprise when, years later, they discovered an entire AS/400 machine and a small team of developers supporting it within the Real Estate building!
Shadow IT is something we deal with within the business community where I work. It's not quite as bad as people going out and buying entire mainframe computers, but the damage is still felt, nonetheless. Here, we've got people making bad decisions about data modeling. Data modeling is one of those things that smaller companies tend to overlook. Anyone can create a table - so why do you need data modelers for that, when you've got DBAs? That's kind of like asking, why do you need engineers designing cars when you could just hire a bunch of mechanics to just keep fixing all the old cars forever. That would work, right?
Bad idea.
So, one of the pieces of data I'm trying to load this week is travel agency agents. This is a table of licensed travel agents that we've contracted with - and for every transaction they divert to us, we cut them a small amount of money. This is in addition to the commission we pay to the travel agency itself. Of course, travel agent is a child of a travel agency. But there's a problem with this. In our data warehouse, travel agency is branded - which means our two different brands are licensed to a travel agency separately. So, the same travel agency could be licensed to both brands, and we store that travel agency twice, once for each brand. This isn't that big of a deal, except that travel agents (the people who actually work at these travel agencies) aren't branded. The very idea is ludicrous, so of course, when I'm bringing this data in, and I'm trying to correlate it to the parent record - I can't, because I don't know which brand to choose.
This all points back to the root of the issue which is, at some point in time, someone - probably from the business side of the house - created a data model for travel agencies and decided to include "brand" as part of that table's primary key. Not, we're all paying the price for that. Even more frustrating, is the business has to hand-key everything in twice when they license a new travel agent, and you get data entry mistakes. So, while the travel agency names match on 95% of all the pairs, 5% of them are different - now you've got data quality mistakes based on a poor data model.
Never underestimate the power of data modeling.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment