The future of enterprise IT has many names. You’ve probably heard it expressed as On-Demand Software, Hosted Software, Cloud Computing, SaaS, PaaS and whatever-else-as-a-service.
That’s the hype - what’s the reality?
The cloud is a trade. You give away a certain level of control and customisation over your business data and processes, and in return you get reduced IT costs, better infrastructure, and more expertise. If that seems like a lot of upside, it is - and it’s all thanks to the magic of core competencies.
Prahalad and Hamel wrote about core competencies in the 90s: the idea that a business should be built around what it can do better than anyone else. In the IT world, that idea developed into the outsourcing fever of the 2000s and finally into the cloud boom of today.
The message is simple: unless managing an Exchange server or fiddling with file permissions is what makes your business better than its competitors, why are you doing it?
The power of the cloud is that there are companies for whom building truly monstrous IT infrastructure is their core competency. They’d be happy to shoulder your burden, and carry it better than you ever could for a fraction of the cost.
But, as with any trade that seems too good to be true, you want to be careful that you’re not giving away the farm while gazing starry-eyed at the upsides. We need to address the other side of the equation.
There are some unlikely scenarios – such as your provider going bust – under which you might not get your data back. That could be years of sales records, gone. While that scenario is unlikely, there are more pernicious ways to be caught off guard. And this report concerns itself with the less obvious challenges.
What if you deploy a best-of-breed cloud sales solution, and a best-of-breed cloud accounting solution, and they don’t work together? You might end up paying just as much hiring people to write software to integrate the two.
Or worse still, maybe the cloud providers don’t offer sufficient API coverage to allow external software to access your data, so no integration is possible. Where does that leave you? Not in the best position.
For our cloud integration report, 'Which clouds play nice?', last week, iTnews assessed the 20 top cloud providers based on four questions.
1. Can I get my data in and out freely?
The first question -- data export -- is the most significant part of playing nice, and should be the easiest to get right.
Cloud providers generally return your data in one of three generic file formats (XML, CSV, TSV) but some only give you part of the data: for example, giving you CSV files without any IDs to connect them together, which is about as useful as a book index with the numbers rubbed out.
Fortunately, there’s a dead-easy test to see if the cloud provider you’re dealing with does any of these tricks: find out if you can export data from their system and then import it back in again. If they can’t even deal with their own data format, what hope do you have?
2. Does it integrate natively with other systems?
A native integration is part of a cloud provider’s core offering. The main problem with native integrations is that there aren’t enough of them.
Microsoft’s Office 365, for example, doesn’t integrate natively with anything, and neither does Dynamics CRM. In fact, of the CRM systems we researched, only Salesforce and SugarCRM had any native integrations at all.
There are also some problems that will crop up in any kind of integration. The big one is Auth ‘n’ Auth. Because abbreviations in the enterprise aren’t ambiguous enough, the Auths are short for Authentication and Authorisation. That is, “who are you?” and “are you meant to be doing that?” respectively.
3. What third-party integrations are available?
Non-native integrations are created by a third party who mediates between two cloud providers to synchronise data. For that reason they’re often also called third-party integrations, or simply middleware.
Although native integration is, frankly, better, there are some features that make middleware attractive, including availability and support for multiple platforms.
4. Can I write code to integrate with it?
If all else fails, or if your requirements are complicated enough, you might need to write code to extend a cloud service or integrate two cloud services together. When doing so, the main concern is the quality and comprehensiveness of a SaaS provider’s API.
An API, or Application Programming Interface, is the window through which a cloud service speaks to the outside world. It is, quite literally, the only way that code can communicate with that service. If what you want to integrate with doesn’t have an API, it’s time to pack up and go home.
With the technology sorted, we should turn our attention to the API’s comprehensiveness and its documentation. Unfortunately, there is only one number that really matters for this: API coverage. That is to say, the percentage of things you can do in the application that you can also do with the API. In a good API, this will be 100 percent.
Not all APIs meet that standard, though. In fact, most don’t. And many suppliers have outright lied to us about API coverage or refused to divulge a figure in preparing our report.
That means you have to look through the documentation to analyse what services are available through the API and whether it will be detailed enough to meet your needs. That’s a lot of work, which we’re attempting to save you by publishing this report.
Playing nice isn’t the only thing to worry about; security and reliability, for example, are significant concerns. But their consequences are big and obvious.
Not playing nice doesn’t lead to fired VPs and international news stories, it leads to subtle surprises, wasted time and quietly ballooning IT budgets.
This is an exerpt from iTnews' cloud integration report, 'Which clouds play nice', which we launched last week. The free report is available exclusively to iTnews subscribers here.