Migrating applications to the cloud requires a business service approach

Guest contributor Jeanne Morain outlines four steps of a business service approach to migrating applications to the cloud.

Security, compliance, and automation are top of mind for executives trying to plot their journey to the cloud. With all the marketing hype and mis-marketing the term cloud has become as overused as Coke or Kleenex. How does one cut through the proverbial "Cloud Clutter" to identify key insights, trends, and prescriptive guidance for migrating their current business applications and systems into dynamic service portfolios that cater to user centric computing? How do I avoid the political pitfalls that have created challenges in other cross siloed initiatives such as Business Service Management?

Many of the customers, technologists and industry luminaries my colleagues (Andi Mann, Kurt Milne, Shinji Yaguma) and I interviewed during our research on Visible Ops Private Cloud and Client4Cloud - were/are faced with these very questions. The answer is it boils down to identifying and creating key processes around what the services are intended to solve for the users (who), the content being distributed (what), context or environment in which the services will be used (how and where), and the goal the services are trying to accomplish (why).

The more successful companies followed a few basic principles that enabled them to understand their service requirements. First they mapped their journey based on needs of the business not technology. Fundamentally they shifted away from a machine-centric to a business-and/or user-centric approach. A major paradigm shift is underway, driven by new regulations, digital native users, and the advancement of enabling technologies (virtualization, mobility, cloud). What was most evident during the research was the required shift from operations to planning, delivery, orchestration, and optimization of services in lieu of systems.

Figure A

Successful architects/business analysts must understand from a macro level the four layers of the stack:

  • Infrastructure (Cloud)
  • Management (Fabric)
  • Containers (1:1), and
  • Users and licensing implications across those layers

Each layer should be set up like building blocks to enable the business analysts to easily select and implement the appropriate implementation route to meet the needs of that service. For example, an insurance claims agent application may require physical desktops and/or the ability to check in/check out the user environment due to the disconnected nature of the users. While a service based on health information exchange for physicians and their patients will require a hybrid cloud approach and more connectivity. IT should have the ability to identify, based on the services in their portfolio, how they establish slices of compute to facilitate those services -- whether physical, virtual or cloud (combination) in secure fashion.

  • Infrastructure/Cloud: The cloud should provide succinct slices of compute on demand that can be expanded to leverage external environments (hybrid bursting) based on policy and automated workflows.
  • Fabric/Management Framework (Orchestration/Optimization): Provides the glue that enables IT to manage the infrastructure/cloud down and the Apps/Users Up by controlling the containers, their consumption, access, and movement across clouds, devices, networks.
  • Containers (Apps, Data): The containers can either be a dedicated compute environment () per user such as Virtual Desktop Infrastructure (VDI) or a many to one compute environment (N:1) Compute such as a Software as a Service Application. The key is understanding what the container is, how it is used, to be accessed, created, and the contents tracked (who, what, when, where and how accessed).
  • Users (Who, How, Where): In order to define a service the architect must understand who the target users are, how they are accessing the applications (connectivity, devices, locations), and where they need to access it from (any restrictions - public versus private domains).
  • Licensing (Should, Can, How): Across each layer of the stack - architects/analysts will need to understand what the license implications are for the applications, data, and access rights. Orchestration and visibility of license posture is critical to ensure compliance across business, regulatory, and security directives. More often than not just because it is technically possible to run an application on the cloud doesn't necessarily mean it is legally possible within the realms of the license agreement.

New paradigm requires a new approach

The traditional static technology approach will not suffice in the Business Service Centric paradigm. During my research for Client4Cloud, I found that top performers took a very different approach to solving the service dilemma. They started with the Business Service Requirements first - understanding the desired return on equity, regulatory and security requirements. They also identified the user, context, and content.

Figure B

Step 1: Create a triage team

This has led to quite a few debates, political battles, and mistakes made along the way. Who owns the responsibility for the application, for the infrastructure, for user access? The lines are not as clear cut as they use to be, as many of the technologies are merging. Desktops are running in the data center, applications are moving from client/server based to software-as-a-service, hosted completely in the data center, and data increasingly a concern for audit. Every part of the business is impacted by the new paradigm shift and needs representation on impact. To be successful, the brave new paradigm requires cross functional participation and cooperation.

Step 2: Move away from the machine: Shift focus to the user and business service

Although the machine centric approach has served IT well in the past -- it needs to be left there. The cloud, like the MP3 player, has revolutionized how people can and want to consume applications. Today's Digital Natives are not any more technical than their predecessors, but they are more engrained in technology. They have learned to use technology during their formative years when they were learning to walk, talk, and breathe. As a result -- they expect to be able to move freely between devices, applications, and networks without having to worry about restrictions from IT. They will push IT and the machine-centric system to the brink of extinction -- not intentionally or with malice, but because it is part of their DNA, just like walking or talking. Understanding what they are trying to accomplish, why they are trying to accomplish it, and enabling their work/thought patterns will be critical to ensure they are productive and not putting the company at risk. At the end of the day -- CEOs, surgeons, and teachers  just want to do their jobs without worrying about the technology they need to do it.

Defining the requirements of the service (who it is for, what they are trying to do, how and where they are doing it, and the goal of the overall solution) is the first step.

Step 3: Understand the risks BEFORE migrating applications to the cloud

The cloud offers a variety of options for migrating applications. There are many tools on the market that enable lifting and shifting workloads from the private cloud environment to public or virtual private clouds hosted by providers. What these options do not cover, though, are visibility into the license implications or risks associated with migrating applications to 3rd party environments. Most cloud providers have a "Bring Your Own License" policy that places the risk back on the enterprise. Software vendors set policies on what applications can actually be run in a public cloud (such as Microsoft License Mobility) and some require additional fees to support the hybrid approach. Most operations managers are not necessarily the license/procurement experts. So, although they understand the application implications, they may not have a full picture of the license or legal risks,  and traditional asset management tools will not help. The more successful companies put sophisticated workflows in place to help reduce the risk of bursting workloads, applications or data that is protected by either regulatory or business policies.

Step 4: Carefully define routes to implementation with a small pilot

Defining the appropriate routes to implementation will take time and analysis based on the user, business, regulatory, and license requirements for those applications. Understanding what the usage patterns are, how customers do and don't access their applications will help determine where to start, what applications are good candidates and which are not. For example, one customer interviewed had a cloud/VDI-first policy.  That was until they realized that for field employees that were deployed into low link regions with limited access to the internet. In this case the business hired a consultant to counteract savings for VDI/cloud resulting in lost productivity of employees. Start with a small pilot to validate assumptions, determine what processes can be automated (which need to be adjusted), and the best path forward for your service.

*Note: The research, summation, etc. of the above was taken from Client4Cloud (2011) and Visible Ops Private Cloud (ITPI, 2011).

Author Jeanne Morain is Director of Strategic Alliances for Flexera Software. Prior to joining Flexera Software, Jeanne held various marketing, strategic alliance and product management positions with VMware and BMC (Marimba). She has over 15 years experience in Systems Management, Virtualization and Cloud Computing implementing solutions for millions of users across fortune 2000 companies (Enterprise and ISVs).