Stop Proliferating ODSs

Everyone knows about the rise and fall of data marts: Will operational data stores suffer the same fate?

Consider vendors' ODSs. The vast majority of ODSs I'm thinking of are homegrown, because very few vendor products package an ODS or equivalent product. Although many packaged data warehouse products include an ODS, I'm not talking about that kind of ODS. The most common subject for an ODS in recent years has been "customer." Luckily, some vendor products implement a so-called customer hub. It's like a customer ODS, but with integration technologies and business rules to control read/write access to the hub. For this specific type of ODS, users should investigate products from DWL, MioSoft, and Siperian.

Use integration tools. All too often, the homegrown ODS is fed by a hand-coded extract, transform, and load (ETL) application or (worse) by manually created replication devices such as triggers. Instead of compounding the administrative challenge of homegrown ODSs with a homegrown integration solution, use vendor tools for ETL, database replication, and other integration technologies.

Consider other integration technologies. Many ODSs are 10 or more years old, and so are ready for replacement. Instead of replacing a legacy ODS with a newly designed one, consider replacing it with an integration technology. For instance, many ODSs enable a "database-oriented form of application integration." Now that enterprise application integration (EAI) technologies have reached a mature level, they are better suited for this purpose and should be considered.

Many user organizations have asked me specifically about replacing a legacy ODS with a vendor's platform for enterprise information integration (EII). When the ODS supports operational reporting on a 24-hour cycle, replacing it with EII can be a compelling solution, because EII can enable more frequent reporting cycles than the usual batch-oriented integration pro- cess that feeds an ODS.

Stop proliferating ODSs.

That's easier said than done, so the next best thing would be to follow the best practices for single-subject ODSs described here. They can at least help you slow down ODS proliferation, perhaps even reverse it into a smaller number of more manageable ODSs. As with any corrective project, this can be painful. But the savings in administration and maintenance make it well worth the effort.

Philip Russom [[email protected]] is a Giga analyst at Forrester Research Inc., where he provides advice to user organizations about business intelligence, data warehousing, and data integration.





Editor's Choice
Richard Pallardy, Freelance Writer
Salvatore Salamone, Managing Editor, Network Computing
Kathleen O’Reilly, Leader, Accenture Strategy
Cassandra Mooshian, Senior Analyst, AI & Intelligent Automation, Omdia