There is a lot of talk about disruptive technology and disruptive innovation – not only in the context of fundamental technology changes, but also in the context of innovating your business by being disruptive.
Cloud Computing has a potential for fostering such innovation in business, for various reasons:
- It makes IT services available to organizations that never before could afford these services. This is particularly relevant to SMBs.
- It provides rapid adoption of new services, thus enabling rapid innovation.
- It allows companies to concentrate on their core business and competitive advantage, instead of baseline IT.
- It allows forgetting about discussions and historic decisions about IT vendors and platforms, instead concentrating on the service delivered, (more or less) regardless of the underlying platform.
However, there is another notion of “disruptive” Cloud Computing can bring to business. It might become disruptive to the business itself. If you have ever read a standard contract of a Cloud Service Provider (CSP) thoroughly (and cloud business is about standard contracts), you have probably seen a number of points in there, which might become challenging to your business.
Look at the parts of the contract that cover topics such as end-of-service, changes to the service, or availability. According to their contracts, many CSPs could go out-of-business at virtually any point in time. They can change their services, typically with short prior notification (if they notify at all). And their guarantees regarding availability might not meet your requirements and expectations.
Furthermore, you will rarely (not to say never) find sections that guarantee upwards compatibility of the APIs (Application Programming Interfaces) provided by the cloud service.
Is this all bad? Not necessarily. To some degree, there are good reasons for these contracts (aside from the potential liability issues). A benefit of Cloud Computing is the flexibility of changing the service rapidly for improved capabilities, but also for improved security. Clearly, a common three-month patch window we observe in many organizations (and in others, far longer or fully undefined) is not sufficient anymore in these days of zero-day attacks. In addition, availability of cloud services is commonly far better than of internal IT services, at a fraction of the cost of implementing high availability.
On the other hand, feature changes might become massively disruptive. They might lead to a huge increase in help desk calls, when users are confronted with a new user interface or some features are somewhere else now. These changes might prevent applications from working at all. They might remove features some customers relied on. The CSP might argue that virtually no one used a particular feature. However, if you are among the 1% who did, it doesn’t help you at all knowing that 99% never used that feature.
When APIs are changed, this can affect integration between cloud services or between a cloud services and your existing on-premise applications. It also, as with any changes, might affect your customizations. The typical argument is that the advantage of cloud services is that they provide a well thought-out standard set of features in areas where you will most likely not gain a competitive edge by customization. I’ve heard this argument in various forms several times. Yes, ideally an organization relies on a standard service. However, to pick a common example: in most services, you must customize. Just think about your own sub-sites and libraries in Microsoft SharePoint on Office 365. Moreover, most business applications, such as CRM in the cloud, ERP in the cloud, or service desk in the cloud, do not exist in isolation from the rest of the business. There is a need for integration.
So what can you do?
On one hand, CSPs should understand these issues. At least the APIs must become upwards compatible. That requires more thinking about the APIs that shall be exposed upfront. It requires better software design. But it is feasible, maybe with the one or other issue when a major upgrade is done. The same holds true for customizations. These must work well.
On the other hand, if the APIs change or customizations might get lost – or when features are discontinued – there must be a notification way ahead, so that customers can prepare for that change.
For customers, the reality of standard cloud contracts means that they must prepare for such unwanted changes. There must be an exit strategy if a cloud service is discontinued or a CSP goes out of business. Customers must think what to do in case of availability issues. And they must do their customization and integration work while keeping in mind that things might change. They must be aware that relying on a cloud service, particularly SaaS (Software as a Service), might become disruptive to their business.
It is not that relying on the Cloud is bad. If customers do a fair comparison of cloud services to their on-premise services, they will find many areas where cloud services score far better. However, not everything in cloud services – and particularly not everything in the very unilateral (in the sense of “unfair”) standard contracts – is good. If this is well understood, customers can benefit from Cloud Computing without disrupting their business.