Hi I’m Jared Hillam, Imagine that you’re designing a new home
and that a plumbing sales rep tells you that he has a packaged plumbing design for 2 story
homes which will reduce the cost of architecting the plumbing into your future house.
You think to yourself, “well I’m not the first person to build a house, and this sounds
like it might save some money.”
So you go ahead and move forward with the idea.
So you build your house with the packaged design and to your absolute dismay the packaged
design is not for your house layout but just that of a generic 2 story home!
So you have pipes going right through the middle of your living room and other places
in the house!
Worse yet the bathroom doesn’t even get any plumbing!
OK…
I’ve made this example as extreme and obvious as possible.
But I’ve done that so I can introduce you to its equivalent in the data integration
space called Packaged Data Models.
OK first let’s talk about what a data model is.
A data model represents the framework of what the relationships are within a database.
This framework in the world of data warehousing is a critical component as it will provide
the structure which will support the analytical needs of the decision makers.
The data itself will literally be stored within this framework on a database.
So building a data model is a critical step in the design of the data warehouse.
This step requires your business people to engage in the process by participating in
facilitated sessions with our data architects.
This can seem intimidating for organizations to take on, so often organizations start looking
for something out of the box.
But here’s the kicker that most people don’t realize.
The amount of effort that you would take in vetting a packaged data model to ensure that
it fits your business; is nearly the same level of effort to go ahead and design one
specifically for your business.
However, this is an easy trap to fall into because data models appear to do more than
they actually do.
Especially to business people.
The first thing to understand is that a data model is just a shell.
A Data Model without populated data isn’t much more than a drawing.
The real expense and heavy lifting in a data warehouse project is not in the design of
the model, but rather populating that model with data from your source systems.
And that is where the big money is spent to create a Data Warehouse.
Now some organizations don’t even vet packaged data models, assuming they are well positioned
out of the box.
But they’re usually in for a huge shock once all the reporting and analytics go live.
They often find that the logic does not mirror their internal practices and rules.
Additionally, they find entire dimensions not being represented.
Like our example with the home, fixing the problem is an expensive rip and replace process
because the entire house around the pipes is already built.
The same is true for a data warehouse.
The ETL, Staging, Data Model, and Reports are all in place and now need a major rebuild.
If you are going to use a packaged data model, at the very least, you should vet it completely
before deploying it in your business.
Rather than thinking of the packaged data model as the end game you’re better off
thinking of it as a guide while you design your own data warehouse.
This is because you’re likely to have a lot of deviations from what the vendor would
consider as “standard”.
And it also enables you to build in your competitive advantage above and beyond your competitors
analytics.
Intricity has extensive experience in the packaged data model space.
We have modified, implemented, replaced, and designed such models for years.
We can help you determine what the right approach is when implementing a data model.
I recommend you visit our website and talk with one of our specialists.
The small investment in our guidance can bring you huge dividends for the future of your
project.