Here's how I see it working in the real world. In the previous example, the legal department chose an e-discovery application (glorified search engine) and created corporate governance policies that got shoved into IT. Everything in the solution ended up in stovepipes, which means it is invariably riddled with holes. In the new world, saying yes by applying data virtualization along with infrastructure virtualization starts with one simple rule from IT to the business: your application must house its data 'here'.

'Here' is a virtual data abstraction interface that accepts any and all types of data -- from any and all types of applications -- in one common virtual place. Want to have your e-discovery tool query against our e-mail data? Point it here. Want to search across e-mail and structured transactional data? Point it to the same place. Want to write new data generated by a new application or an old Word file? Then click 'save' and here is where it will be. If there is only one virtual place to put all data, then there is only one virtual place to find all data. Behind that data abstraction, IT still has to do all the hard things it's always done, such as decide what data is going to reside where, for how long, how to protect it and so on. But if it can be done 'fluidly', then change suddenly isn't paramount. If you can react to changing infrastructural requirements without the business unit calling, then like the proverbial tree that fell in the woods, did it even happen? I suggest that if the phone isn't ringing, things are good.

Server virtualization enables fluidity of virtual machines executing application stacks so that if a failure occurs or if new powerful machine technologies come out they can be integrated dynamically, and based on priorities we might move a virtual machine to a whole new environment without the business unit knowing or caring. Server migration, high availability, disaster recovery, performance optimization and asset utilization/optimization are all functions within change states that normally cause disruption -- or at the very least they cause the phone to ring. Virtualization enables the automation and fluidity beneath that abstraction layer to be invisible.

Data Virtualization is Not Storage Virtualization

Storage sits at the bottom of the data layer, and like the rest of infrastructure, should also be virtualized. By creating basic data abstractions, logically all data can exist in one place, making it easier to perform any application or data operation function. Data layer services, such as database management, logical provisioning, file system management, performance optimization, protection and so on are functions that can be more easily addressed simply because all data exists in one virtual location. IT managers would continue to have to operate and optimize the physical storage layer beneath, but by creating a fluid data abstraction layer, they are able to mitigate the physical effects of change, which results in less negative visibility and fewer phone calls.

One of the reasons storage virtualization has been slow to move upstream is that specialized skills and knowledge about devices and functions within this layer are lost when the abstraction moves above those devices. For example, if your storage administrators are gurus at managing and operating EMC Clariion arrays, enabling them to see those Clariions as generic disk storage would not offer enough benefit to outweigh losing the ability to utilize the administrators' specific skills and tools that they acquired to manage those devices. It is a losing proposition for the industry to take high-end, proprietary equipment and say 'now you can treat these expensive devices disposable and forget all the skills and tools you know and love.' By creating a data virtualization approach, you don't have to throw the baby out with the bathwater -- you can simply buy time to do it the right way.