Cloud Source Blog
In This HP Cloud Source Blog, HP Expert, Christian Verstraete will examine cloud computing challenges, discuss practical approaches to cloud computing and suggest realistic solutions.

A roadmap to cloud enable applications

credit: freedigitalphotos.netAs I promised in my last blog entry, I’d like to take some time to discuss application transformation. Indeed when talking cloud with customers, the number one question I typically receive is how existing applications can be migrated to the cloud. I always stress that existing applications are not the only ones for which cloud can be used. I cannot stress enough that the cloud allows us to do new things, but the question on the migration of existing applications remains and should be addressed. Such migration is actually a process that requires a number of upfront decisions and several key steps. Let me take a minute to describe the two key decisions that need to be taken upfront:

 

  • First, it’s important to define your cloud vision, in other words, how do you see your cloud eco-system and what cloud types (private, managed, public) are you willing to implement or consume from. Through a cloud vision & roadmap exercise you can define whether you look more at consuming services from managed and/or public clouds, or whether you are mainly interested in installing a private cloud. You may obviously also plan to combine all three types of cloud in your cloud eco-system and take full advantage of converged cloud. Even if you decide to start in one place, take a long term view as you may want to add other cloud types later down the road and it would be unwise to position an application in one type of cloud to have to migrate it somewhere else six months down the road.
  • The second decision you have to take is define a small number of applications you want to migrate. Many companies have hundreds of apps, and ultimately want to migrate many of those, but you should really start with a small number, maybe something between 8 and 10. Look for applications that will be used for the forcible future and that have variability in their usage pattern so you maximize the benefit of moving them to cloud. You may also want to flag one or a couple applications you want to sunset and replace, but are we then still speaking about transformation and migration? Also take applications that should reside in the cloud(s) you are implementing first. Remember, you want to demonstrate the value of cloud to both IT and the business, so ensure such benefits can be experienced after the migration.

Once that is done and you know which applications you want to migrate, you will have to decide to what cloud you want to migrate them to. I typically propose the use of Geoffrey Moore’s core versus context criteria. If the application truly differentiates the way the enterprise operates, if it’s part of the companies key assets, it’s probably better to migrate the application to a private or managed cloud where you have a good understanding of the security, compliance and SLA’s you will receive. If this is a context application, in other words, one that you need to run the enterprise, but that does not differentiates you; this application may be moved to a public cloud for example. It’s up to your company to decide what is core and context for them and accordingly highlight where they want the application to run. Make sure you involve the business in the core versus context discussion as it’s from an enterprise perspective that this decision should be taken.

 

Once you know where you would like to put the application, two elements need to be taken into account. The first one is related to the data. All applications use data. So, is the data used by the application core or context? This is the same question than the one we just asked for the application itself and should be easier to take now the company has a clear understanding of what its core functionalities are. If the data is core, which means critical for the enterprise, and the application is core, it’s a no brainer. The same applies if both are context, although there, you may have to look at potential compliance issues such as privacy. The situation becomes interesting if the data is core but the application is context. You should then look at the level of interaction between the data and the application. How heavy is the interaction and how much is the application dependent on the speed at which the data is received. If bandwidth and latency are acceptable, the application may be put in the public cloud and the data in the private/managed cloud as originally planned. Otherwise things will have to be reviewed.

 

The second element to look at is how the application is actually structured. This will define the migration strategy. Is the application compliant with Service Oriented Architecture principles, in other words, is it written in modules that are integrated through data? If yes, the application can be migrated reasonably simply, if not it may be more complex. We will come back to that.

 

Knowing where the application will be located, knowing what type of migration will be required and knowing what data interactions are needed, one can no finalize the application migration strategy and the transformation plan.

 

Fundamentally there are four migration strategies possible:

  • If the application is SOA compliant, a re-hosting can take place. Little changes are needed to the application; it’s more a question of linking the app to the new data sources and testing the implementation prior to take it in production. This type of application obviously gives the best return.
  • If the application consists in integrated modules and functionality, a re-architecting of the application may be required. Using SOA principles, the code is divided in separate modules that each represents one function and the modules are linked through data. In that process it is perfectly applicable that some of the functionality is replaced by existing cloud services rather than re-written. The software needs to be rewritten and re-assembled prior to being tested and taken into production. This process is costly, but once the application is implemented in the cloud, it fully benefits of having become a cloud application.
  • It may turn out that the application is too complex to re-architect. In that case, you may want to leave the application in the legacy environment, which means you will not get the full benefit of the migration, but make the application visible in the cloud. This can be done through the development of a number of web services that invoke application functionality. The disadvantage is that the benefit is lower than in the case of a migration, but the advantage is to shield the user from the actual application. Once the web services are in place, the application may be transformed, replaced etc. without affecting the interaction between the user and the application as he actually only interacts with the web services.
  • If none of the above work and the application can be replaced, a new application may be written and/or SaaS services invoked to address the functionality. Here we replace the application. This is obviously also the case for the applications that are sunset.

The last step consists in testing the revised application and taking it in production. Using testing tools the functionality and performance of the application are reviewed and a stress test may highlight whether the application allows for growth in its usage patterns.

 

Migrating applications to the cloud and exposing their functionality as services to the business users forces enterprises to identify what is core to their business and how users should be supported with appropriate services.

 

You may want to take time to review the business process in the first place and where possible to simplify it. That may make some applications or portions of applications obsolete. So you won’t have to port them to cloud. By reviewing the business processes, look at the individual steps in the process and identify which service (often also called transaction) supports each process step, the enterprise can develop a greater understanding of how it operates and establish a way to adapt business processes faster to changing needs. This is worth a discussion in its own right, but I wanted to mention it here as it may help in the thinking process on how to migrate existing applications to the cloud.  

Labels: cloud| Cloud Source
Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the community guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Christian is responsible for building services focused on advising clients in their move to cloud, particularly from a business process and ...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation