This week, Dell acquired Ocarina, a provider of primary storage deduplication.  The acquisition provides technology that they can integrate with existing storage platforms such as EqualLogic.  However, Dell also sells deduplication technology from EMC/Data Domain, CommVault and Symantec.  Dave West at CommVault suggests that these technologies are complementary, and I agree. However, the announcement raises a significant strategic question – which is a better deduplication strategy, “one size fits all” or “best of breed”?

Deduplication is an important technology in the datacenter and reduces power footprint and cooling requirements.  However, it typically brings a performance trade-off during read or write operations due to the additional processing required to re-hydrate or deduplicate data.  The benefits of the technology are compelling and we have seen multiple large companies promote different deduplication strategies.  Their approaches fall into two broad categories:“best of breed” (BoB) or “one size fits all,” (OSFA) and the choice of approach has a major impact.  Let’s look at each strategy individual.

One size fits all

This approach is best exemplified by EMC’s Viper project and HP’s StoreOnce initiative.  The idea is to create one global deduplication technology that is used across all applications and hardware.  In theory, this allows for deduplication with consistent results and the ability to move deduplicated data from one system to another with out having to re-hydrate data.  The idea is a bold one, but has some challenges in implementation.

The fundamental problem is that both data characteristics and the requirement for read/write performance vary widely.  For example, compare the performance and SLA requirements of an Oracle database to a user file backup.  Not only are these data types completely unrelated, but they are also written to storage in a very different ways.  Given these variations how can you use one deduplication algorithm?  Deduplication technology is complex and must be designed to solve specific problems.  A generic algorithm is just that and will likely provide mediocre results across the board.

These vendors have chosen a difficult path and their challenge is to create a flexible deduplication algorithm that will work effectively across all data types and business SLAs.  Having seen deduplication development first hand, I can tell you that it is extremely complex and creating a generic solution that works across all tiers of storage and types of data and provides compelling results is extraordinarily challenging if not impossible.  It will be interesting to see how these vendors address this.

Best of breed

This approach is best exemplified by Dell and their recent acquisition of Ocarina.  In this model, a vendor assembles a range of data reduction options to meet different needs.  For example, a supplier might offer an in-band compression option that would minimize the performance impact and provide an adequate but limited data reduction benefit for performance sensitive customers.  They would also offer a backup-specific deduplication solution to minimize backup windows, recovery times and storage footprint.  By offering these options, the vendor could provide solutions that meet a range of customer needs.

The challenge with the BoB approach is that you do not gain the interoperabilty benefits of OSFA.  Moving data from one environment to another will require the re-hydration and re-deduplication of the data, potentially impacting performance.  Although this creates inefficiencies, it does provide the benefit of optimized data reduction that best aligns with business requirements

Summary

Based on my experience with deduplication in the secondary storage arena, the BoB approach is the way to go.  The OSFA model promises a level of simplicity with one algorithm used universally; however, it also creates substantial development and management complexities due to varying data and business requirements.  The vendors promoting this approach position it as a long-term strategy and so it is unlikely to appear any time soon.  This means that it is unclear if/when the vision will come to fruition and it is certainly possible that it may never live up to expectations.

The BoB approach provides an immediate time-to-market benefit.  There are suppliers providing a range of data reduction options today that fit nicely into this model, and Dell appears to be pursuing this approach with Ocarina for primary storage and various partners for backup deduplication.  The challenge is that it can add to management complexity and force re-hydration as data moves between solutions.  However, even with these limitations, I believe that this is the best approach available today.  It provides the flexibility and optimized performance that customers’ need to meet their varying business requirements.

The Future

Long-term, I believe that we will see a combination of these two models.  The simplicity of OSFA is beneficial, but business requirements will mandate the improved performance and data reduction characteristics of BoB.  The best strategy is to define two or three broad tiers of data and use appropriate data reduction methods for each.  The data reduction algorithms will likely vary by tier and may range from simple compression to sophisticated deduplication approaches.  An important consideration is manageability and scalability of each tier and SEPATON will play an important role by providing a highly scalable platform for protecting, storing and retaining secondary data. SEPATON has spent a great deal of time solving the deduplication conundrums in the secondary storage area – with our ContentAware approach, we can deliver both the speed and simplicity of the OSFA approach and the flexibility and efficiency of the BoB approach. Take my advice. BoB is the way to go.

