Marketing and Business Development

Robert Eve

Subscribe to Robert Eve: eMailAlertsEmail Alerts
Get Robert Eve: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Virtualization Magazine, SOA & WOA Magazine

Virtualization: Article

Ten Mistakes to Avoid When Virtualizing Data

Meeting the ever-changing information needs of today's enterprises

Data virtualization's ability to overcome hardware and software complexity provides enterprises with an excellent opportunity to improve IT agility and save significantly. As more enterprises seek these benefits, data virtualization is swiftly moving from new idea to the mainstream. This article looks at the 10 most common mistakes made by early adopters as object lessons for helping new implementations accelerate the potential achievement of data virtualization's benefits.

Determining where and when to use data virtualization is the source of five common mistakes that may occur as enterprises adopt data virtualization. Implementing data virtualization, from the design and enabling technology points of view, is the source of three potential mistakes. Failing to determine who implements it and failing to correctly estimate how much value may result are also common. Before we address these, let's begin with a definition of data virtualization.

Data Virtualization at a Glance
Data virtualization brings together (federates) data from multiple, disparate sources - anywhere across the extended enterprise both inside and outside the firewall - into unified, logical, virtualized data stores for consumption by nearly any front-end business solution including portals, reports, and applications (see Figure 1). As a middleware technology, data virtualization is often referred to as virtual data federation, high-performance query, or enterprise information integration (EII).

Data virtualization reduces development time and ongoing maintenance costs by avoiding physical data consolidation with its associated development, storage and support requirements. Further, as data requirements change or expand, modifying the virtual data store can be completed in minutes, typically without requiring IT resources to rebuild consolidated physical stores. Both business users and IT share in these benefits.

Mistake #1 - Trying to Virtualize Too Much
Data virtualization, similar to storage, server, and application virtualization, delivers significant top- and bottom-line benefits. For example, an energy firm uses data virtualization to integrate real-time oil field data with its nightly consolidated warehouse information to increase its production by thousands of barrels per day. A financial services firm reduces its new application development time by 50 percent, while another financial services firm saves nearly $2M annually in business intelligence (BI) and reporting costs.

However, data virtualization is not the solution for every data integration problem. For instance, when the consuming application requires multidimensional analysis, or when the data requires significant transformations before it can be consumed, physical data consolidation is the better approach.

To avoid virtualizing too much data on any particular development project, begin with a good understanding of the characteristics of the business, data sources, and data consumers.

Mistake #2 - Failing to Virtualize Enough
The flipside to Mistake #1 is failing to virtualize enough. Doing things the "way we've always done them," rather than looking for the best way, is something everyone can relate to. During the 1990s, physical data consolidation developed with the advent of separate, consolidated stores and specialized extract, transform and load (ETL) middleware. By the 2000s, ETL had become the default data integration paradigm. But should it be exclusive?

Failing to virtualize enough carries a large opportunity cost because physical data consolidation necessitates longer time to solution, more costly development and operations, and lower business and IT agility due to the extra overhead involved.

Fortunately, the prescription for avoiding this mistake is to carefully analyze and define requirements during the data integration decision-making process to ensure that the best solution to meet these requirements, not tradition, drives the decision.

More Stories By Robert Eve

Robert "Bob" Eve is vice president of marketing at Composite Software. Prior to joining Composite, he held executive-level marketing and business development roles at several other enterprise software companies. At Informatica and Mercury Interactive, he helped penetrate new segments in his role as the vice president of Market Development. Bob ran Marketing and Alliances at Kintana (acquired by Mercury Interactive in 2003) where he defined the IT Governance category. As vice president of Alliances at PeopleSoft, Bob was responsible for more than 300 partners and 100 staff members. Bob has an MS in management from MIT and a BS in business administration with honors from University of California, Berkeley. He is a frequent contributor to publications including SYS-CON's SOA World Magazine and Virtualization Journal.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.