Outsourcing Disasters or Disastrous Outsourcing!

I read with interest the recent posting by Claus Mikkelsen, Outsourcing Disasters about disaster recovery (DR) planning and how little overlooked details can bring you down.

His posting reminded me of the blackout day when I was stepping out of the building of a power utility company right when everybody in the region lost power. Just few minutes before blackout, I was discussing with the company about DR data center.

The utility company was in the process of setting up a DR data center not very far from the main data center. In light of how data centers in NY/NJ were impacted during 9/11, one of my concern was the impact to DR data center operations in case something happens near main data center. Power failure was also one such point raised during the discussion. And I got an earful on grid resiliency from the utility company guy. When I found out the grid being the reason for blackout, I just thought to myself "How Ironic!"

As for the story of Simmons changing DR vendor because of blackout, cynic in me says that there is more to this story than just the reason given in the article (See Disaster recovery supplier dumped).

I can only hope that Simmons learnt from their experiences and performed extensive due diligence. Hopefully, this time around, instead of just looking at written contract terms, Simmons really performed an assessment of vendor DR plan and any cascading impacts to its own operations and DR plan. And also has in place regular testing of different DR scenarios.

My favorite story: The primary network of an hospital went down due to a worm infection. So the IT staff switched to backup network and worm took that down too! Finally hospital resorted to SneakerNet to transfer medical images to ER and ORs. The moral of the story is to have an alternate process in place that is architecturally and physically different than your primary process.

Many times, I have come across this. The companies are quick to outsource a function. They worry about contractual terms instead of performing real due diligence on vendor's ability to deliver on those contractual terms.

Research in Mockery (of Patent Law)

"When they took their final position on here's what we'll do it wasn't about money, they wouldn't give us terms that would allow us to carry on our business," RIM Co-CEO Jim Balsillie told an RBC Capital Markets communications, media and technology conference. See BlackBerry maker calls NTP's settlement terms 'crazy' (Accessed through Good Morning Silicon Valley blog entry RIM to NTP: Appease you we tried, now screwed you all will be)

Why should this company be allowed to carry on business? First, it violates the patents awarded to someone else to develop and market a product, then it uses the resulting revenues to start a legal fight to invalidate original patents. This case shouldn't be about whether NTP patents were valid or not. This case should be about whether RIM violated the awarded patents or not.

If RIM wins the patents battle with NTP, the loser will not be NTP only, the real losers will be startups, small companies and individual inventors. What prevents any company with deep pockets to violate patents of anyone?

Violate Patent + Make Money + Invalidate Patent = RIM

Who owns what?

It has been quite a while since I updated my blog. I typically write and update blog at home when I can dedicate enough time to think and write. With my recent schedule, I decided to give up trying to stay home long enough to write blog. I started writing this entry while waiting to board my flight home at Denver Airport. Last few weeks have been really hectic for me with trips to various cities, a botched SAN file system project and getting to know a new product inside out.

There is lot of stuff I would like to share with my readers, from Data Domain to Storage Management to my commentary on several interesting storage entries in blogosphere. I just need to find enough time to put my thoughts in Office OneNote.

The SAN file system project implementation was an interesting experience. The project was supposed to be simple and quick install. But everything that could go wrong, went wrong. Fortunately, in the end, everything was resolved to customer's satisfaction. In retrospect, everything came down to our overconfidence and in turn oversight of critical issues during planning. For me, the lesson learnt from this project was, even if someone is working in a team as a team:

• Someone has to take accountability,
  
• Someone has to take ownership, and
  
• Someone has to be an Octopus with tentacles in every pot! to know what is going on in each pot.

I also spent good amount of time learning and playing with Data Domain 4xx product. This wasn't some canned demo, I received a highly technical insight and experience with this product. In my opinion, if you think, compression can help you in your backup and recovery process, you got to take a look at this product.

Look for more thoughts on this product, technology and business strategy in future entries. To sum it up in few words, when I look at Data Domain today, I see VMware near its inflection point.