Related posts:

1. Inline Deduplication: What Your Mother Never Told You
2. TSM and Deduplication: 4 Reasons Why TSM Deduplication Ratios Suffer
3. HIFN – Commoditizing hash-based deduplication?

Today SEPATON announced the addition of Storage Pools to our data protection platform.  The technology marks a major step in the path to data protection lifecycle management, and I am excited about the new functionality and wanted share some brief thoughts.

To summarize, storage pooling allows data to be segmented into discrete pools that do not share deduplication.  Data sent to one pool will only be deduplicated against information in that pool and will not co-mingle with other data.  Additionally, pools provide configuration flexibility by supporting different types of disks with different performance profiles.  Pools also benefit from SEPATON’s DeltaScale architecture which allows for dynamic capacity and performance scalability.  Pools are a no-cost option with our latest software release and customers have the ability to implement them in the way that best meets their business requirements.  Some of the benefits include:

Service levels

The logical separation of pools enables end users to provide differing levels of service.  Pools can be configured with different node and storage configurations thus allowing an administrator to provide different ingest and density metrics for each pool.  However, the environment is still managed in one system image and can scale capacity or performance.  This prevents system sprawl as is common with many of our competitors.

Multi-tenancy

Pools prevent ingested data from comingling with data in other pools.  This is vital for those environments where data segregation is critical.  A classic example is a service provider who wants to offer accelerated backup as a service.  They must keep each customer’s data separate, and an S2100 with Storage Pools will cost effectively address this challenge and provide system scalability to meet future growth requirements.  With competing solutions, the service provider would need to implement separate systems for each customer.  The management complexity would increase rapidly and it gets even more difficult as data grows.

Another benefit of storage pooling is that it ensures that one pool’s capacity does not impact another’s.  If an appliance is segmented into pool A and B and A fills up, pool B will not be affected.  The benefit is that in a pooled system, the operator can provide consistent capacity and performance to each pool and not have to worry about how growth in one pool will impact another.  Of course, the rapid growth in the first pool may provide a revenue opportunity for the service provider and they can benefit from SEPATON’s dynamic capacity scalability.

Charge-back

Separating data is valuable, but it is critical to understand system utilization to enable effective chargeback.  The new release also provides capacity reporting to allow users to quantify the capacity used by each pool.  This allows for effective chargeback since you can clearly delineate storage usage.

Future Protection

Disk technology is always changing.  In the world of SATA, we continue to see increasing densities and new controller technologies.  For example, HDS recently announced an upgrade to their AMS series of disk arrays and SEPATON is shipping the new technology in our platform.  Inevitably, future innovations will occur and as they do, Storage Pools will allow the different disk technologies to co-exist in a transparent fashion and allow for data migration.

Single System Image

Most importantly, Storage Pool technology relies on SEPATON’s core appliance technology.  The ability to dynamically scale capacity and performance is a hallmark of SEPATON’s DeltaScale architecture.  The same functionality extends to Storage Pools thus allowing end users to grow the system as needs change while maintaining single system manageability and detailed reporting.

In summary, storage pools is a new technology that brings a range of new features to SEPATON’s platform.  The functionality is unique in the deduplication appliance space and when combined with SEPATON’s dynamic scalability can provide tremendous customer benefits.

Related posts:

1. IBM Storage Announcement
2. A little bit off topic – deduplication and primary storage

One of biggest challenges facing today’s datacenter managers is protecting the vast quantities of data being generated. As volumes have increased, customers have looked for larger and larger backup solutions. Multi-node global deduplication systems have become critical to enable companies to meet business requirements and EMC/Data Domain’s response to these challenges has been “add another box” which is their answer to all capacity or performance scalability questions. It appears that Data Domain has acknowledged that this argument no longer resonates and has reverted to Plan B, bolt-on GDA.

