Can Vendors Play Nicely?

By Roger Lawrence, CTO Strategic Enterprise Services - South Pacific

 

It seems the Holy Grail for Cloud Computing, is vendor contestability. This is the ability to change service providers based on a commercial consideration. Think about it like you would the airlines. You use Qantas as a rule, and have negotiated excellent fares based on your volume of business, then Virgin offers a special for next week with lower fares. So you change service providers.

 

The following week Qantas lures you with a value added offer of upgrades, or more status bonuses for your common sectors, and you simply change back.

 

Sounds great, right? This week HP provides your customer relationship management, next week you use Sales Force, and then you shift to Dell’s new discounted offering.

 

What are the inherent flawed assumptions and the challenges with Cloud Vendor Contestability?

 

I can think of 3:

  1. A lack of cloud standards
  2. The cost of transformation
  3. Inherent risks to the business

Let’s discuss each one briefly:

 

1. Cloud standards

 

Cloud computing works on a premise of SOA otherwise known as Service Oriented Architecture. The general idea is that everything is offered as a service. For example, if an application needs to authenticate a user, it uses an authentication service. Rather than having its own directory and authentication mechanisms, the application simply consumes the service.

Think about logging into Instagram with your Twitter account. Instagram doesn’t need its own authentication service, it just passes the request to Twitter.

 

One of the issues we have is that there are very few standardised services for cloud computing. There are very few standards in place for provisioning services, billing engines, enterprise grade authentication services and even for applications themselves.

It’s more like the global consumer electricity supply. Every country you go to has a different voltage, phase and frequency of supply. Don’t forget to pack your plug adapter.

Furthermore, there is no incentive for vendors to standardise. Why would Microsoft ever provide the same database structure, taxonomy or UI on CRM as Salesforce?

 

We can further compare the potential of standardisation to that of cars.  Over time, driving interfaces became standardised that way you can purchase a different car and drive it without retraining. We may be able to extend this analogy to software interfaces. Even so, standardised services, interfaces and data structures are still a distant dream. Consider the investment software vendors are making to shift from licensing, on-premise business models, with support annuity revenue streams; to elastic, cloud-based, evergreen, subscription models. They will do all in their power to grow, and keep their own customers.

 

This raises a question: Do we need a regulatory drive to force software vendors to standardise?

 

2. Transformation

 

In my earlier analogy, I compared airlines as business service providers to cloud computing providers. Of course the flawed assumption I implied, was that transporting someone from one place to another, was equivalent to supplying a CRM system.

But it’s not.

 

Instead it is more like supplying an office block. You wouldn’t change office block providers from one week to the next, because of the amount of furniture, people, documents and other items you’d need to shift from the one building to the other.

Transforming IT systems isn’t as simple as exporting data, transmitting it to the other system and importing it. The bandwidth required for that would be significant enough on its own accord.

 

But transforming systems to other providers requires mapping data, cleansing it, verifying its integrity and determining what to do about dependent systems.

 

In short, this is a mammoth task. Again, vendors are not incented to help you transition out of their facility either. As far as I know, we are the only enterprise player that has standard de-provisioning clauses and rates.

 

Even so, this is hardly likely to be a weekly, monthly or even annual exercise—depending on the system.

 

3. Business Risks



There are a couple of inherent business risks to changing cloud service providers.

 

The first one includes loss of productivity resulting from system interface changes. Think of the last time you upgraded Microsoft office, and how long it took for you to become productive again. This productivity slump occurs despite all empirical evidence that the latest version was easier to use than the previous version.

 

Now multiply that across all of the IT systems you use.

 

Now multiply that number with the number of users you support.

 

Until the interfaces are identical, it will be challenging, and costly to keep shifting platforms for users to use.

The second risk is that of SLA’s. Different providers may provide lower costs, but they also provide varying levels of service level agreements. This could significantly impact the business if a system failed, or even needed upgrading.

 

Conclusion



Vendor contestability is not here yet with Cloud Computing service providers. Until they have an incentive to play together (like the Mobile Operators with SMS at the turn of the century) vendors will continue down the path of differentiating themselves, and in the process lock in users.

 

Ultimately we need to remove ourselves far enough away from the client-server architectures of the ‘80s, and migrate to service oriented architectures. We need to abstract the presentation layer, the business logic and the compute layer so a client can keep their storage on-premise. Then we need to look to switch the business logic to an alternate provider and maintain the presentation layer. Until we take these steps, we will be barking up the wrong tree.

 

Currently contestability takes place at “down select,” and/or contract negotiations.

 

If contestability is in your IT strategy, you need to shift your organisation to a services oriented architecture. Then consider the apps most likely to be contestable over time, and architect for that eventuality.

 

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Roger has been trying to get out of Information Technology since programming COBOL on mainframes in the late '80's. But no matter in which c...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation