Business Continuity

A lot of conversations have been going on recently regarding source code escrow and business continuity: here, here and here.

Wow.  Regardless of whether you’re talking about on-premise applications or SaaS “hosted” apps, business continuity is a pretty important issue.  Many organizational leaders are extremely worried about making sure that their infrastructure is stable enough to allow them to sleep well at night.  So they sink a lot of cash into various potential solutions in hopes that they’ll create a safety net.  Right now, for most customers and vendors, this safety net is built out of four potential components (some solutions aren’t conducive to all options):

  1. source code escrow (vendor out of business)
  2. insurance (vendor causes damage)
  3. warranties (solution doesn’t work as advertised)
  4. IP indemnification (solution infringes on rights of others)

Like any net, though, it has a lot of holes – gaps in the netting where stuff can slip through.  Even if you try to cinch the net tighter, it’s not a solid material – there are ALWAYS going to be gaps.  This is a hard lesson to learn, especially in the game of risk management and mitigation.  You’re not going to protect it all.  [It’s an imperfect analogy, but look at the Secret Service detail for the President of the US – he doesn’t walk around all day completely enclosed in bullet-proof material.  Rather, he’s protected by agents all around.  Once and awhile, something slips through, even after extensive diligence and effort.]  At the end of the day, therefore, you protect against what you can with the understanding that the only way to obtain 100% protection is to restrict operations by 100% as well.

The goal, therefore, is to find a way to mitigate the biggest risks, not just the low-hanging fruit and those that are most obvious – but those that can cause the most damage.  Which brings us back to losing access to software used to run a business.  This could be your desktop operating systems… it could be your word processing applications… it could be your CRM (customer/relationship management) application.  The key is to determine which applications are mission critical and then figuring out strategies to make sure that you have options available in the event you lose access.

This does not mean you need source code escrow for every application.  Microsoft Word, as pervasive as it is, isn’t the only word processing application available in the world.  It’s also not using a file format that is wholly unreadable by any other word processing application.  So if Microsoft Word becomes suddenly unavailable tomorrow, even if it was a hosted application (which it currently is not), having spent money on source code escrow will have been wasted.  You could probably more cheaply (and with greater efficiency) simply buy a new word processing application.  And guess what?  This is true for almost ALL of the applications that your business uses!  As Apple has been saying for their iPhones, “there’s an app for that.”  In fact, there are usually a dozen.  What you move to might not be your favorite, but it will get the job done in a cost effective manner.

So where did you need escrow?  In the past, it was for customized applications or those that required substantial and pervasive integration and implementation – something so ingrained in your environment that its failure would immediately and irreparably cripple your business.  Many CRM tools used to be of this nature.  They were so customized… so specialized… so deeply modified for your particular use that it wouldn’t be as simple as just grabbing a new one off the shelf and porting the data over.  But that’s not really how it is these days.  Data is no longer held in proprietary databases, it’s held in more generically available database architectures (like Oracle or SQLServer).  Competitors now are even building their apps using similar data structures to encourage customer poaching.  You can thus port your data efficiently and quickly if necessary.  Thus escrow has become an almost non-starter.  Eventually, you’ll have to move to a new app regardless – but with an on-premise solution, you can keep using the software until you migrate.  Source code isn’t going to get your data moved to a new application any quicker.

For hosted apps, however, the added risk is that you no longer have control of your data.  Even a daily backup doesn’t get you the application.  Source code escrow in this scenario was hopefully going to give you access to the code to bring up at your own site if the hosted vendor went away.  But wait!  It’s not OBJECT code escrow, it’s SOURCE code escrow.  Additionally, you’re not getting the support applications, either.  We need another option.  A way to provide a SaaS customer continuity in software use.

It’s brainstorming time.  I put out my suggestion in the comments of Frank Scavo’s post.  Now it’s your turn.  Speak loudly – get creative – no idea is too outlandish.  The comment area awaits your input!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s