Eyeballing the idea of outsourcing some IT functions to the cloud? If you want to avoid the cloud raining on your enterprise parade, you'll need the protective umbrella of some thorough advance planning.

In an industry that's been fond of technology fads for decades, cloud computing looks like one that might actually stick around for a while. Although choosing a cloud service provider (CSP) might seem like a decision little more complicated than choosing a software package, there's more to it than that. Hopefully, here you can find some guidance in figuring out how to make a good choice.

Let's first assume you've already made the decision to buy cloud services, rather than building a private or hybrid cloud infrastructure of your own that you may or may not sublet to other companies. "Building" means you're getting into the business of being a cloud provider yourself, which presents a completely different layer of challenges that we won't address here.

Strategic Alternatives

The next big decision is exactly what services you're going to outsource. The stable of "as a service" cloud offerings now includes not just software and platforms or other infrastructure, but also storage, security, data and databases, test environments, APIs, back-end services, and workstation virtualization.

Choosing which services to commit to the cloud is more important than it may seem, because on a certain level, you're restructuring how you do business. The changes to your business won't necessarily be drastic, but going to the cloud will definitely cause some. That makes moving to the cloud not just an IT concern, but a strategic move that touches executive, sales, marketing, and other functional enterprise areas. The decision should be treated as such, the subject of thoughtful planning.

If your enterprise is big enough, consider undertaking a cloud conversion project with a task force that includes representatives of all the stakeholding areas of your organization. For one thing, you don't want to overlook anything that will be a major stumbling block later. For another, you want to be sure everyone is on the same page about ceding to a CSP a portion of the total control over your infrastructure that you have now.

Next comes a long series of strategic questions to which you need to give yourself honest answers. What are your corporate goals in choosing a provider? Saving time or money are the only real justifications for using a CSP. How much of both are you realistically expecting to gain? What kinds of services do you need? Are there some parts of your business for which cloud might not be a good answer? Are you going to outsource "mission-critical" functions or just some peripheral ones? And what does "mission-critical" really mean to your enterprise?

The size of your organization is important, too. Does your volume of users (which may include customers and trading partners as well as internal end users) justify using a CSP? If that number is under several dozen, probably not. Another concern is that if your business is too small, you may not have enough clout for a CSP to be flexible about customizing your service or your contract, both of which can be critical to a successful implementation.

How quickly do you need to have CSP services deployed? How much uptime do you need to be guaranteed for your apps? How much risk are you taking on by handing control of your outsourced systems to an outside party? How will the role of your IT department change depending on how many services you outsource? Who will be responsible in your organization for administering the relationship with your CSP? How will you track your own resource usage to be sure you're not being accidentally overcharged once you have a CSP, and who internally is going to be responsible for that oversight? Who will be the internal "owner" of your data? These are ducks good to have in a row before you even talk to your first CSP.

Tactical Decisions

Ideally, you'll want to start with one provider and implement an outsourcing program in stages. Realize that you may eventually have several CSPs that handle different services, but that's in the future. However, sampling different vendors for different services right off the bat probably isn't a good idea. It sounds smart, but managing all those relationships can quickly become a problem in itself that can "cloud" the whole outsourcing issue. Procedures you may develop for working with one CSP won't work with all CSPs because there really isn't enough standardization in the industry yet. CSPs don't all charge for services on the same basis, there isn't a universal model for CSP services, and the choices between public, private, and hybrid clouds don't mean the same set of services in all contexts. It's probably best to focus on one relationship at a time unless you have compelling reasons to do otherwise.

Naturally, you'll want to at least compare prices from several different CSPs, but the lack of standardization means you have to be wary about the meaning various CSPs may attach to similar terms. For one thing, does the CSP charge by the hour or by transaction? Don't forget that "transactions" will include your sending new customer and product information to the provider's servers as well as receiving back order confirmations, payment data, and so forth.

What other services will be necessary? For example, who will carry out the initial integration of back-end data with in-house systems? How about over time as changes might be needed? Will end-user training be required, and if so, who is responsible for that at what cost? Are there consulting or other services that might be required to iron out procedures at the start? Are there special costs associated with staging the implementation and integrating the non-cloud elements of your business?

It's a good idea to do a cost analysis over several years that takes into account not just the cost of acquiring services, but the transaction, network, professional services, and other fees that will be required over the life of the contract. Then compare that to your projected costs of making no change. Does your justification for making a change still hold?

Additional Information Resources

There are a few third-party sources of objective information about considerations in making a CSP selection that you'll want to check out, although there may be fees associated with accessing some of them.

ISACA (formerly the Information Systems Audit and Control Association) offers ISACA IT Control Objectives for Cloud Computing, an educational resource document for IT professionals that provides a good overview of what ISACA considers should be expected from a CSP. The NIST Cloud Computing Synopsis is a paper from the U.S. National Institute of Standards and Technology that explains cloud systems in non-technical language and makes recommendations for cloud users at all levels. The Cloud Security Alliance Controls Matrix offers a discussion of cloud-services security concerns for both providers and consumers. The Jericho Forum, a membership organization of senior IT officials, has published the Jericho Forum Self-Assessment Scheme (SAS), a protocol that helps users check the effectiveness of IT security plans, including those involved with cloud computing.

While you're at it, there are also documents someone at your organization should read about professional standards that relate to cloud-computing services, because you'll want to know if your prospective CSP meets them.

