The cloud migration will not be too bumpy, and should achieve expected business values and results.
Cloud strategy becomes a strategic piece of IT strategy, which is also integral part of business strategy, but how to implement it with confidence? Where can you find a true vendor-neutral methodology that allows business to understand how your current portfolio will move to the cloud and what delivery models optimize the portfolio delivery?
1. Ask WHY, WHAT Before HOW via Navigation Methodology
- Start with WHY? Why do you need step into the cloud? This is strategic process to objectively analyze the biggest challenges facing in IT, for example, statistically many IT organizations spent 70%+of their resources on legacy infrastructure maintenance & operational projects, worrying about upgrades to hardware and software, IT has the reputation as cost center to play the role as firefighter or controller, with lower level of customer satisfaction and employees' productivities. The cloud presents a different delivery model, it's ubiquitous, it can achieve high levels of availability, if that's taken into account in application design, and it's also about OpEx rather than CapEx, generally speaking: Better access and delivery of the app are tipping points for moving to the cloud.
- Then ask “WHAT” can and should move: This is a thoughtful planning process where one examines the age, operational costs, complexities and support limitations of applications in the current portfolio and makes priority decisions about which ones need to be modernized. That may mean in place upgrades or replacement with some other type of offering which may or may not be cloud- based. The next step is, of course, evaluating the options and making decisions based on what is available and meets your needs. As some of the most compelling cloud-based applications today are those that address core business processes that are common across industries such as HR, collaboration, even e-mail.
2. Step-Smart via Application Portfolio Management Methodology
The tried and true method includes: To adapt the Application Portfolio Management methodology with a pragmatic
(Service Oriented) Architecture
- Taking an application centric approach is the right way to approach cloud migration. It is applications that directly support a business, not the gear in the datacenter. Too often when planning and executing cloud migrations, people only look at current state infrastructure usage for decision. This assumes that an application is 100% fulfilling the demands of the business and there is no opportunity for improvement. Also, taking an infrastructure-centric approach does little to address the risk of “breaking” application dependencies and potentially impacting the business.
(business driven) and bottoms-up (current state application deployment)
Approaches, here are a few highlighted steps from top down methodology:
1) Document your key business functions and activities, then quantify what’s important to them and what demand they place on your portfolio: Reduced risk? Agility? CapEx cost savings? High level of global availability? Strictly regulatory requirements?
2) Inventory your application portfolio and align it to business activities: This should include collecting information about the applications such as demographics, implementation and business relevance. The goal here is to understand which applications support what business activities and to have the information necessary to make fact-based informed decisions.
3) Understand the applications key workload performance characteristics: Low-latency? Intense Numerical Processing? This can be difficult but important.
ALL CLOUDS ARE
NOT CREATED EQUAL. For example: getting two virtual machines from two
different cloud providers with the same configuration does not mean they will
perform the same. They will absolutely have different characteristics so it is important to quantify what the
required performance characteristics will need to be for an application to be
supported properly. This is critical when choosing a cloud provider.
4) If you have applications that are complex, not well documented, or business critical you may want to consider, building out a current state deployment blueprints that highlight application inter-dependencies and shows infrastructure dependencies. This will help mitigate unnecessary risk as you migrate those applications.
5) One of the key elements that most methodologies ignore is the visible and hidden costs of training and enablement. Besides the visible cost of re-educating you users in the new services and processes, you should confirm is you are also liable for a salary/award bump triggered by employees gaining new skills
So, after completing these steps you should have collected enough information to intelligently decide on what application you would like to move, and have the basis of the performance capabilities required by the future state cloud platform.
3. Vendor Evaluation & Migration Methodology with PM Principle
Look at the business capabilities the IT portfolio is supporting and at their non functional requirements. They might suggest that cloud would be the better delivery platform to orchestrate business capabilities. It's probably hard to find a totally cloud neutral provider or for that matter an ‘anything neutral’ in this business. Even if a provider is not branding their own products per se, they still have very tight, interlocking relationships with a variety of secondary providers that do. When it comes to the cloud, CIOs have to be very wary of not getting bogged down dealing with a myriad of providers to be sure the third parties are reliable and you don't get caught up managing too many providers. And migration to a cloud-based application as first and foremost a project that needs to be planned and executed using good project management principles:
1) The first step, deciding where to put what application is fundamentally a strategy discussion. It is related to the nature of the application and the data. And where do ROI and
2) The second step, reviewing if the application can be migrated to where it is supposed to be (private, managed or public cloud), the discussion becomes technical. Is the application consists in a series of loosely coupled "services" tied together through data sources? Again, none of this is vendor specific.
3) The third step, performing the appropriate transformation (re-host, re-architect, re-place, encapsulate) is vendor specific as you have to take into account the technology provided. But that's the last step and it has more to do with implementation than with the actual doing.
4) Most vendors have a basic migration plan that, if properly managed, will work well. Rigorous testing is critical of course. So, use the vendor's migration tools and process but manage the project yourself using sound project management methods.
The big "gotcha" in these migrations are usually, in no particular order, data migration, performance, compatibility and interoperability with your environment (no, everything isn't always "plug and play" regardless of what the vendor tells you). Follow the effective project management principle/practice, the cloud migration will not be too bumpy, and should achieve expected business values and results.