Operational Data Hub: What It Is, Why It Came About

As an enterprise architect, you are familiar with the amount of time and money spent on enterprise data management (EDM). If your company is like most, however, about 60 percent of your IT costs are spent on ETL and related data integration tasks—which serve very little value and are major time sucks. Organizations wind up spending a lot of effort and money simply copying data between multiple systems.

There is another way. The Operational Data Hub (ODH) is a “newish” concept—an enterprise architecture pattern— that is a categorization of an architecture that a customer builds to support multiple lines of business.

“The hub is replacing data marts…data warehouses—all of that. The hub is the single source of record outside of the core system,” said Brian Novacek, Senior Solutions Engineer Erie Insurance.

Why Did the Operational Data Hub Emerge?

The ODH pattern emerged from a technological shift away from relational technology as relational databases require extensive up-front modeling and conformance to rigid schemas. Each data item must have its place pre-allocated in the data model or the data cannot be loaded. This makes the cost of designing a data model to support complex integration too expensive.

The ODH on the other hand is built on the foundation of a multi-model, NoSQL database. Using a document data model, the multi-model database is schema agnostic, yet schema aware, and enables data to be loaded with much lower schema design costs.

Some of its key features include:

• A flexible document data model to handle all data types without limitations
• Sophisticated indexing that allows data to be queried as soon as it’s ingested and even before it’s been fully cleaned
• The ability to represent complex and evolving semantic relationships within and across data items
• The ability to store data and metadata together to support robust data governance
• Elasticity to scale to massive enterprise-wide data volumes
• Robust security and encryption to allow data to be combined and shared safely

Why Organizations Rely on the ODH

A classic data warehouse solves “observe-the-business” problems exclusively. An ODH, on the other hand, solves “run-the-business” problems, while providing real-time observation (i.e. discovery) capability as data flows through the enterprise. Specifically, it features continuous loading and query, ability to write-back updates, and granular security.

For years, accepted wisdom forced architects into data patterns that not only kept “run-the-business” and “observe-the-business” solutions separate and distinct, but resulted in a significant accumulation of so-called “technical debt.”

Technical debt is a result of decisions made during software development that create future re-work, oftentimes because shortcuts are taken instead of thoroughly vetted approaches. The term can also apply to unintended consequences resulting from not knowing any better and/or from following conventional wisdom.

The ODH quickly remedies these issues. By using an ODH—a key facilitator for integrating data in silos—this energy could be better put to use driving innovation through things like new application development.

And, it just may be the tool to solve your EDM woes, too.

Next: More on Technical Debt

This blog is the first in a series on the ODH. Now you have the basics on ODH, what it is and how it came about. In the next one, we will do a deeper dive into technical debt and how ODH’s new architectural pattern will solve the technical debt that’s accrued over time.

For more in-depth information on ODH, check out this resource.