ISO/IEC 27001 is an international standard for forming an enterprise's information security management system that spells out control objectives, management responsibilities, and auditing procedures. ISO/IEC 27001:2005 specifies the requirements for establishing, implementing, operating, monitoring, reviewing, maintaining, and improving a documented Information Security Management System. COBIT 5 is ISACA's framework for governance of enterprise IT. SAS 70 is an auditing standard developed by the American Institute of Certified Public Accountants (AICPA) that specifies controls and safeguards that service providers must meet for hosting or processing customer data, which is required under Section 404 of the Sarbanes-Oxley (SOX) U.S. financial-reporting requirements law. MSPAlliance, the international association of managed service providers, offers the Unified Certification Standard (UCS) for Cloud and Managed Service Providers, a voluntary set of standards for vendors in the managed services industry.

Specific CSP Attributes

Once you feel you have a grasp of the larger issues, it's time to start evaluating any CSPs you might be considering working with. This step brings with it a new set of questions, some of which will have subjective answers.

Does the CSP have sufficient technical expertise? Does it have a successful track record of at least two years in the CSP industry? Does the CSP understand your business type? Does it have expertise in your market segment? Does it have experience with your size of organization? What professional services does it provide to help with your transition? How many data centers does it have (just one means it's potentially more vulnerable to outages)?

What are the CSP's total capabilities? Is the CSP limited in its geographical service area? Do you need your CSP to have international experience? Does the CSP have documented policies and procedures for such service aspects as service changes, event handling, billing and reporting to clients, and providing physical, environmental, and logical security? What's the quality of their hardware?

Then, naturally, there are the usual questions one has in choosing any type of provider. What's the general reputation and financial stability of the provider? Are there some customer references you can check? What's the provider's current level of customer satisfaction? Will there be a specific person at the provider responsible for your services/implementation (not just your "account")?

How does the CSP's pricing compare to its competitors? Don't forget that you may be comparing apples to oranges. If price is based on usage, how does that compare to your current costs? If based on hours, how many hours per day will you really be using the service and what will that cost? What will the charges be over time for such tasks as customizing software, cleansing data, or adding services not spelled out in the initial contract? What are the CSP's payment options? How much bandwidth will you need to handle your enterprise traffic? Will you be paying by the hour, per transaction, or some other metric?

The Heart of the Matter: SLAs

Low prices may mean too much wiggle room in the service-level agreement (SLA), which opens up another realm that can be rich with pitfalls. The SLA is possibly the most important part of your agreement with the CSP, so it deserves careful scrutiny.

A key part of any SLA is the amount of guaranteed uptime. While 99.7 percent or better uptime is minimally acceptable, it's important to determine how the CSP is defining it. What's the measurement period for uptime performance? How long can service be interrupted before it's truly considered "downtime"? How are incident notifications handled? Too little granularity here can be a huge problem later.

What are the provider's other SLA terms and conditions? Can they be customized for you? How many and what kind of customer support services are included? What constitutes noncompliance with the SLA and what are the penalties for that? Is there a clear differentiation of duties performed by your staff and the CSP's? What happens if a midday outage occurs? What happens if a data breach occurs?

Are customization of services and software covered in the SLA or somewhere else? What happens if you want to upgrade the third-party software you're using to a new version? What if you want to upgrade in-house software running on the CSP's servers? How is that handled and who's responsible for making sure that everything remains integrated?

Can your CSP provide services that meet certifications such as PCI-DSS (payment card data encryption and security), the Health Insurance Portability and Accountability Act (HIPAA), or other standards that may be specific to your industry or markets?

Will the vendor provide a sandbox environment for you to test in before full implementation? What are the disaster recovery and failover plans of the provider? A promise of 100 percent uptime is meaningless if the provider doesn't have an HA/DR plan.

Parsing the Technical Issues

Of course, you can't forget technical issues that may seem like mere details compared to the other, bigger questions that have to be answered, but the technical matters also have to be clarified.

How are users going to be connected to resources? What policies does the CSP use to determine which users access which servers? How well is your data going to be isolated from other clients' in shared environments? How does the CSP handle load-balancing between servers to keep the needs of other clients from slowing down your application response times? Will your users be able to connect to your applications easily via mobile devices?

What will be the procedures for adding new trading partners to your systems if that's necessary (otherwise known as "supplier enablement")? Will you be able to maintain audit trails on changes to your own data? Do your applications need to use Web services? How will Web services use be handled, and how will where those services are located affect your transaction numbers? Are the user interfaces and menus for end-users and administrators easy to understand and use?

While we've covered a great many questions here, there are always more. Because your business is unique and so are your needs in a CSP, there could easily be hundreds more that you need to ask to be sure a CSP is the right fit for your business needs. Someone in your organization needs to explore what those might be. You don't need to believe in Murphy's Law to know that the question you forgot to ask could end up being the one that comes back to bite you.

Into the Future

How things will work for you in a cloud environment on day one isn't going to be the end of a project; it's the start of an ongoing relationship. As with anything, over time circumstances can change, both for your enterprise and for the CSP. So there are a few more points to be sure to cover.

How hard will it be to drop the provider if they don't measure up? Does your contract spell out everyone's responsibilities if there needs to be an exit strategy? How often will the provider be sharing performance data with you, and what happens if that data isn't satisfactory to you? How easy will it be to migrate your apps and data if you decide to switch CSPs later, for whatever reason?

Does the provider have a long-term cloud strategy for its own business? What are your guarantees if your CSP is later acquired by another company?

Can your CSP extend your services smoothly if your enterprise expands in the future? On the other hand, don't take on more services than you really need up front. You don't want to be paying for extras if that growth turns out to be farther in the future than you currently anticipate.

Finally, after all is said and done, before you ink that pact, you have to ask yourself if you trust the people into whose hands you're going to place an important piece of your business. If the answer is anything other than "yes," all the other questions become irrelevant.

If you're interested in a list of CSPs who provide service for IBM i users, please see "Technology Focus: Cloud Service Options for IBM i."