Cloud governance is about more than security

Cloud computing needs governance. Which is to say that cloud computing needs processes, policies, and procedures. In a way, this is no different from IT more broadly. But virtualization, dynamically moving workloads, and an increased reliance on third parties for many types of IT functions mean that well thought-out and documented processes, policies, and procedures tend to be more important in cloud computing than with a more static and manual environment.

This has been driven home to me in the course of speaking at lots of cloud-related events over the past few months and appearing on panels such as the one at HMG Strategy's CIO Summit of America in New York last week.

Governance for cloud computing is a big topic that I'll be exploring in stages over the next few months. I'm going to get started today with two basic points.

Security procedures and technology are part of governance, but governance is a broader concept.

Legal and regulatory procedures, transparency, service levels, indemnification, notification, and portability are all part of this bigger picture, especially as the discussion widens to include public cloud infrastructure providers and software-as-a-service vendors. It's all about mitigating risk associated with suppliers (whether supplying software for on-premise IT or supplying infrastructure in a public cloud).

Consistency and portability are two of the most important pillars supporting well-governed cloud architectures whether on-premise, public, or a hybrid architecture. These concepts are closely related but they're not the same thing.

Consistency refers to having a consistent runtime environment (such as an operating system or middleware) in different clouds, private and public. The same application should be able to run in both places. For starters, this means that you can take a given Linux, Java, PHP, or whatever application and the target environment(s) will have the supporting software and hardware infrastructure that allows that application to run in the same way in all these places. The bottom line is that the user of that application should not be able to tell where it is running. (Of course, the IT operations people need to know where workloads are running as well as specifying upfront where different workloads are allowed to run.)

One of the ways that consistency breaks down is that public clouds encourage ad hoc development that doesn't necessarily comply with an organization's standards for applications run on-premise. This may be fine for prototyping or other work that is throwaway by design. However, it's far too easy for prototypes to evolve into something more--as often happened in the case of early visual programming languages--and the result is applications that either have to be rewritten or that may have support, reliability, or scalability issues down the road. Just because developers find that a given public cloud environment offers the cheapest and easiest path to write and test an application doesn't mean total application life cycle costs will be lower. Public cloud-based development will happen though, so the best strategy is to recognize this inevitability and channel it in a way that fits within organizational standards.

Consistency goes beyond just technical factors though. Consistency between on-premise and public cloud environments also requires that the full runtime--including the applications running on it--be supported and certified by the same ISVs and others when running in the cloud or in the cloud, a commitment that is as much about business relationships as technical ones.

Portability takes multiple forms. Portable computing creates scalable private clouds that can be federated to a public cloud provider under a unified management framework. Portable applications mean that developers can write once and deploy anywhere, thereby preserving their strategic flexibility and keeping their options open while lowering maintenance and support costs Portable services simplify development and operations by eliminating the need to re-implement frequently needed functions in private clouds and enable the movement of data and application features across clouds. Portable programming models let existing applications be brought over to cloud environments or evolved incrementally.

And, as with consistency, there are aspects of portability that aren't primarily technical--such as whether software subscriptions and licenses can be transferred from one location to another. Consistent support and maintenance environments are also essential elements.

Organizations will use public cloud providers in various forms. The goal should be to govern that use, not block it.

If some of what I wrote above seems to focus on the potential downsides of using public cloud resources, that isn't my intention. The benefits offered by public cloud infrastructures operated by companies like Amazon and software-as-a-service offered by someone like Salesforce.com are well documented. In the case of infrastructure, they allow rapid experimentation and expansion. Hosted applications can often be brought online more quickly than conventional on-premise software and thereby start delivering business value faster.

And the reality is that cloud computing in some form will happen throughout all organizations whether it's the evaluation and adoption of a new CRM platform through a formal IT process, the ad hoc use of public cloud infrastructure by developers, or the "bursting" of an on-premise cloud to a public cloud to gain temporary capacity. Especially given the importance of properly securing data and minimizing lock-in to specific third-party provider, it's critical to bring cloud computing activity that involves corporate data or production applications under a common governance umbrella.

But, for the vast majority of organizations, simply forbidding the use of public cloud resources and applications is a poor strategy. For one thing, it cuts the organization off from the benefits of using those third-party providers. For another, that approach is unlikely to work. Shadow IT, which is to say unofficial use of personal mobile devices and free or inexpensive Web-based services of all sorts, happens.

So better to acknowledge that reality and, to the degree possible, make it an explicit part of overall IT governance. An IT organization might, for example, freely allow personal devices to access corporate e-mail but put in place mechanisms such as tokens that add a layer of security to that access. A final point worth making here is that, as one CIO told me, perhaps the most important process is to involve users in formulating the policies rather than creating an IT vs. everyone else dynamic.

Cloud computing isn't "risky" any more than IT more broadly is risky. Rather, like all IT activities, cloud computing projects should be undertaken in a way that both mitigates risk and that considers those projects in the context of IT as a whole while taking into account the ultimate objective: to support the business in a way that balances costs with benefits.