Building a Business Case for AWS Adoption

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Mario Thomas, Global Advisory
Organisational transformation through the adoption of AWS
Building a Business Case for AWS
6 June 2018

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
• TCO and the business case
• Business case tooling and process
• Discovery and the data we collect
• Analysis of and normalising data
• The outputs
Building the business case

Why establishing the 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 a business case tells us

• What the cost of getting into AWS will be
• What the cost of operating in AWS will be
• What the costs of exiting current infrastructure could be
• What benefits the business will gain from being in AWS
• What the cost of doing nothing is
• What building infrastructure for new workloads costs
Building a business case tells us

What type of business case
do customers need

Directional
Detailed
?

Iterate the business case; don’t go for
perfection with the first pass

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

How do we build a business case?

Manual Automated

• Migration cost estimator
• Simple TCO Calculator
• Assumptions
• Resource efficiency model
• Six R’s analysis
• 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

When do we 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

Why not just build a TCO analysis?

TCO and the business case
Business
Value
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
Current / Do Nothing
(with growth)
AWS Environment
Payback
Period
Time
Cost

Business
Value
$
1 2 3 4 50
TCO
Migration Bubble
Cost Optimising
Current / Do Nothing
(with growth)
AWS Environment
Payback
Period
Time
Cost

Features of a great AWS cloud adoption business case TCO BCA
Like-for-like comparison of AWS vs. on-premise/co-location for same workloads ✓ ✓
A high-level business-focussed analysis of application migration patterns (six R’s) ✗ ✓
A cost for migration to AWS ✗ ✓
A cost of operation (TCO) once landed in AWS ✓ ✓
Alternative TCO’s for higher-level services (e.g. RDS instead of Oracle on EC2) ✗ ✓
Consideration given to current licencing and licencing in AWS some ✓
Resource utilisation cost analysis ✗ ✓
Third party cost analysis ✗ ✓
Identification of value benefits ✗ ✓
Financial cost analysis including balance sheet and budget items ✗ ✓
Apply cost optimisation principles to the TCO’s in the business case maybe ✓

Features of a great AWS cloud adoption business case TCO BCA
Show the cost and cashflow of leaving on-premise or co-location and moving to AWS ✗ ✓
Show the cost of doing nothing (i.e. not migrating to cloud) ✗ ✓
Calculates NPV, ROI, MIRR and the payback period ✗ ✓
Provides financial models to the customer so they can amend assumptions ✗ ✓
Provides a presentation which can be used for stakeholders ✗ ✓
Time to execute 3-8h varies*
* Can be as little as 2 hours and as long as 10 weeks, subject to having the data from the customer.

What information do we need to build
the business case?

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
• Ensure there is an executive sponsor

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
environments are massively underutilized
A 2017 Study by IDC stated that typical data
centers are 45% utilized.
This is measured in terms of the amount of idle
compute hours and unused storage capacity
for provisioned components.
IDC: Quantifying Datacenter Inefficiency
http://www.integra1.net/uploads/files/IDC%20Making%20the%20Case%20for%20Composable%20Infrastructure.pdf

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
IDC: Quantifying Datacenter Inefficiency
http://www.integra1.net/uploads/files/IDC%20Making%20the%20Case%20for%20Composable%20Infrastructure.pdf
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)
• Understand upcoming application changes
• Consider application migration patterns
• Application maintenance costs
• Innovation / ongoing development / bug fixes
• Managed service organisation
Application costs

• Licensing landscape
• Existing licences
• Transferability of licences
• Upcoming licence renewals
• Move to Amazon Linux
• Application requirements:
• SLAs
• Disaster Recovery
• High Availability
• Security and access
• Regulation and compliance
• 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.
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. 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%

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

Business Domain Technical Domain

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

• 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

Task On-Premise On AWS
Install server, rack, TOR, networking… ✓
Manage physical access ✓
Test power and network fail over ✓
Deal with disk failures ✓
Manage RAID arrays ✓
Hardware procurement and budgeting ✓
Patch management and End of Life issues ✓
Configure services ✓ ✓

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

How do we analyse and process the
data for the business case?

• Data is given to us in a variety of formats, the most popular are:
• Excel
• CSV
• vCenter exports
• PDF
• ADS exports
• Often cut and pasted from multiple sources
• There are usually errors, missing data and questionable data
• Understanding what you are getting is key to being able to challenge the data
• Get to know the data, you are going to need to document it
Data formats

• Once received, data must be analysed
• Begin by establishing meaning, do this by discussing the data with the customer
• Generate questions and assumptions about the data
• Then move on to validation
• Look for range errors (e.g. inexplicably large amounts of RAM vs. cores)
• Look for invalid data (e.g. versions of Windows that don’t exist)
• Look for 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)
• Customers sometimes include everything, check you’re not counting infrastructure
Analysing and normalising data

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 need to ‘cut and paste’ just values to ensure completely clean data
Analysing and normalising data

How do we collate and present the
numbers?

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

Building a Business Case for AWS Adoption

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Building a Business Case for AWS Adoption

Similar a Building a Business Case for AWS Adoption (20)

Más de Amazon Web Services

Más de Amazon Web Services (20)

Building a Business Case for AWS Adoption