Building the business case for AWS

© 2017, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Mario Thomas, Global Advisory
Organisational transformation through the adoption of AWS
The AWS Approach to the business case
31 October 2017

The following applies to this document and all other documents, information, data, and responses (written or verbal) provided
by Amazon Web Services, Inc. or any of its affiliates (collectively, "AWS") in connection with responding to this request and
other related requests (collectively, this "Response"): This Response is expressly (a) informational only and provided solely for
discussion purposes, (b) non-binding and not an offer to contract that can be accepted by any party, (c) provided "as is" with
no representations or warranties whatsoever, and (d) based on AWS's current knowledge and may change at any time due to a
variety of factors such as changes to your requirements or changes to AWS's service offerings. All obligations must be set
forth in a separate, definitive written agreement between the parties. Neither party will have any liability for any failure or
refusal to enter into a definitive agreement. All use of AWS's service offerings will be governed by the AWS Customer
Agreement available at http://aws.amazon.com/agreement/ (or other definitive written agreement between the parties
governing the use of AWS's service offerings) (as applicable, the "Agreement"). If the parties have an applicable Nondisclosure
Agreement ("NDA"), then the NDA will apply to all Confidential Information (as defined in the NDA) disclosed in connection
with this Response. AWS's pricing is publicly available and subject to change in accordance with the Agreement. Pricing
information (if any) provided in this Response is only an estimate and is expressly not a binding quote. Fees and charges will
be based on actual usage of AWS services, which may vary from the estimates provided. Nothing in this Response will modify
or supplement the terms of the Agreement or the NDA. No part of this Response may be disclosed without AWS's prior
written consent.
Disclaimers

• Why establishing a business case is important
• Types of business case
• When to build a business case
• Cloud economics
• Business case tooling and process
• Discovery and the data we collect
• Data formats
• Analysing and normalising the data
• The outputs
Building the business case

Why establishing a business
case is important

An effective business case and the process to create it
can help you to remove friction to adoption of the
cloud as well as identify the key stages and costs of
adoption and migration to AWS.
By understanding your existing application
workloads or plans for new ones we can work with
you to develop the foundations of a sound business
case.

New WorkloadsExisting Workloads
Customers with existing workloads
typically want to know what the cost of
moving those workloads to AWS will
be as well the ongoing cost of keeping
them there.
Customers with new workloads which
have not yet been deployed to a
production environment, typically want
to know the cost of keeping those
workloads in AWS.

In preparing the business case, we often find more
opportunities to help customers drive efficiencies in
the broader business as well as reduce costs.
This creates the environment required to accelerate
innovation, increase productivity and reduce risk.

• What the cost of getting into AWS will be
• What the cost of continuing to be in AWS will be
• What benefits the business will gain by being in AWS
• What the cost of keeping application workloads where they are will be
• What the cost of deploying new workloads to on-premise or co-location
environments will be
What the business case tells us

Types of business case

Directional
Detailed
?

Directional
1-2 days
Low-fidelity data, directional
Limited customer scope
Presentation
Simple Excel output
Detailed
4-10 weeks
High-fidelity data, detailed
Broad customer scope
Presentation
Multiple outputs

When to build a business case

When to build a business case
At each stage of adoption:
• Project
• Foundation
• Migration
• Reinvention
Customers may opt to develop any and all
types of business case to establish gating
criteria to the next stage.
Here
Here
Here
And here

Cloud economics

Cloud Economics
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
Current / Do Nothing
AWS Environment
Payback
Period
Time
Cost

Total cost of migration (TCM)
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
AWS Environment
Payback
Period
Time
Cost

Total cost of operation (TCO)
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
AWS Environment
Payback
Period
Time
Cost

Cost optimisation (CO)
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
AWS Environment
Payback
Period
Time
Cost

Payback period
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
AWS Environment
Payback
Period
Time
Cost

Value benefits
Value
Benefits
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
AWS Environment
Payback
Period
Time
Cost

