Do Standards Mask the Real Issues holding back Cloud Adoption?

Mimecast Chief Scientist Nathaniel Borenstein was in London a couple of weeks ago- and I took the opportunity to interview him about Cloud standards- since he knows a thing or two about standards.

Nathaniel had an interesting perspective- that a lack of standards aren't necessarily the problem with Cloud Adoption

httpv://www.youtube.com/watch?v=HOSkmauQhgE

Transcript:

Justin Pirie: Hi. This is Justin Pirie. I'm here with Nathaniel Borenstein, Chief Scientist of Mimecast. Nathaniel, you've been here in the UK this week talking about the standards and I wondered how much do you think standards are an inhibitor to businesses adopting to the cloud?

Nathaniel Borenstein: I think that standards are often an excuse that masks other concerns about cloud option. There are certainly some issues around standards, but the large number of organizations and applications that have moved to the cloud already are an existence proof that a lot things are reasonable to do in the cloud now. What happens is that a lot of times if an organization is leery of the cloud or has various fears around the cloud, standards are an easy thing to latch on to say "Oh we're going to wait for more standards" and if you can't be more specific about what standards are you waiting for you're probably not thinking very clearly.

Justin Pirie: So what is a good example of an application that isn't good for the Cloud, because we're always talking about things that are good of the Cloud, but what isn't?

Nathaniel Borenstein: Well there some things that really no amount of standards or engineering can possibly make suitable for the Cloud and my favourite example it’s a bit fanciful because it’s so obviously a bad idea but try to imagine if you have an implantable defibrillator that's sitting in your chest and has the job of restarting your heart if it stops. You really don't want any of that to depend on the Cloud, because any external dependency could kill you. So that is the worst possible application move to the Cloud and its characteristic of a class of applications, I'd call it real time, non-networked applications.

If you have an application that needs to act in real time, and isn't already dependent on the network moving into the Cloud adds to that dependency, it’s a bad idea. If it’s real time but already depends on the network, and you do it right the Cloud isn't likely to or won't necessarily make things worse, but if you're already not dependent on the network best stay that way.

Justin Pirie: So taking another angle, are standards an important part of preventing vendor lock-in, in the Cloud?

Nathaniel Borenstein: Well that's one of the most commonly cited reasons for holding off to the Cloud and for more standards are needed and it’s certainly a valid concern. And what I think that people fear is that their vendor will implement the services in such a way that is extremely hard to transfer their data and application to another vendor.

That can be the case but it rarely is. More often there are other factors that go to vendor lock-in. A good example that Mimecast does we do email management in the Cloud and if anyone ever needed to leave our service and go to another vendor, we would certainly work with them and make sure they can get the data but the issue wouldn't be one of format for the data or data transmission protocol. Formats for archive data have been around for a long time. Microsoft Exchange uses PST files. Lotus notes uses NSF files and while it might be nice to have a single standard for that, the pre-Cloud world got along pretty well without it and so can the Cloud world.

In fact the harder thing in that kind of migration is just dealing with the sheer quantities of data and you often have to send out technicians with disks because the network isn't up to the terabytes or petabytes of mail you might be trying to transfer. So what really turns out to matter more than the standards, not that the standards don't sometimes matter here, is your relationship and trust with the vendor. If you don't believe your vendor will help you leave them if it ever comes to that, then you probably shouldn't be with that vendor in the first place. You probably shouldn't go to that vendor.

Mimecast makes a promise to its customers that if they ever need to leave, we'll be sorry to see them go but we'll help them get on to the new location because that's a part of our professional service and it should be part of the professional standards for the industry and it should be perhaps in some cases even a legal requirement that vendors make this kind of data portability and service portability easy. Standards can be a part of that but I think very relatively small part of that.

Justin Pirie: Absolutely. I mean when I told people that as I say you got to think about the birth, marriage and death of contracts or divorce, and it’s a really important part of contracts that people don't necessarily spend enough time thinking about. But, if you think about the divorce before you get married i.e. with a pre-nup, then you can make sure you can get your data out well.

Nathaniel Borenstein: That's exactly right. The commitment that vendors like Mimecast try to make to our customers that we will help you if you leave it’s a lot like a pre-nuptial agreement and its designed to reduce the inevitable pain of the divorce.

Justin Pirie: Absolutely and of course we don't want a divorce.

Nathaniel Borenstein: No of course and I think we found that the more clearly and believably we make those promises the less often we have to fulfil them. Justin Pirie: Well thank you very much that's been really enlightening. You can check us out on the blog: blog.mimecast.com or @mimecast on twitter. Thank you Nathaniel.

Nathaniel Borenstein: Thank you.

FILED IN