The use of the term “bolt-on” stems from a previous blog post by EMC/Data Domain’s VP of Product Management, Brian Biles. In the entry, he characterizes other deduplication vendors as bolt-on solutions, and the obvious implication is that Data Domain is better because it is not a bolt-on. Few would agree with this assertion, but it is an interesting opinion and I will return to this later.

On the surface, the GDA announcement includes all of the buzzwords including “dual controller”, “global deduplication” and “transparent load-balancing”. The solution sounds impressive, right? Well so did the DL3D 4000 and remember what happened to the DL3D family? The simple fact is that EMC/Data Domain (DD) has announced a product that may be impressive on paper, but the reality is much different. DD has been rumored to be developing a true global deduplication solution for the last few years, and it is hard to believe that this is the result.

GDA is unlike any other deduplication appliance. Every vendor (including DD pre-GDA) has built appliances that are self-contained and designed to minimize the administration, configuration and modification of backup environments. In short, the solutions are designed for simplicity. The GDA is different; it is essentially two separate DD880′s and a heavy OST client that hashes and software compresses the data and sends it to one of the two boxes based on the first digits of the hash. By forcing media servers to perform highly CPU-centric processing, the GDA moves the problem to the media server. The problem now rests on the end users shoulders to manage and size every server to ensure it meets appropriate GDA specifications. Essentially, the GDA has assimilated the media servers into its “appliance” realm and pushed processing and management activities onto the customer. It is important to note that GDA requires Symantec OST technology which is available on NetBackup and BackupExec. If you run any other backup application then GDA is not an option for you.

Here are some points to consider related to the implementation:

• How do you size the required media server upgrades to meet your performance requirements?
• Will you need to purchase new media servers to gain the processing power required?
• Who do you call if your performance does not meet expectations?
• Are you comfortable running such highly CPU intensive agents on your media servers which may already be resource constrained?
• What happens if you have some applications that backup directly to tape using a LAN free approach such as NDMP or RMAN?
• What if you are running backup applications like IBM TSM, EMC’s own NetWorker or CommVault that do not support OST?

These are real end user concerns. We have plenty of customers with 20+ media servers who would need to completely overhaul their environment to implement GDA. These customers would scoff at adding DD’s agents to their already overburdened servers.  In contrast, a true multi-node global deduplication solution like SEPATON’s can be connected and will just work as a backup target. Agents are not required when backing up to a VTL.

In summary, it appears that EMC/Data Domain is tacitly acknowledging the limitations of their hash-based architecture. They spent years trying to develop an integrated global deduplication solution and the best they could come up with is a cobbled together system including dual 880′s and an unwieldy OST client. It appears that the GDA has more in common with the DL3D4000 then I originally thought! Isn’t it ironic that the biggest opponent of bolt-on technology has so fully embraced the concept in the GDA?

Related posts:

1. SEPATON Versus Data Domain
2. NetApp and EMC Duel to the Death for Data Domain
3. NetApp and Data Domain: ‘Til death or a better offer from EMC do we part

There is an interesting blog discussion between Dipash Patel from CommVault and W. Curtis Preston from Backup Central and TruthinIT regarding the increasing or decreasing benefits of deduplication ratios. They take different perspectives on the benefits of increasing deduplication ratios and I will highlight their points and add an additional one to consider.

Patel argues that increasing deduplication ratios beyond 10:1 provides only a marginal benefit. He calculates that going from 10:1 to 20:1 results in only a 5% increase in capacity efficiency and suggests that this provides only a marginal benefit. He adds that vendors who suggest that a doubling in deduplication ratios will result in a doubling cost savings are using a “sleight of hand.” He makes an interesting point, but I disagree with his core statement that increasing deduplication ratios beyond 10:1 provides only marginal savings.

Preston responds to Patel by suggesting that there is a real cost to purchase, manage and power/cool disk systems. An increase in deduplication ratios from 10:1 to 20:1 reduces the amount of required disk storage by two. (e.g. 10 TB at 10:1 requires 1 TB of disk while a 20:1 reduction would require .5TB disk.) He argues that this provides real management cost, power and cooling savings. I believe that Preston makes a good point, but there is another element that is also worth considering.

