Cloud Transformation: what you need to know before engaging your provider
1. Value without compromise.
Cloud Transformation: what
you need to know before
engaging a provider
Alex Lal
Infrastructure Strategy and Solutions
Velrada
2. Your Cloud transformation journey
Building the benefits case
Aligning the organisation
Designing the solution
Planning the transformation
Today’s agenda
3. Established in 2009, Velrada is an award winning, Australian-owned,
business and technology consulting firm with strong experience in
resources around the Asia-Pacific region.
Alex is a Managing Consultant in Velrada’s Infrastructure Strategy and
Solutions Practice, with 10 years’ experience of major infrastructure
transformation projects in the Government, Utilities, Mining, Oil & Gas
and EPCM sectors.
In addition to our infrastructure consulting practice, we also have
strong capabilities in:
Operational efficiency and process improvement
Rick management and compliance
Business change and transformation
Information management, Business Intelligence and Big Data
Web, mobile and social collaboration
Systems architecture and integration
Alex Lal
Infrastructure Strategy and
Solutions Consultant
By way of introduction
4. Questions, questions, questions…
Public, private or hybrid Cloud?
Which provider?
Which pricing model?
How will this affect business critical application x or service y?
How will it impact my network (performance and costs)?
Where will my data be stored and how quickly can I retrieve it?
What about ancillary services (BUAAS, DRAAS, MAAS, CAAS…)?
Business Case
Vendor Selection
Service Design
Migration Planning
Integration
Change Management
Security
Service Transition
UAT & Training
Purchasing & Billing
Vendor Management
Ongoing Maintenance & Support
5. Cloud transformation
delivers intended cost
savings, but little else due to
lack of alignment with
business objectives.
Migration effort is more
challenging than initially
envisaged, leading to erosion
of confidence and support.
Business critical applications
or services do not function as
well in your Cloud
environment as they did on
premise.
New ways of working require
new capabilities to be
developed within your ICT
organisation.
Common pitfalls
6. Are you prepared?
Your Cloud transformation journey
Strategy: build support
and momentum
through a business-
focused benefits case.
Planning: understand
your key metrics and
align your working
practices accordingly.
Design: create an
overarching design and
governance framework
to support decisions.
Execution: ‘prime’ your
environment and take a
risk-based approach to
migration.
Program management
Commercial management
Risk management
Change management
What you should know…
7. In order to leverage the benefits of
Cloud, we should understand and
focus on how it will create business
value, by aligning with
organisational strategies and
objectives.
Building the benefits case
8. DEMAND MANAGEMENT
Business
Partnering
Governance
Sizing and
Scoping
Pricing
Transparency
Translating ‘wants and needs’
into a set of high-level
solution or service
requirements
New role for ICT
organisation – more
‘service broker’ than
traditional IT shop
Understanding the ‘wants
and needs’ of the
business
Frequently overlooked, but
critical to ensuring
responsiveness and controlUnderstanding the costs
and providing visibility back
to the business
Aligning the organisation
9. 9
Designing the solution
‘Commodity’ Layer
‘Managed’ Layer
‘Utility’ Layer
Services that can be called
off by business teams or
users from a service
catalogue.
Services that are controlled
centrally by the ICT
department.
(Typically) infrastructure
services that are consumed
‘as a service’ by the
organisation as a whole.
10. 10
Planning the transformation
Asses
s
Design Plan Validate
Begin with a
comprehensive inventory
of current and planned
applications, infrastructure
services and data sets.
Work with partners to
build a picture of what
type of Cloud
environment(s) will
meet your needs.
Identify low-risk candidate
applications, services and
data for early migration to
test and prove transition
approach and processes.
Validate this with
the business to
build confidence
and trust in within
the organisation.
11. Look beyond TCO – seek alignment with business
(not just ICT) strategy and objectives.
Ensure key ‘pieces of the puzzle’ are in place
before engaging with your vendor.
Start with a comprehensive understanding of
your current environment and planned initiatives.
Be prepared to realign the ICT organisation to
manage the new environment.
Key takeaways
Cloud market reaching a level of maturity where value proposition is compelling, but still plenty of things that can go wrong.
Business and technology stakeholders within the enterprise still have a range of questions, but are not necessarily sure where to go for sound advice.
Perception that Cloud transformation is high-risk, low-reward from an internal profile perspective.
Aware that there are a large number of facets – but still often treat Cloud transformation as an ICT infrastructure project, rather than a transformation program.
What we need is a way of taking a step back, looking at the problem in a holistic way, but still providing practical advice based on real-life experience to help compensate for limited experience/confidence in delivering these programs.
Example 1 – application rationalisation delivered cost savings but delivered very few of the intended benefits, because they hadn’t thought through the business, security and technical constraints.
Example 2 – in the desire to move infrastructure off premise, realise cost savings and make the environment easier to manage, don’t really go through the due diligence required to identify which applications and services are good candidates to be moved into the cloud, and ensuring they are optimised to do so and still able to integrate with other legacy systems.
Example 3 – deliver the Cloud migration, but haven’t given sufficient attention to the changes in capabilities, ways of working or business processes that this entails. Manging infrastructure via online tools and service contracts, rather than managing tin. Quite a formidable business change challenge in many organisations.
Example 4 – by failing to give adequate consideration to the needs of end users, ensure the technical environment is prepared and optimised for the transformation and taking on ‘too much too soon’, the migration effort becomes much more complex, it’s difficult to deliver quick wins and build confidence in your migration plans and processes.
Just as a note – the term ‘Cloud’ can refer to a huge range of products and services, or combinations thereof. I tend to look at it more as an architectural approach or design pattern, but everyone will have a different view.
I didn’t really want to get into a very detailed discussion of particular architectures or products, so I’m deliberately using ‘Cloud’ in its broadest possible sense.
What I hope to pass on today is a set of planning approaches that will help provide you with some confidence that your addressing the opportunity in a good way, and a few practical ideas on how to move forward.
Talk through each component of slide
Design – must begin with a comprehensive understanding of you existing technology environment, constraints and strategy
You should have a pretty clear understanding of all of these things before beginning any procurement exercise – by all means engage with vendors (the more the better), but don’t rely on
Look beyond the TCO.
Flexibility, elasticity, agility – all sound great, but straight from the vendor product spec.
Makes the environment easier for us to manage, but Cloud has the potential to be a genuinely disruptive, transformational technology opportunity for the business: so we should be aiming higher.
Can create a platform for more flexible, dynamic, responsive interaction with employees and customers. Just look at the way it is revolutionising consumer tech.
How does implementing Cloud align with my corporate (not just ICT) strategy and objectives. What are the key drivers and imperatives? Examples:
Multinational corporations: making information available worldwide outside the corporate network
Government: enabling information sharing across organisation boundaries within a common, secure environment
Transport & infrastructure: storing large amount of remote sensor and running high-volume data analytics
Retail & education: coping with periodic surges in demand that are predictable and therefore do not require 24x7 infrastructure provisioning
This will fundamentally affect your choices concerning your Cloud architecture, pricing model and even vendor.
Either on prem or in the Cloud – the challenge is the same, managing demand.
However, a much more flexible, dynamic environment, with fewer levers at your disposal.
Likelihood is you will have created some additional expectations within the organisation with regard to response times, etc.
Change of mindset as well as capability/operating model.
Leveraging the benefits versus stability of the service.
Some of these capabilities will be developed through outsourcing/managed services, but will need to mature further.
Commodity layer – e.g. a Hadoop ‘job’, new VM, license for a particular application within the overall capacity constraints available. Usually made available to users via some sort of web form of GUI.
Successful deployments tend to have a very clear and defined focus on what the value proposition for that particular organisation is at each layer of the model. Also a clearly defined roadmap of which elements to deliver when.
Managed layer – typically concerns the overall capacity of the environment, or cost/capacity-sensitive compute, network or storage resources that need to be centrally monitored and managed.
Utility layer – services that are consumed ‘as a service’ by the organisation as a whole, but resources reside in the Cloud. BUaaS, DRaaS, CaaS, etc.
A number of decisions need to be made at each layer, depending on the balance of flexibility, scalability, security and control you require. Public/private/hybrid. SaaS, PaaS, IaaS. Probably some mixture of all of them at each layer.
Therefore dozens (if not hundreds) of design decisions will be required on how to architect these services, let alone operate and manage them. Not really possible without a clear overarching design framework and principles, and a governance process to control this.