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.
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 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.
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.
Like what you just read, here are a few more articles for you to check out or you can visit our blog overview page to see more.
A data platform lets you collect, process, analyze, and share data across systems of record, systems of engagement, and systems of insight.
We’re all drowning in data. Keeping up with our data – and our understanding of it – requires using tools in new ways to unify data, metadata, and meaning.
A knowledge graph – a metadata structure sitting on a machine somewhere – has very interesting potential, but can’t do very much by itself. How do we put it to work?
Don’t waste time stitching together components. MarkLogic combines the power of a multi-model database, search, and semantic AI technology in a single platform with mastering, metadata management, government-grade security and more.Request a Demo