Migrating to the Cloud: 1 – ASSESS

This is essentially a discovery and analysis exercise that most of the times can be split into two different perspectives or areas of focus: Business and Technical. As a rule of thumb, I always think of these six questions:

1. What? E.g. what’s in scope?
2. How? E.g. how is IT run?
3. Where? E.g. where are the customer sites/facilities?
4. Who? E.g. who is involved?
5. When? E.g. when should the transition be completed?
6. Why? E.g. why migrate to the Cloud?

The following paragraphs cover some (not everything!) of what to look for when asking and answering these questions.

Business Assessment

I often engage CxO executives that couldn’t care less about how sexy my Cloud solution looks like. As I keep saying, Cloud is never the goal. Cloud is a means to an end. Customers know that as well and therefore all they want to know is if my proposition makes business sense and more importantly, how exactly can they benefit from it.

With regards to Programme Governance, I normally start by gathering the requirements.  I can’t stress enough how important it is to get the customers’ requirements right, as this will make a huge difference between an assessment that is either too shallow or too thorough (not to mention it can obviously compromise the success of the project). Cover what the customer thinks of their own functional/non-functional requirements and needs but consider complementing it with your own view. Some customers are less familiar with some aspects of the Cloud so it’s likely they’ll count on your expertise and background to complement their vision.

Another of my initial concerns is to establish roles and responsibilities, both from the provider and the customer side. For this I normally use a RACI or RASIC matrix. Sometimes this precedes the requirements gathering as it’s a natural evolution from the people’s introductions.

It’s also very important to understand what are the goals and business drivers to consider Cloud as an option - this will most certainly shape the Target State Environment and potentially the Transition Strategy. I find it fundamental to learn about the customers’ business model and strategy. What is the customer aiming to achieve over the next 3 years? Are there any known pain points? What is IT importance within the business? I also look for compelling events, such as a lease on a Data Centre building that is about to expire or a server infrastructure that is rapidly approaching EoL. I try to identify any quick wins as these tend to increase the level of confidence in the project, which is often very useful in the project’s early days. I also try to think outside of the “Cloud box” and be watchful for any opportunities for additional optimization. I always aim to get as much tangibility on the targets as possible, however some customers will state vague goals like “reduce operational costs”. To my view, this doesn’t help me to realize how success will be measured. I’ll often ask by how much? Are there constraints, budget, time or otherwise? Is there a preference for a CapEx or OpEx model?

Don’t forget the all-time favourites: processes. I don’t think I can say I know my customers’ business well enough until I’m aware of their relevant business processes. I typically enquire about assets related processes (e.g. procurement, provisioning, decommissioning, etc.), operational processes and project control processes to name a few.

Invariably, a lot of the business assessment will focus on financials. Remember, exec sponsors will be putting their budgets on the line so the business case and consequently the figures need to stack up. For some techies, this might pose a challenge, so hopefully this and my following posts on the subject will be of some help.

As the simplest of tactics, it’s important to understand the current TCO and if there’s a target TCO or a target ROI (I have TCO/ROI models that I can share if you need). Find out all you can about budgets, from the overall IT budget to the project’s. Ask how does the business fund IT? Other common KPIs may be of importance, such as inflation, depreciation, payback period, hurdle rate, Return on Assets (ROA), Net Present Value (NPV), Internal Rate of Return (IRR), amongst others.

All of the above are often elements of a Project Initiation Document (PID), which in turn is part of the Programme Governance Documentation. A PID may also include sections that cover information such as contacts, scope, deliverables, risks, assumptions, constraints, KPIs, project controls, etc.

 

Technical Assessment

Cloud wouldn’t exist without technology and therefore there needs to be a technical assessment, which normally follows the business assessment. One reason for this is that by the time you start looking at the techie bits, you should already have a good understanding of how IT relates to the business.

In my opinion, migrations to the Cloud should be application orientated so if you think the same way, ensure applications are at the centre of everything you do.

Starting with infrastructure, it’s important to understand what is out there. I try to learn everything I can about the estate, from sites’ geographical dispersion to percentage of virtualized systems to the specs of every piece of physical and virtual hardware. Most customers have this information relatively up to date, so I often tap into CMDBs, existing documentation, run workshops/interviews, anything that can assist me in building a detailed Current State Design. If possible and applicable, I’ll extend my time horizon, i.e., don’t focus on the present only and analyse growth and any capacity plans.

Customers should also provide information on how is the infrastructure being utilized, i.e. how are systems utilizing resources (e.g. CPU, memory, disk, I/O, etc.). Unfortunately is less frequent (from experience) when I can get hold of information about how are applications utilized. It’s common to find CMDBs that provide information on what software is installed on which systems down to version and patching level, however this is not sufficient to design a comprehensive End State Environment and/or an effective Transition Plan. As a few examples, it’s imperative to determine relations such as:

-          Application-to-business mappings: which application maps to which business process, and how critical it is to the business (usually indexed to revenue );

-          Application-to-infrastructure mappings: which infrastructure components are required to be operational in order to guarantee application availability (from the servers where it’s installed, to the switches/routers that provide network connectivity);

-          Application interdependencies: which applications communicate with which applications (from typical 3 tier dependencies to authentication requirements)

Information like the above will also allow defining the transformation approach for each hardware and software component to be transitioned to the Cloud.

Conclusion

I’ll be writing further posts on both Business and Technical assessments, to deep dive on these subjects and also to share some ideas on tools and templates to use, so if this interests you, watch this space!

As a closing thought, don’t expect this post to exhaustively cover all that needs to be assessed in a migration project, or that aspects covered will always apply to any migration project. Instead, this post is intended to provide an overview of common aspects to be aware of, a spark to trigger new ideas in your own mind and enable you to explore even further.

PS - By the way, once those new ideas start popping, make sure you come back and share them with us J