The industry, the analysts, and the rest of us are trying to get a handle on the many faces of Data Virtualization (DV). As soon as we think we get it, another use case shows up. If we define DV as federating data “in flight” as opposed to putting it in a central database/warehouse/mart, then we are talking about streamlining EAI, ETL, ESB, SOA, and reporting (aka BI, BA, etc.), where data is either physically moved or served on-demand. The same multi-source federation is valuable for all these patterns, however DV has become known nearly exclusively as a support technology for Business Intelligence.
How Unfortunate!
While DV is valuable across these other patterns, I want to highlight the new architectural pattern taking hold as a second key application of the technology that is being referred to as Transactional Data Virtualization (TDV). This pattern would simply not be possible without TDV.
Most people associate DV exclusively with its “first face,” Business Intelligence. The second face may surprise you as you absorb the concept of taking DV from reporting to operations. Data is federated live directly from the sources, served up on-demand to applications or to end users in portals, and updated by the application or user, effecting a heretofore unparalleled agility and efficiency to your business.
I wrote a blog some time ago about turning dashboards into operational consoles, where TDV makes data actionable. KPI dashboards can be turned into interactive user interfaces where users can take action on the conclusions and decisions based on the KPIs. Our customers are streamlining their customer-facing applications and portals by using TDV to federate data from multiple backend systems and present it on web pages. Certain fields, for example an address or preferences, are editable. If the end user is authorized, and write-back is enabled, Enterprise Enabler® updates that information in the source systems, with transaction management. If the changed information needs to reside in more systems than the original source of record, it updates those systems at the same time. I’m sure you picked up that this means you don’t have to run a separate synchronization step, which means that latency in synchronizing can be reduced an irrelevance.
Data Federation Must Have a Transformation Engine
Data Virtualization brings tremendous value any time data is required that must be compiled with or put in the context of data from one or more other sources. In my experience, this happens close enough to “always” to round up. Unless there is a transformation engine involved that federates multiple disparate sources, the federation will require custom coding to align the data properly. That’s a strike against agility, which is not good, but with such an engine, DV enables fluid complex integrations of many flavors.
On the Horizon
Enterprises with forward-looking IT organizations are incorporating Data Virtualization into their Enterprise Architecture and are quickly reaping the ROI as they reduce tech debt. The days of heavy, complex, infrastructure are numbered as CIOs elect to eliminate the old obstinate and unyielding integration platforms to finally deliver true agility to the business.