Based on my observations, too many companies initially decide to adopt a technology because they fall for the hype surrounding it. They simply do something because their peers are doing it. This may be the real driving force behind Malcolm Gladwell's book, The Tipping Point (2002), but it seems obvious that it’s not a good reason to build a cloud strategy.

I wrote a few weeks back about revisiting your cloud strategy if you already have such efforts under way, but let’s back up that truck a few feet and consider things from the perspective of those just diving in. While the previous article posed a series of questions about cloud architecture strategies to help newcomers, they also can benefit from reading this one first to better set the context. (Also, let me direct you to an article that’s recently been posted on developing a cloud and mobile strategy that will facilitate the interconnection of those two ecosystems, here,)

So, when it comes to beginning to architect your cloud strategy, you first need to determine what you want from the cloud: whether it will be public or private or even hybrid; what components in your architecture are candidates; and then how to deploy, monitor and administer your cloud services. Many organizations prefer a private cloud for more sensitive requirements, such as a human resources application and personnel data. Some might find a public cloud more appropriate for an internal commodity service or one that they can offer to partners or customers, perhaps even one for which they may charge a fee to access. Hybrid clouds are generally considered to be some combination of public and private services, where an end-to-end process lives across both infrastructures.

Starting from the premise that as an enterprise architect you already have a holistic understanding of your corporate architecture, the next job is to make some important business decisions to identify workloads to move to the public cloud. Then, it's time to focus on the technology.

Business First!

When determining which services should go into the cloud, you need to fully understand the business opportunities behind the moves. The first step to take is to have a business discussion where the following questions are asked:

• Are we building an online application? If not, should we be?
• How quickly must this service go live to capitalize on a business opportunity or meet a challenge?
• What funding constraints are we working under?
• Does the application involve collaboration and sharing?
• Are there business opportunities for the services in the cloud beyond your own applications that use those services?

The answer to the first question should be straightforward, but you need to explore all avenues of your application. For instance, even if it's not strictly a Web application, how much of your application can be self-administered by users (your customers) over the Web? By making more of the admin functions self-serve, you not only may be able to save call-center costs, but your users may prefer it. However, providing this service will require you to place this functionality in the cloud, since more users will need access to it. Doing this has direct consequences in terms of authentication, authorization and security in general.

Questions two and three always rise to the fore in a cloud discussion. Obviously, the cloud is a fast and cheap (at least in so far as upfront costs are concerned) way to get access to infinitely scalable resources. If you’re facing an unexpected competitive threat, you may very well need to step on the gas – and the cloud gives you that capacity and avoid the internal rigamarole of requisitioning, testing and deployment, even assuming the business was willing to give you all the money you need as quickly as you need it to support a launch. In other instances, however, there may be less pressure to move quickly, and putting in the effort to build the internal infrastructure may prove out to have been a more cost-efficient down the road.

If your application requires collaboration between different users, groups or entire organizations, then a cloud solution is a good decision, whether you build it yourself for a specific function or leverage what already exists for mainstream requirements. For example, Google Apps is an excellent example, even for large organizations, allowing easy collaboration for documents, spreadsheets and presentations. Placing these applications in the cloud was previously impossible, and the results have had a direct business impact for both Google (positive) — and Microsoft (not so much).

Regarding the next point, don't be selfish. Ask yourself whether other business groups in your organization can benefit from the services you place in the cloud. Corporate reuse of existing applications has been a goal of almost every enterprise since the 1980s, with the hope of cost savings and increased return on investment. The cloud is delivering on this promise by helping us think about reuse during the design phase, instead of after applications have been built and deployed. Furthermore, ask whether your company can find new business opportunities by offering paid access to some of your valuable cloud services.

In the next blog (available here), I will explore the technical reasons to help determine which parts of your applications should go into the cloud. Stay tuned!