Being on cloud nine refers to a state of extreme happiness. As a CIO, wouldn’t you be happy if your team supplied IT services demanded by your users, that were always available when needed and at an optimized cost? With all of the hype, your IT strategy must include the exploitation of cloud technologies. The topic of my blog is to provide you with some ideas specifically for enabling your application portfolio.
Over the past few weeks, I’ve seen a heightened interest in moving applications to the cloud. In fact, this week alone, I’ve received four inquiries. I see two approaches for cloud application enablement: “born in the cloud” and “existing application migration.”
Born in the cloud
Born in the cloud refers to a new application needed by your organization. The main benefit of born in the cloud is that you can build a “cloud-ready” design. There is a range of deployment models you may choose from, such as:
- Software as a service: The vendor has built a “cloud ready” version of their application (for example, Salesforce.com).
- Platform as a service – packaged application: The vendor’s “packaged application” is customized to meet your organization’s needs (for example, SAP).
- Platform as a service – custom developed software: An application is written to run on “cloud ready” middleware (examples include WebSphere Application Server, DB2 Database, and WebSphere MQ).
Of the three options, I foresee cloud technologies having the biggest impact on “custom developed software.” First, new programming models such as Ruby on Rails and PHP improve programmer productivity. Second, testing environments can be provisioned “instantly” and decommissioned at the end of the testing cycle, eliminating upfront investment. Third, cloud allows organizations to complete more thorough testing of applications, leading to better quality software. Many of you have suffered through severe application performance problems and production outages, which could have been avoided if the application was stress-tested before production deployment.
Existing application migration
Organizations that have been around for awhile have accumulated a portfolio of thousands of applications used to support the business. Today, CIOs spend approximately 70% of their budgets keeping those applications running. Many of you are looking at cloud technologies to reduce your “keep the lights on” spending. At the same time, many of you who have led modernization programs know that factors such as project priority, cost, and effort are likely to turn your existing application migration to cloud into a multiyear program. One methodology to migrate applications to the cloud consists of the four steps shown in the figure.
I describe each step in detail.
- Data Discovery and Assessment: The goal of this step is to collect the required information to plan the application migration. Data discovery involves collecting information about each application such as technical operating environment, software licenses, financials, data security classification, and application architecture. Assessment involves inspecting the collected data for quality and completeness.
- Transformation Planning and Design: The goal of this step is to discover which applications are the “low hanging fruit” to move to the cloud. Transformation Planning and Design involves reviewing each application to determine if it can be deployed in the cloud, the financial benefit, and effort. For example, let’s look at two web applications. App A is a simple application where web, app, and database components are deployed on a single server with no application interfaces. App B is a complex application where web, app, and database components are deployed on multiple servers. In addition, App B has interfaces to both internal and external applications. The assessment would conclude that App A is “low hanging fruit” and should be moved first. App B should be moved to the cloud after the “low hanging fruit.” Transformation Planning and Design creates a plan that identifies the application migration sequence to the cloud. To make the plan manageable, applications are grouped into waves.
- Migration and Remediation: The goal of this step is to verify that your application can be migrated to the cloud. A “sandbox” is created by partitioning part of the cloud. Then, the “to be verified” application is installed in the sandbox. Installation might involve taking a copy of the “virtual machine images,” restoring them in the sandbox, and performing minor adjustments, such as IP addresses. Installation might also involve provisioning new “virtual machine images” in the sandbox, deploying the application code and copying the business data.
- Onboarding, Testing, and Cutover. The goals of this step are to onboard the application to the cloud and decommission the legacy environment. Onboarding can include repeating Step 3 in a cloud partition designated for production applications. Testing verifies that the application onboarding was successful. In some cases, testing compares the results from executing the same transaction in the cloud and legacy environments. Cutover includes changing network settings, informing the IT helpdesk, and updating configuration information. Finally, after the application has had a chance to “burn in on the cloud,” the legacy environment can be decommissioned.
Conclusion
I think cloud is here to stay. The two approaches I described provide you with several ideas to “cloudify” your application portfolio. If you have an opportunity, you try both approaches. “Born in the cloud” gives your organization exposure to developing new applications using cloud technologies. “Existing application migration” gives your organization insight into what the beginning of a multiyear transformation program is to move from your legacy environment to cloud. Let me know what you think – do you have a plan to get to “Cloud Nine?”