Most end users purchase deduplication with an end goal of replicating their data for disaster recovery purposes. The benefit of deduplication is not just about retaining data locally, but also about reducing bandwidth requirements for replication. The implications of going from 10:1 to 20:1 can have a major impact on replication and disaster recovery and in some cases can make the difference between meeting or missing SLAs. If we take the same example above, 10TB will shrink to 1 TB and will take 49.4 hours to replicate over a T-3. The same math with a 20:1 ratio yields 24.7 hours. (The model assumes that the T-3 delivers 45 Mb/sec and can be fully utilized for backup.) In this scenario, if the customer’s requirement is to get data offsite in 24 hours, they barely miss it with 20:1 and completely miss it with 10:1. If the deduplication ratio were to increase by one point to 21:1, the customer could replicate their data in 23.5 hours and meet their window. As you can see, in this case, data reduction ratios really matter. In fact, they are critical to the customer meeting their SLAs.

In summary, I believe that Patel is wrong in his assessment of deduplication ratios. Increasing ratios can and will have a meaningful impact on customer environments and suggesting that the benefits only result in 5% savings is misleading.

Related posts:

1. TSM and Deduplication: 4 Reasons Why TSM Deduplication Ratios Suffer
2. DeltaStor Deduplication, cont….
3. DeltaStor Deduplication

I was recently pondering TSM’s implementation of target deduplication and decided to review ESG’s Lab Validation report on IBM TSM 6.1. There is quite a bit of good information in the paper, and some really interesting data about TSM’s target deduplication.

Before discussing the results, it is important to understand the testing methodology. Enterprise Strategy Group clearly states that the article was based on “hands-on testing [in IBM's Tucson, AZ labs], audits of IBM test environments, and detailed discussions with IBM TSM experts.” (page 5) This means that IBM installed and configured the environment and allowed ESG to test the systems and review the results. Clearly, IBM engineers are experts in TSM and so you would assume that any systems provided would be optimally configured for performance and deduplication. The results experienced by ESG are likely the best case scenario since the average customer may not have the flexibility (or knowledge) to configure a similar system. This is not a problem, per se, but readers should keep this in mind.

The whitepaper highlights the data reduction realized using TSM and mentions capacity savings of 19:1. However, if you look carefully, you see that the space savings calculations are based on capacity reduction from TSM’s proprietary progressive incremental technology and deduplication. Progressive incremental technology reduces the amount of storage required by bypassing full backups. The really interesting question is “what additional benefits are gained by using TSM’s target deduplication?” Fortunately, ESG provides an answer.

The idea behind deduplication is that it provides capacity savings by removing redundancies within backup data. Theoretically, IBM should have an advantage deduplicating TSM backups since they are intimately familiar with the application and its data formats. However, ESG’s results do not support this assertion. The paper states, “Data deduplication enhanced data reduction in TSM nearly 50% over progressively incremental backup schemes alone.” (page 8 ) This suggests that IBM’s deduplication provides a 2:1 space savings! Wow, talk about a minimal benefit; you could get close to the same results with hardware compression.

In summary, TSM deduplication appears to provide minimal capacity savings while creating management challenges. As an end user concerned about backup and recovery, you should carefully evaluate your options. The improved manageability, performance and data reduction of dedicated target deduplication appliances like SEPATON’s S2100 product family is a better option for all but the smallest environments. TSM includes target deduplication for free, but remember, in this case, you get what you pay for!

Related posts:

1. TSM and Deduplication: 4 Reasons Why TSM Deduplication Ratios Suffer
2. Deduplication ratios and their impact on DR cost savings
3. TSM Deduplication

TSM presents unique deduplication challenges due to its progressive incremental backup strategy and architectural design. This contrasts with the traditional full/incremental model used by competing backup software vendors. The result is that TSM users will see smaller deduplication ratios than their counterparts using NetBackup, NetWorker or Data Protector. This post explores four key reasons why TSM is difficult to deduplicate.

Progressive incremental model
TSM’s incremental only approach presents the biggest challenge to deduplication. By sending only changed data, TSM limits the amount of redundant information stored and hence deduplication benefits. This is in stark contrast to most other backup applications that rely on frequent full backups; it is these jobs that provide the best data reduction. However TSM is often configured to perform nightly full backups of data types such as Exchange, Oracle or SQL. These backups will provide similar deduplication benefits as seen in other applications, but typically represent a fraction of total data protected.

Data movement
Deduplication algorithms use various methods to recognize redundant information. They analyze data as it is written to the system to find the redundancies. In traditional backup applications, data is typically written to a disk or tape device and remains there until expiration. In contrast, TSM writes data to a given pool and then will run multiple processes which move the data such as reclamation. These processes create deduplication challenges because they force the appliance to constantly re-hydrate data and then re-deduplicate data. The frequent data movement creates inconsistent data patterns that can be difficult for deduplication mechanisms to recognize resulting in decreased data reduction.

Data fragmentation
TSM is designed to maximize performance by using multi-streaming. This means that a given job could backup to almost any disk or tape device and its data could be multiplexed or mixed with data from any other server. This can be a challenge because data becomes fragmented and will be written in many different physical tape or disk locations. Deduplication struggles because these segments can be small and the algorithm must effectively recognize the varying block sizes to achieve the best possible data reduction. In practice this reduces data reduction.

Reclamation/Overwrites
Since TSM typically spreads a backup job across multiple pieces of media, data becomes fragmented. TSM has a process called reclamation which reduces fragmentation by moving data onto new cartridges and expiring the previous cartridges. Reclamation is designed to minimize the number of cartridges required in a TSM environment, but it can be I/O intensive. As the process it runs, it moves unexpired data onto new cartridges and expires the old cartridges. This can be a challenge for deduplication systems that utilize a batch cleaning process. These systems run a weekly or more frequent process to deleted expired cartridges; free space is not realized until the cleaning is completed. Deduplication ratios will decline since the expired cartridges will consume disk space. The other challenge is that the clean process can be I/O intensive and could negatively impact other TSM processes.

TSM is a very powerful application with a unique data protection model. Unfortunately, the same technology that reduces backup windows also creates challenges for deduplication. The result is that deduplication ratios decrease in TSM environments. However, even with smaller ratios, deduplication still provides a strong benefit for TSM environments particularly with deduplicated replication.

Related posts:

1. Deduplication ratios and their impact on DR cost savings
2. 6 Reasons not to Deduplicate Data
3. TSM Deduplication

Rumors have been circulating for months about the demise of NetApp’s VTL offering. Today, Beth Pariseau from SearchDataBackup published the first public confirmation that development on the product has ceased. It is not a surprise, but makes for an interesting case study.

NetApp acquired VTL technology with their purchase of Alacritus for $11 million back in 2005. Alacritus provided a software only VTL solution that ran on a Linux platform. Their product specifications appeared impressive, but they had limited success in the US. Our partners in Asia saw them more frequently. For NetApp, the acquisition made sense because it represented a relatively cost-effective entry into the rapidly growing VTL market. However, as in most things, the difficulties were in the details.

NetApp’s core intellectual property is their ONTAP operating system and associated WAFL filesystem. These components provide the intelligence and value-added features of their arrays. The challenge for NetApp after acquiring Alacritus was the integration of the two technologies.

NetApp’s short term strategy after the purchase was to build a VTL using Linux, Alacritus, x86 servers and existing disk shelves, and they released their first system in 2006. This leveraged their hardware design and configuration, but bypassed their core software IP. Customers could reuse VTL disk shelves in their filers if they decommissioned the VTL, but there was no ability to share the same storage between filers and VTLs. This is your classic island of storage problem.

The next trend in the market was deduplication. NetApp recognized the importance of the technology and announced A-SIS deduplication for their filers in May of 2007. However, the Alacritus VTL did not support ONTAP/WAFL and so the technology could not be reused. NetApp then embarked on a project to develop a second deduplication engine (after A-SIS) for use on their VTL.  They said that the new deduplication system would be available in June of the same year, and I believe that they underestimated the difficulty of creating a new engine. The development took far longer than expected and they announced the product in October of 2008. To this day, we have seen few implementations of NetApp VTLs with deduplication, and I often wonder if this is because their new deduplication engine does not work effectively.  Given the limited success, it is not surprising that NetApp has officially ceased development.

In my opinion, NetApp’s VTL failed due to a lack of commitment. To be successful, they needed to port the Alacritus solution to ONTAP/WAFL to allow it to co-exist transparently with existing technology. I believe that NetApp was focused on snapshots and replication for backup and recovery and so the NearStore VTL was not given the attention it deserved. Had they integrated Alacritus and ONTAP, they had the potential to create a unified filer, VTL and deduplication appliance which would have been very competitive.  Instead, they chose to leave Alacritus as a separate product, and NetApp’s aggressive pursuit of Data Domain marked the end of the NearStore VTL.

The irony is that I believe NetApp had an opportunity to be an early player in the VTL space. They had the relationships and footprint to aggressively sell the solutions. Unfortunately, their critical missteps and lack of focus limited their success.

Related posts:

1. NetApp and Data Domain: ‘Til death or a better offer from EMC do we part
2. Surviving A Down Economy – A vendor Perspective
3. It’s final – EMC acquires Data Domain

When backing up data to a deduplication system, two types of data are generated. The first comprises objects being protected such as the Word documents, databases or Exchange message stores. These files will be deduplicated and for simplicity I will call this “object storage”. The second type of data generated is metadata. This is information that is used by the deduplication software to recognize redundancies and potentially re-hydrate data in the case of restoration. These two types of data are critical and are typically required for writing the data to the system and potentially reading data. Here are four key questions that you should ask about protecting metadata.

1. How is metadata stored?

It is important to understand how the storage system is configured to protect this data. Simple questions like “how much storage is allocated to metadata?” can be vital since running out of metadata space is essentially the equivalent of running out of object space. (e,g, if you run out of metadata capacity then you cannot add any more items to object storage since this creates metadata.) I have heard of numerous scenarios with competing systems where customers run out of metadata space while still having ample object space available. This results in inefficient space utilization.

2. How is metadata protected?

Metadata is a critical part of the deduplication process and its loss or corruption can be very problematic. You should understand how metadata is protected. Are backup copies made? If so, how are they created, stored and recovered.

3. How does metadata storage requirements grow over time?

As mentioned above, running out of metadata space results in poor capacity utilization. You should understand how metadata is created and its growth over time. In many implementations, the size depends on deduplication efficiency and so the more data you backup that cannot be deduplicated (e.g. compressed or encrypted data), the more metadata space you will use. Replication may also require meta space and you should ascertain this impact as well.

4. What happens if the metadata it is corrupted?

Since this data is critical for the operation of deduplication, you should understand what happens if you permanently lose the metadata repository due to corruption or other problem. In extreme cases this could result in a complete system loss while in other cases the impact may be a reduction in deduplication ratios. The impact will vary by deduplication algorithm.

In summary, the creation management and handling of metadata is a key component of every deduplication algorithm. Many vendors prefer to gloss over the importance of metadata and focus on other areas such as deduplication ratios or post-process vs inline. The reality is that the management and creation of metadata is critical and each end user should evaluate how this effects various solutions and their business SLAs. In a future blog post, I will discuss how SEPATON addresses each of these four questions.

Related posts:

1. A little bit off topic – deduplication and primary storage
2. TSM and Deduplication: 4 Reasons Why TSM Deduplication Ratios Suffer
3. Inline Deduplication: What Your Mother Never Told You

The email below appeared in my inbox yesterday.  The EDL/DL3D 1500/3000 has officially been discontinued.  It was obvious from the moment EMC purchased Data Domain that the Quantum stuff was dead, but it took time for EMC to finally admit this.  The strongest statement came in Frank Slootman’s TechTarget interview.  Clearly the EMC/QTM relationship was a rocky one from the beginning and so the outcome is not surprising.

Click for larger image

I find it amusing that just over a year ago, EMC was promoting the Quantum technology and said that “These offerings compete directly with Data Domain and are sharply differentiated by their superior, policy-based de-duplication capabilities, including de-duplication checks between local and remote sites, better scalability, Five-9s availability, and unmatched service and support.” (Local copy of the source, original source.)  EMC has since completed the acquisition of Data Domain and Quantum is now the pariah and Data Domain is the best thing ever.  Frank Slootman, VP of EMC’s backup group, said in the interview linked above, “We’re swapping a lot of those [Quantum-based] boxes out at zero revenue. We’ve taken out about a dozen and we’ll continue to take out a similar number this quarter. Customers don’t want it.” Wow, so much for sharply differentiated products with superior technology!  I feel sorry for end users who bought into EMC’s DL3D story and now have to deal with a forklift upgrade.

Related posts:

1. DL3D Discussion
2. EMC one-ups NetApp
3. EMC and Data Domain: It was the best of times, it was the worst of times

I attended multiple keynote and breakout sessions at SNW last week, but my busy meeting schedule conflicted with many of the morning sessions. I was able to attend to Data Domain’s talk given by Frank Slootman and wanted to provide some commentary.

The bulk of the session was boring and included what appeared to be a standard corporate slide deck which I am sure any salesperson could present in their sleep.  The presentation could be summarized with Data Domain’s usual message: inline deduplication is good and everything else is bad, and, of course, Data Domain’s deduplication is the best.  I was definitely hoping for something more interesting and was sorely disappointed; however, things changed when it came to the Q&A.

Just to provide a bit of background, my experience with SNW is described here.  There were a large number of end users in attendance both at the expo and the keynote sessions and I estimate that many of the show’s 900 end users were in attendance for this talk.  At the end of the planned remarks, Slootman opened the floor to questions.

The first question came from a Data Domain end user who was familiar with Slootman.  The customer started by saying “Frank, we met when you visited our company.”  Slootman acknowledged the statement although it was not clear that he knew the person and things went downhill from there.

The customer was a Data Domain user and expressed frustration about the lack of basic capacity planning tools.  He was annoyed about his systems’ limited advanced warning when space was running low.  The result was that he had to fight with procurement to expedite the purchase of new shelves to ensure that he did not violate business SLAs.  His seemingly simple request was a tool that would allow him to forecast storage requirements for his Data Domain systems so he could plan purchases in advance.  Seems like a reasonable request, right?  Well, not according to Slootman.

First Slootman suggested that the end user pay attention to the automated capacity warnings.  The end user replied “Yes, but when those arrive it is too late.”  (I wonder if this can be adjusted.)  The customer pressed the point and said “I really need this and you promised it!” At this point Slootman became agitated and you would think that he would put on his “the customer is always right” hat and say something vague like “I will look into it and see if I can get it prioritized” or perhaps “I understand your frustration, let’s meet after the show and discuss it.”  Nope, none of the niceties from Slootman, he went straight for the jugular.  His answer was “Look, I have 50 other priorities just like this on the list and yours is on the bottom!”  Ouch!  How is that for customer service?  At this point, the end user’s microphone was disabled and questioning moved elsewhere.

The entire discussion was surprising.  My table comprised a mix of vendors and end users and everyone was looking at each other in wonder.  I even heard a couple of people say “can you believe he said that?”  I was equally surprised especially since everything Slootman had previously said was boring corporate fluff and I would never imagined that he would respond so aggressively to a customer.

In summary, the question about capacity planning was the highlight of the Slootman’s talk.  As the head of EMC’s Backup and Recovery division, you would think that Slootman would take a customer-centric approach to the situation.  Sure the end user was frustrated and perhaps even a bit aggressive, but I would have expected Slootman to take the high road and avoid alienating a customer in a public forum.  Clearly he did not.  Being the head of the division, it makes you wonder what values he is instilling in his own organization.  Is he suggesting that this is an appropriate way to treat customers?  Would it be acceptable for his reps to say the same thing to an agitated end user?  Clearly the answer should be no, but is it?

What do you think?  Is this an appropriate response to a question in a public forum?  Have you seen a similar attitude from others in his group?

Related posts:

1. Poll: Who will acquire Data Domain?
2. It’s final – EMC acquires Data Domain
3. Data Domain & GDA – Bolt-on to the rescue