"Because as we know, there are known knowns. We also know there are known unknowns; that is to say we know there are some things we do not know" went the now famous response to a reporter's question by US Secretary of Defense, Donald Rumsfeld.
Of course, the concept of known knowns, known unknowns, and also unknowns unknowns is highly familiar to enterprise technology professionals. Every organisation that has been around for more than a few years has built up an IT estate comprising of all three.
And it is this lack of knowledge that creates one of cloud migration's greatest challenges.
Accordingly, many organisations start cloud migration with a discovery exercise to ensure they know what they're taking to cloud and why. And conversely many organisations also do not, instead choosing to lift-and-shift the known unknowns to cloud and deal with the problem later.
Which might seem peculiar but is entirely understandable, "We don't know what's in our data centres and have neither time or budget to work it out" is the perturbed reply regularly heard from CIOs and CTOs.
Discovery has a reputation for being an expensive, time-consuming and frustrating process that often fails to deliver. But it doesn't need to be this way.
Here we share insights from the experience of using the AppScore Cloud Accelerator methodology with customers and partners and describe the three critical success factors that ensures a pain-free discovery to underpin effective cloud migration.
Critical success factor 1 - Senior stakeholder backing
Discovery will impact on your teams, it's unavoidable. Whilst a lot of useful information can be gathered by agents and tools, at some point the SMEs need to be engaged. No automated agent can determine factors like roadmap status or business criticality. But getting time with SMEs is difficult, they're busy people, so discovery must have the backing of a senior stakeholder who can set priorities and ensure SME engagement.
Success comes from agreeing a scope and timeline with the senior leader and asking them to issue formal comms. During discovery, report progress weekly to them highlighting risks and issues and required escalations.
Senior stakeholder backing is undoubtedly the most important of the critical success factors, without it discovery will fail.
Critical success factor 2: Breadth then depth
Capturing just the right amount of data to make the decisions you need to at that point of the programme is proven to be the most effective approach.
Deep diving too early lengthens the timeline and results in unhappy SMEs who must provide considerable amounts of information. Wading through an enormous dataset also causes analysis paralysis as you try to work through the information, much of which turns out to be superfluous. Discovery’s reputation for being time consuming, frustrating, and expensive is largely caused by collecting too much data.
The right amount of data depends on your programme but at the start the following will usually be enough:
- A server and database list with details on operating system and database versions, environments, and data centres. Servers should also be matched to applications. Sizing and performance data can be captured for future run cost planning if required but isn’t essential at this stage.
- Information to determine 7R transformation routes (within AppScore this is done by answering five questions)
- A basic set of information about the application, typically we use 25-30 questions covering items such as business criticality, data classifications, application type, high-level security requirements and so on.
The aim is to collect enough data that can be used to categorise applications and score them for risk, complexity, and benefit. Scores which can then be used to determine the effort involved in migration and group the applications into scopes, move groups or similar.
More detailed information is captured iteratively as you move through the scopes. So, for example, you might capture high level information across 50 applications, then go deeper on groups of those applications.
Critical success factor 3: Use time boxes
A great frustration with discovery is when it seems to run on and on. Going too deep in data capture is one cause but it's also important to time box activities to ensure completion by a set date. Within the AppScore Cloud Accelerator methodology we use time boxes of four, eight or twelve weeks. With weekly reviews and progress reporting to senior stakeholders.
At the end of the timeframe assess what’s been discovered and take applications forward for migration or into deeper discovery using an iterative data capture approach.
Also, you should not expect to discover everything within the time box, instead expect there to be gaps in the data at the conclusion of the cycle. This in itself is highly useful information.
For example, if, after four weeks of focused discovery, you're not able to identify what 10% of the servers do it raises important questions. Why is the organisation paying to run them? Who's patching them, what security risks do they present? These known unknowns should then be taken forward for further investigation.
A scalable process to turn unknowns into knowns
The AppScore Cloud Accelerator methodology has proven to be highly effective in ensuring successful discovery across all sizes of estates. Even large estates can be covered in a short period: recently we achieved 90% coverage across 3,000 servers and 650 applications in eight weeks.
Whilst most organisations experience the problem of not understanding what's in their data centres, using the three critical success factors with a standardised methodology will quickly turn unknown unknowns into known knowns.
For a demonstration on AppScore and the AppScore Cloud Accelerator methodology book a session with our team here.