I thought I'd take a moment to circle back to an announcement from Dec 20th that EMC made around this topic, because I thought the story-behind-the-story would be interesting.
The press release is innocuous enough (as are most press releases). Simply put: EMC is offering a complete set of business continuity services: in addition to the usual assessment / design / implementation stuff, we now can help you operationally run your business continuity environment.
So why do I think this is interesting? Like any glacier or volcano, the interesting stuff is underneath ...
The Business Continuity Landscape
Now, please remember, I've worked at EMC for over 13 years. And, for a big chunk of that time, it was all about SRDF.
Not to bore you with history, but -- at the time -- EMC had the only viable approach for replicating massive ammounts of data at a distance, and doing so in a way that customers could recover at a remote site simply because all their data was there, up-to-date.
We sold a lot of it.
And, over the years, we built up an enormous amount of intellectual capital in assessment, design, implementation and management of these environments. I'd argue we became the best at this sort of thing -- no one else came close during our heyday.
But we found significant barriers to adoption. Several years into this, I started to notice that there were two very distinct groups out there.
I started calling them the "haves" and the "have nots".
The "haves" were organizations that fundamentally saw sophisticated business continuity as an essential part of their business strategy. It wasn't a nice-to-have, it was a must-have.
Think about it, if you're a big bank, or other financial institution, or an airline, you need to be operational 24x7, no excuses. If you're down for any length of time, for any reasons, unimaginable havoc is wreaked in your business, the businesses of your customers, and -- occasionally -- in the global economic picture.
As a result, the "haves" think business continuity all day long, and they've done so for many years. Senior management understands the issues and provides the required funding. These companies have people who've been working in this arena for many years, sometimes decades.
They've got operational processes that have been honed over the long run. They practice recovery as a normal course of their business. It's part of their thinking. It's a core competency of IT.
They're so good at this, they tell us what we need to be building.
These people found EMC (and SRDF) a winner -- they still use a lot of it to this day. Scratch any sophistcated, large-scale business continuity implementation, and there's a very good chance you'll find a bunch of EMC technology underneath.
The "have nots" were a very different picture.
Yes, they understood that business continuity (or even simple disaster recovery) was important, sort of. But, as various projects competed for scarce dollars, the big BC project never really got the resources or attention it needed.
Worse, because it wasn't part of the corporate fabric, they usually didn't have the in-house expertise to do the assessment, write the justification, design the architecture, etc. etc. These skills can be pretty specialized, and they tend to work at places that do a lot of this sort of stuff, as you'd expect.
Worse yet, these IT leaders were frustrated. On one hand, they knew that keeping business running if something bad happened was of the utmost importance, but they couldn't seem to "break through" the considerable and sustained investment required to solve the problem, even in a basic way.
And Then Things Began To Change
I don't know if there was a defining moment or event, but over the last few years, more and more customers are taking the whole topic of business continuity seriously. And I think it's due to a number of factors.
Some have had a really bad IT day, and realized just how exposed they are.
Others are getting good advice from their business consultants around risk mitigation at a board of directors' level.
Still others find themselves in a fully automated, 24x7 business model with a global reach and realize that there is no such thing as downtime any more.
Some of the costs associated with business continuity have come down as well. Bandwidth is far cheaper, as is storage. VMware means that you've got the ability to do very clever things with the number (and types) of servers you use for recovery. And some people tell me that data centers in the hinterland have gotten cheaper in terms of real estate and energy costs.
And still others realize that, while it's an expensive proposition (like insurance), what's really expensive is NOT having insurance when you needed it.
I think that the other trend worth noting is that more and more customers realize that relying on a shared service provider (e.g. Sungard or similar) presents interesting questions at crunch time. I've noticed that there's a strong preference these days to "own" your own recovery capability to a higher degree in the past.
Maybe it's a trust thing, maybe it's an economic thing (using the assets to do other work in the meantime).
But We Found There Was A Missing Link
Our previous experience in managed services was primarily around storage. We offered a set of managed storage services where we had different approaches to managing a customers' storage environment for them.
Maybe it was a residency or two. Maybe it was a program management office. Maybe it was a full SLA arrangement where we provided defined service levels at defined prices.
Not really outsourcing, more like a flexible insourcing arrangement where the customer owned the assets, and we assumed as much (or as little) of the responsibility for running the stuff as the customer wanted.
I was a bit surprised on just how popular these offerings were in the marketplace. Managing storage at scale was becoming hard, and finding the skilled people who knew how to do it was harder still. And all the cool technology in the world was valueless unless you had a way to use it properly.
The best part? When I run across a customer who's using these services, not only do they like the arrangement, the discussion is more around "what do we do next?" rather than "how do I fix this problem?". That's a good place to be in.
It's the same situation, only more extreme, when we get to complex high-availability environments.
There's the need to assess the business context and what's being done today. There's the task of creating a "protection services level catalog" that spans everything from casual backups to multi-site replication. There's the fun task of creating the business case and the justification. And, of course, designing the architecture and migration plan.
And that's just for starters.
The real value -- besides getting these environments up and running -- is keeping them running and knowing that they work. Not everyone knows how to implement business continuity so you can test it in the middle of a workday. Or keep an eye on application-dependency spider-webs to ensure you're protecting entire business processes, rather than individual applications.
Or understand how newer technology (like CDP, or dedupe) can fit into the environment. Or the valuable interplay between archiving and backup/recovery/and replication.
All valuable skills, all hard to find, all hard to keep in place in critical mass over a sustained period of time.
Hence the need for managed availability services. EMC can create the critical mass to take you from a "have not" to a "have" with regards to business continuity.
But what's the end goal here?
The Goal Is (Was) Skill Set Transfer
Look, at the end of the day, we don't want to be seen as a services company, like IBM or EDS or the others. We want to have the capability, and make it available to the customers who need it, but our real goal is enabling our customers to realize the full potential of the technology.
Our starting assumption was that customers want to be self-sufficient in these areas. And we constructed our offerings around the ultimate goal of self-sufficiency in any of the areas we offer services in.
That's a bit different approach than a pure services company. I don't think Glass House, or IBM Global Services, as an example, want their customers to be self-sufficient from a skills and consultancy perspective -- it just doesn't support their business model, but it supports EMC's.
But, wouldn't you know it, many customers don't want to be self sufficient. They want to consume this stuff as a service, and not a product with a bunch of internal staffers keeping it running. They like the idea that a bunch of trained professionals, backed by a major IT player, can come in and keep the stuff working at optimal levels.
And, I guess, that's not surprising. IT is finding itself needing to think more about the information, than the technology.
And, for those folks who are using services like these, they've not only built an important capability for their business, but they've freed themselves to focus on business issues, rather than technology issues.
And I think that's a good thing ...
Quantifying a few of Chuck's observations about the business continuity "have nots", here are some statistics from a recent Forrester report "Six Years After 9/11, Most Firms Are Not ready for Another Disaster" by Stephanie Balaouras:
-27% of enterprises do not have a recovery site in the event of a data center failure
-23% of enterprises never test their disaster recovery plans
-48% have less than 50 miles separating their production and recovery data centers
So, these concerns are pretty widespread among the North American and European customers Forrester surveyed.
Posted by: David Buffo | January 10, 2008 at 02:10 PM
An interesting conversation.
I used to describe the haves and have nots a little different but in the end it's the right idea. The haves as you call them, generally were mainframe guys who came to computing with project management skills, with process orientations and all of the other attitudes you mentioned.
The have nots generally grew up from the Windows, LAN and some of the Unix environments. They were oriented around small farms of computing or installations that didn't have to be robust and they were okay with what the technology provided.
I think one of the things that has happened is that the LAN/Windows guys got themselves into a bit of a corner. They built up enormous amounts of large fairly inexpensive infrastructure without building up the necessary business process around it. And one day they found themselves running enormous amounts of the business on those systems and it had gradually become as important as those apps that had always been running on mainframes.
In some ways we have fairly inexpensive redundancy built in - afterall the Internet is built on this concept. If one thing fails, there are enough other resources still going that we're all okay. On the other hand, the smart money says that doesn't work for reasons of good governance in business. And companies are beginning to realize what they've got and that they need to do something.
I think you're spot on that this is an issue of skills transfer of teaching best practices, and leveraging our years of knowledge of how to do these things right and that we don't want to get into a big services business. Most companies cannot afford the IBM/EDS consultant gigs anyhow, but they can afford working with a vendor that can help them learn how to fish if I can mix metaphors here.
The challenge isn't so much the technology (hardware works now, and software is getting there.) The challenge is in making it all work together AND in getting the business and technology bits right. In our area of email archiving we see that too - companies have relied on IT to help them with archiving but as new regulations kick in, legal wants to have more control over those functions but wants IT to provide the infrastructure to make it happen. Companies are working through how to do that right but they want to get the skills and products from us and learn themselves.
Posted by: Joyce Tompsett | January 10, 2008 at 08:01 PM