Government policy-makers should level the playing field for cloud services

OVUM VIEW

Summary

Cloud services policies are being developed and iterated in all jurisdictions. Having reviewed a number of draft policies in recent months, we believe policy-makers need to work harder to create a level playing field for cloud services adoption, mindful of the potential for a type I procurement error (buying a “bad” cloud service) or a type II procurement error (buying a “bad” in-house, shared, or outsourced service, when a cloud service would have been better). Policies tend to be biased toward avoiding type I errors, so even in policies that are well-intended the playing field is tilted away from cloud services. Type II errors can, however, create worse outcomes, arising from missed or delayed opportunities for productivity improvement and innovation in policy and service delivery.

Innovation-minded governments need to level the playing field

The logic of government cloud computing policy usually starts with the implicit assumption that cloud services are risky, ill-defined, and unproven compared to other ways of sourcing ICT, such as in-house IT, internal shared services, and outsourced/managed services.

Cloud services adoption in government faces a steady headwind caused by procedural, organizational, and cultural inertia. The following five statements may help policy-makers to question their assumptions and strengthen government cloud services policy.

1. There is no cloud

As far as government agencies are concerned, there is no such thing as “the cloud.” The term may be useful in the consumer market as a trendy synonym for the Internet, but it has no place in government ICT policy thinking. Policy should refer to a “cloud service” – a tangible service delivered on a professional basis by a trustworthy external service provider.

2. Cloud computing and cloud services are different things

Cloud computing is the suite of technology innovations, including scalable infrastructure, virtualization, automation, self-service provisioning portals, and multi-tenant architectures, that is used by a service provider to build and deliver a cloud service. But there is much more to providing a mature enterprise-grade cloud service than buying and installing cloud computing technology.

A cloud service is an established bundle of processes, people, organization, and technology, which has been assembled and refined to deliver a well-defined and trustworthy shared service to many customers. Trustworthy, sustainable, cloud services require scale and are expensive and difficult to build and operate.

We often use the phrase “cloudy is as cloudy does” to make the point that a cloud service should be judged by what it is today. In contrast, a plan to buy and install cloud computing technologies – for example to build a so-called “private cloud” – is simply a promise that a service may exist in the future, if sufficient funding is available and implementation of the required processes, people, organization, and technology is successful and sustained over time.

3. “Private” versus “public” is the wrong way to view cloud services

Most policies start with a mechanistic taxonomy of cloud services as either “public,” “private,” “hybrid,” or “community.” This taxonomy is rapidly becoming an anachronism because the categories are indistinct and become more blurred as the service offerings mature. Worse still, it is often implied or explicitly stated that “public” cloud services are relatively unsafe for government, while “private” or “community” cloud services are safer. The track record of ICT project and shared service implementation failures in most jurisdictions proves that this very statement is a triumph of hope over experience.

One of the biggest benefits that cloud services can offer government is the reduction of implementation risk. The correct way to assess cloud services is not as either “public” or “private,” but rather whether or not they already exist – and are functional, reliable, trustworthy, and affordable. In short, does the service meet the agency’s business requirements?

4. The best way to understand cloud services is to showcase them in action

Policy documents often tend to be long on theoretical positions written by those with little or no hands-on experience of cloud services and short on real examples. This needs to be reversed. The most impactful way to explain cloud services is to show tangible examples of their use and to discuss the experiences of early adopters in the public sector. Ovum’s case studies reveal that cloud services are better, faster, less costly, and (overall) less risky than more traditional sourcing approaches. The first task for anyone charged with developing a cloud services policy should be to research and publish 10 to 20 examples of early cloud services adoption experiences within the relevant jurisdiction. When it comes to understanding the practical benefit/risk tradeoffs, seeing is believing.

5. Type II procurement errors are just as bad as type I errors, if not worse

Overall, we need to counterbalance the bias inherent in most cloud services policies toward avoiding a type I error. A type II error can be just as bad, if not worse.

The risks of procuring a “bad” cloud service are relatively low and can be contained by well-established risk-management mechanisms and shorter contract terms. However, the risks of “bad” in-house, shared, and outsourced services are well understood; they are often substantial, long term, and difficult to mitigate. The risk of a type II error in cloud service procurement is a deferred or missed opportunity for productivity improvement and innovation in policy and service delivery.

Potential transformational benefits should be fairly stated

A government cloud services policy should aim to fairly state the potential transformational benefits of cloud services and create a level playing field for agency adoption, mindful of the practical and long-term costs to government of both type I and type II procurement errors.

APPENDIX

Further reading

“Government cloud: agencies need shopping skills, not just cloud stores” IT007-000681 (December 2012)

“‘Cloud first’ raises expectations of innovation” IT007-000650 (September 2012)

“‘Cloud-first’ ICT policy is better for government than ‘cloud last’” IT007-000648 (September 2012)

“Cloud services are an organizational innovation, not a technology ‘silver bullet’” IT007-000644 (August 2012)

“Australian Agency chooses SAP for SaaS ERP” IT007-000637 (July 2012)

“It’s time to understand the organizational catalysts for cloud adoption” IT007-000634 (July 2012)

Practical Steps to the Cloud for Government Agencies, IT007-000629 (July 2012)

Adoption of Microsoft Dynamics by a Government Agency: A Case Study, IT007-000628 (July 2012)

Adoption of Google Apps by Monash University: A Case Study, IT007-000625 (July 2012)

Adoption of Salesforce by a Government Agency: A Case Study, IT007-000626 (June 2012)

“Questions that a Chairman or CEO should ask their CIO about cloud services” IT007-000618 (May 2012)

Why Government Agencies Need the Cloud, IT007-000618 (February 2012)

Enterprise Adoption of Public Cloud Services Is All About Pragmatic Tradeoffs, IT007-000616 (February 2012)

Author

Dr Steve Hodgkinson, Research Director, IT, Asia-Pacific

steve.hodgkinson@ovum.com

Disclaimer

All Rights Reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the publisher, Ovum (an Informa business).

The facts of this report are believed to be correct at the time of publication but cannot be guaranteed. Please note that the findings, conclusions, and recommendations that Ovum delivers will be based on information gathered in good faith from both primary and secondary sources, whose accuracy we are not always in a position to guarantee. As such Ovum can accept no liability whatever for actions taken based on any information that may subsequently prove to be incorrect.