Business case tooling and process

Manual Automated

• Migration cost estimator (manual or automated inputs)
• Operations calculator (manual or automated inputs)
• Assumptions
• Resource efficiency model (manual inputs)
• Six R’s analysis (manual inputs)
• Financial analysis
• Business value analysis
Manual business case tooling

Automated business case tooling
Business Case Discovery &
Planning
Dependency
Mapping
Workload & Data
Migration
ValidationInventory

Business case process
Discovery Analysis Outputs

Discovery

Business objectives
• It is important that we find out about you
• Knowing your business objectives is key to
presenting the business case aligned to them
• We like to understand what challenges will come
up in building the business case so we can work
around them or through them with you
• Understanding what is driving your cloud adoption
plan is key to a well articulated business case

Discovery
People
Costs
Third Party
Costs
Infrastructure
Costs
Application
Costs
Migration
Costs

Infrastructure costs

Used IT
Capacity
Idle
Capacity
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
On-Premises IT
Compute capacity
A typical on-premises compute
environment is massively underutilised
Typical data centres are less than 45% utilised.
This is measured in terms of the amount of idle
compute hours and unused storage capacity
for provisioned components.

Used IT
Capacity
Idle
Capacity
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
On-Premises IT
Compute capacity
Part of this can be explained by buying for
“peak load” requirements with inflexible
infrastructure
CyclicalPart-timeFluctuating

Infrastructure savings can be significant in the
business case, because of this over-capacity

• Data centre costs
• Facilities costs
• Lease term remaining
• Lease termination penalties
• Cost of reduced footprint
• Connectivity
• Leased lines to the data centre

• Servers
• Number of physical servers
• Number of virtual servers
• Virtual servers mapped to their physical counterparts
• Specification (CPUs, cores, RAM)
• Performance characteristics (CPU/RAM/IO min/max/avg.)
• Storage (SAN, NAS, direct-attached)
• Network connectivity (peak throughput)
• Dependencies on other servers

• Upcoming refreshes
• Existing end of life plans
• Date purchased / instantiated, time remaining on capex
• Cost of purchase / instantiation, cost remaining on capex, lease penalties
• Depreciation / amortisation approach
• Data centre management costs (non-third party) maintenance and
support
• Utilisation of the servers

• Applications and systems installed on the server
• Power supply, cooling, backup, Disaster Recovery
• Security, Compliance and certification cost
• End of life costs
• Decommissioning costs
• ‘Other costs’

So how do we collect this data?

Application costs

• Number of application workloads
• Map workloads to the underlying servers
• Establish workload dependencies (both server and other workloads)
• Review OS licensing and the underlying OS (move to Amazon Linux?)
• Understand upcoming application changes
• Consider application migration patterns
• Application maintenance costs
• Innovation / ongoing development / bug fixes
• Managed service organisation
• Regulation and compliance
Application costs

• Licensing landscape
• Licenses in place
• Transferability of licences
• Upcoming licence renewals
• Application requirements:
• SLAs
• Disaster Recovery
• High Availability
• Security and access
• Perform a “Six R’s” analysis of each workload
Application costs

Application costs
R Name Description Examples
1 Retain Workloads are kept in-situ and are not changed in any way.
Unresolvable dependencies, custom
Linux kernels, non-x86, AS400, etc.
2 Retire Workloads are retired from use.
Existing decommission scope, Unix,
AIX, SCO, etc.
3 Re-host Workloads moved to the cloud, lift-and-shift.
Minimal re-engineering, IP, DNS, file
path changes, Win 2008, RHEL, etc.
4 Re-platform
Workloads moved to the cloud with some changes to
support use of cloud concepts, e.g. elasticity, failover, etc.
Broader changes, use of higher-level
AWS servers, e.g. RDS
5 Re-factor
Workloads require significant re-engineering in order to run
on the cloud.
Significant re-engineering, e.g. AIX to
Linux, server-based to serverless, etc.
6
Re-
purchase
Workloads are candidates for migration to SaaS-based
solutions.
On-premise CRM to SaaS CRM,
Exchange to WorkMail, etc.
10%
5%
40%
30%
10%
5%
70%

