Integration: Klingons vs. Elves

Integration is largely dismissed by those interested in purchasing software these days. Quotes like “don’t worry, we’ll make it happen” or “oh, it’ll all come together in the end” are heard in meetings as everyone rushes to sign the vendor’s contracts before the end of the fiscal year. Unfortunately, six months later the same people are saying “the vendors weren’t upfront in their demos with us!” and “I don’t understand what’s so difficult about all this, why can’t they just make it work!”.

If you’ve ever integrated different systems together, you know that integration is where the rubber meets the road so to speak. From a technical perspective, I’m not a fan of bolting two (or more) different systems onto each other and forcing them to talk to one another. However, many times it has to be done and if that’s the case, it needs to be planned accordingly. The best way I can explain an integration effort is this:

System 1, a.k.a. “Worf”: A Klingon who hails from the planet Kronos. Worf has been characterized as a “swarthy humanoid”, doesn’t like cold weather and enjoys a bloody battle. Speaks Klingon.

System 2 a.k.a. “Enel”: An Elf who hails from Valinor in Middle-earth. Wise and immortal, Enel is a skilled hunter and has pledged to preserve the world. Speaks Elvish.

Worf and Enel couldn’t be more different. In fact, they’re completely different in every way imaginable. So, how the heck do you make them talk to one another? Hire an interpreter (i.e. 3rd party software tool) to assist in the language barrier? What similarities does Worf have that Enel can understand (i.e. temporary tables)? What symbol of understanding can be passed between them (i.e. Web Services or APIs)?

To ensure that the Klingons don’t invade the Elven continent of Middle-earth and destroy an ancient civilization, it’s important that you get your Supreme Council in a room (i.e. project stakeholders) along with your Trusted Advisors (i.e. IT architects, etc.) and determine the best way (or ways) for Worf and Enel to communicate with one another before you join their people together as a nation. Otherwise, prepare for Worf’s battle cruiser to enter Middle-earth airspace and it won’t be pretty.

Are You Using “Test” Data in the Cloud?

Yes, you read that correctly. The word test is in quotation marks, as in “is it really test data that you have in the vendor’s cloud?”. Astonishingly enough, at least 85% of financial institutions are using live data in their test environments [1]. Could this be you and are you protecting your organization against a data breach effectively?

When a cloud technology vendor makes an offhand remark like, “yeah, we can create a test environment for you and load your test data into the cloud while we work through a Non-Disclosure or Proof of Concept agreement with your legal team”, be afraid. Be very afraid.

Now, I’m not knocking the technology vendors. In fact, to them this is a natural part of the engagement. What you have to be aware of is whether your company’s test data is truly “test data” or not. For example, if you’re in the financial or healthcare sectors where a data breach could expose Personal Health Information (PHI) or Personally Identifiable Information (PII), you should understand your test data thoroughly.

Once you understand your test data, think about putting together a more robust agreement with the vendor besides a Non-Disclosure or Proof of Concept agreement. Non-Disclosure and Proof of Concept agreements typically do not contain the language to protect your company against a data breach. A Master Services Agreement or Subscription Services Agreement should be reviewed by your legal or contracts team to determine if your company will be protected while using the vendor’s cloud if there is a breach with regard to the test data.

Karen Hsu of Informatica explains that “because data stored in a cloud-based ‘sandbox’ environment for testing purposes is vulnerable, it should be masked to protect sensitive information” [2]. She recommends using an automated masking tool to assist with the protection of your data. Regardless of what tools you use, your “test” data should be understood before loading any of it into a vendor’s cloud environment.

References:

[1] Dark Reading News. (2010, March). Live Data In Test Environments Is Alive And Well — And Dangerous. Retrieved from http://www.darkreading.com/risk/live-data-in-test-environments-is-alive-and-well—-and-dangerous/d/d-id/1133220?

[2] Hsu, Karen. (2013, March). Masking Test Data in the Cloud. Retrieved from http://www.bankinfosecurity.com/interviews/masking-test-data-in-cloud-i-1822

Unlimited Liability for Breach of Confidentiality in SaaS / Cloud Contracts

I recently opened up a contact form for readers if they had any questions about technology vendor management and I received this great question from a reader. It does step into the legal realm of contract management and since I’m not an attorney, please understand that my below response isn’t legal advice, it’s based on years of working with technology vendors and technology contracts.

Unlimited liability for breach of confidentiality: Is it practical to expect SaaS suppliers to accept that risk in this era of very public security breaches?  

It’s not unreasonable or impractical to include this type of language in your SaaS (Software as a Service) / Cloud contract. From my experience, including unlimited liability for breach of confidentiality in your vendor’s contract hinges on one thing: your data.  What type of data do you want to remain confidential?  Is there financial, corporate information, protected health information (PHI), or personally identifiable information (PII) being stored within the SaaS / Cloud product?  Where will the confidential data reside? Offshore, onshore, nearshore, offsite, onsite? If it’s a true cloud provider, your data will be sliced and diced on servers across the globe. Do you have the option of a private or hybrid cloud with this vendor? Will there be any vendor resources performing patch / breakfix / maintenance work to the product that will see this confidential data? If so, where are they located and what data would they see as they performed this work?

In addition to the initial research regarding the type of confidential data to be stored, it’s important to perform a complete risk assessment of the project and the vendor’s products in the beginning of the purchasing engagement (preferably in the sourcing phase, not the contracting phase). My most recent post digs more into vendor vetting and it includes a great video from Monte Ratzlaff, Security Manager, at the UC Davis Health System, who elaborates on the issue of vendor risk.

From a contractual standpoint, vendors typically take issue with unlimited liability of any kind. That’s not to say that you can’t add the unlimited liability for breach of confidentiality language in your contract for the first draft and see what the vendor comes back with as far as redlines. Vendor pushback on unlimited liability is to be expected and I would recommend finding a back fence position if they don’t accept it. This back fence position could be anything from including a monetary cap in the contract (i.e. the vendor will pay $1 million related to the breach and then you’re responsible for any fees over the cap) to other remedies that would effectively make your company whole in the case of a breach. If you’re in an industry such as finance or healthcare, a public breach of confidential information could have severe ramifications for your business and if the monetary cap is too low, your company will be picking up the tab for any additional fines past the amount of the initial cap.

Overall, I would say that it’s perfectly reasonable to include unlimited liability for breach of confidentiality in your company’s SaaS / Cloud contracts depending upon the type of confidential data to be stored and your line of business. However, keep in mind that many vendors may take issue with it, and if this is the case, be prepared with a back fence position that will protect your company.

A Few Hard Truths About Cloud Vendor SLA’s

From an IT perspective, cloud computing is amazing. Although, from a vendor management and contract management perspective, it’s not. Like a bad haunted house, it’s full of “gotchas” around every corner, not only in the contract language but in the SLA’s (Service Level Agreements) that don’t allow you to effectively manage the vendor when things go wrong.

What’s so difficult about cloud computing SLA’s? Well, to name a few…

1) Silver, Gold and Platinum are not your friends. When reviewing the contract, take a look at the SLA’s. Do you have a choice of “Silver”, “Gold” or “Platinum” service plans to choose from? It seems pretty easy, right? Yes and no. It’s like one of those burritos at the 7-11. They’re wrapped up nicely underneath those hot lamps in that silver foil. When you’re desperate, you’ll buy one, only to open it up in the car and realize that it’s a molten blob of artery clogging goo that smells like roadkill. It’s similar with these cloud service plans. If you have mission critical systems that will be running in the cloud, closely analyze these service plans and fully understand how your Sev 1 issues will truly be handled. Otherwise, you’re in for a bumpy ride on the burrito express.

2) Pray for 90.0% uptime and hope you get 91.0%. It’s really amazing that these vendors can get away with 90.0% uptime. What’s your company’s SLA around uptime? Do you have one? If not, it should be at least 99.99% (if not 99.999%). However, most cloud providers will fool you into thinking that 90.0% uptime ain’t so bad. Is it? Yes, it actually is. In fact, if you do the math (and this is pretty scary, so hold onto your hat) on 90.0% uptime, it comes out to 36 days and 12 hours of downtime per year (in a non-leap year). Can your company handle this much downtime? Really? I didn’t think so.

3) Everyone has the same SLA’s.  Everyone that purchases the product from the vendor is on the same version, and everyone has the same SLA’s. Going back to the Silver, Gold and Platinum plans, there is no deviation from these SLA’s and they’re mostly in favor of the vendor. So, what to do? Don’t choose the first cloud vendor that you met at that great conference in San Francisco. Put it out for an RFI / RFQ / RFP and see what each vendor’s capabilities and SLA’s are before buying.  It’ll save you heartache (and heartburn) in the long run, I promise.