Operational Data Hub and Service-Oriented Architecture
The Operational Data Hub (ODH) is a newer architecture pattern, so enterprise architects may wonder how it fits in with other technologies and architectural models that they’re already using and/or are familiar with. They may wonder whether an ODH replaces these models or complements them.
A service-oriented architecture (SOA) is a good example of just such an architectural model. Let’s explore what SOAs were meant to do and where an ODH can fit into that model.
SOAs serve two major functions:
- Create a broad architectural model that defines the goals of applications and the approaches that will help meet those goals
- Define specific implementation specifications
For decades, software development required the use of modular functional elements that performed a specific job in many places within an application. But then enterprises needed a way to adapt their procedure-based development model to the use of remote, distributed modules.
The solution was to redefine the old model into a broader and more clearly architected collection of services. These could be provided to an application using fully distributed software components. The architecture was called service-oriented architecture, or SOA, which wrapped these services in systems to support open use under full governance.
SOAs have three major objectives:
- To structure procedures or software components as services – These services are designed to be loosely coupled to applications, so they are only used when needed. They are also designed for easy use by software developers who have to create applications in a consistent manner.
- To provide a way to publish available services – This includes their functionality and input/output (I/O) requirements. Services are published in a way in which developers can easily incorporate them into applications.
- To control the use of these services to avoid security and governance problems – Security in SOA revolves heavily around the security of the individual components within the architecture, identity and authentication procedures related to those components and securing the actual connections between the components of the architecture.
These characteristics all sound great—and they are! But an Operational Data Hub (ODH) can make them even better.
Where ODH Fits in with SOA
SOAs were a good idea, but unfortunately they proliferated data silos and created issues with data quality and governance. While they helped solve operational interoperability challenges, they also had the unintentional consequence of proliferating data problems by creating derivative copies of data all over the enterprise and exacerbated challenges around governance.
ODH provides a better mechanism to integrate data across silos on the operational side by allowing you to have a 360 view of data as applications are integrating with each other. SOAs are fine, but what you also need is an ODH behind it to eliminate derivative data. Also, an ODH allows you to do it piecemeal, so you don’t sacrifice agility of application-to-application integration.
With an ODH in place, true data-centric integration is now available, allowing real-time applications to be brought to the data in many cases, as opposed to needing to move the data around to the applications whenever operational integration needs to occur. When an ODH enables real-time, data-centric integration, it becomes possible to support cross-line-of- business operations that might otherwise not have a home.
For example, a global investment banking customer needed to keep track of a particular regulation regarding OTC derivative trades that could only reasonably be gleaned after numerous trading desk data was integrated. At that point, any trades that needed remediation would need to be tagged and tracked for further processing.
In this example, the best place to tag these trades was in the ODH, recording the fact that they needed certain types of upstream and downstream remediation—all of it—however, based on an integrated context. In other words, the operational work now began in the middle, so to speak, even though the trades originated elsewhere. Only with a data-centric integration pattern with operational capabilities was this possible.
Read our ebook, Introducing the Operational Data Hub, to learn more about this topic and more, including the functional specifications of what an ODH should do and specific use cases of how it is being put into practice today.