• Re-examine the Six R’s analysis and understand scope for:
• R1 > R2 or R5
• R3 > R4
• R4 > R3
• R5 > R4 or R6
• R6 > R5 or R4
Application costs

How do we decide which ‘R’ an application
belongs in?

Migration costs

• Planning and designing migration
• Development effort
• Testing effort
• Acceptance effort
• Deployment effort
• Landing zone configuration
• Licensing
• Data migration
• Cut over
• Roll back plan
Migration costs

• Roll back plan
• Duplicate environment
• Training and certification
• Migration velocity
• Identify which apps can move most easily
• Create prioritised move groups
• Organise in sprints and sprint teams for fast results
• Be able to forecast the entire project timescale
• Create a high-level multi-year/month project plan
• The migration should be fast paced and demonstrate a commitment to
migrating the workloads because of its velocity
Migration costs

Migration costs
Application Prioritisation Drivers
Organisational Drivers (Cost, Risk, Time)
Application Drivers
Transaction Load
Resource Utilisation
Scalability and
Performance
Infrastructure
Size of Servers
Number of Servers
File Systems
Database
Storage Volumes
Environment
Test, dev, UAT,
staging, acceptance,
prod
Security and
Compliance
Business Criticality
Frequency of use
Supported business
process and impact
Size of user base
End of life; end of
life support
Application
Complexity
Technology stack
Application
architecture
External interfaces
Inter-dependencies

How do we calculate the migration cost?

People costs

• Direct people costs (employees):
• Recruitment, retention, replacement and retirement costs
• Activity costs including understanding time and motion
• Training and development costs
• Physical space, equipment, and services
• Direct people costs (contractors):
• Recruitment, retention, replacement and retirement costs
• Cost per hour/day/week/month
• Physical space, equipment, and services
People costs

How do we capture people costs

Third party costs

• Contract related costs
• Fixed costs (maintenance, etc.)
• Variable costs (innovation, change requests, etc.)
• Variation penalties / early termination penalties
• Lock-in deals
• Tools lifecycle status
• Software licences (e.g. orchestration tools / multi-cloud)
• Activity costs including understanding time and motion
Third party costs

Data formats

• Data is given to us in a variety of formats, the most popular are:
• Excel
• CSV
• vCenter exports
• ADS exports
• Often cut and pasted from multiple sources
• Sometimes there errors, omissions, missing data and queries
• Understanding the data is key to being able to improve it
Data formats

Analysis

• Once received, we analyse the data
• We discuss the data with you to ensure we understand it
• This will generate questions and assumptions about the data
• We then move on to high-level validation
• Identify range errors (e.g. large amounts of RAM vs. low numbers of cores)
• Identify invalid data (e.g. versions of Windows that don’t exist)
• Identify high utilisation, peak CPU and peak RAM values
• Filter the data
• Some data can be excluded because it doesn’t apply (non-x86, not R3, R4 or R5)
• We prefer to see everything and then filter down
Analysis

Normalising data

• Once data is analysed and filtered, it’s time to normalise it
• Our tooling typically uses Excel or CSV inputs
• We need to produce ‘clean’ CSV inputs
• We remove all formula’s and only work on plain text data
Normalising data

Outputs

Outputs
Executive presentation
outlining cost savings, TCM,
TCO, CO, value benefits and
further optimisations.
Source data
Analysed data
TCM
TCO
CO
Value benefits
All workings

Thank you!
Mario Thomas, Global Advisory
mario@amazon.com
@mariothomas

Building the business case for AWS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Building the business case for AWS

Similar to Building the business case for AWS (20)

More from Amazon Web Services

More from Amazon Web Services (20)

Building the business case for AWS