Change Management

What is Business Transformation?

Transformation Competition 5th September 2019

What is Business Transformation from a Cloud Migration Perspective?

A simple answer is the agility to experiment in order to gain insights that can lead to business decisions.

To unpack that a bit: when faced with a rapidly changing business environment the capacity to quickly run up Proof of Concept ideas to test a market supposition and then abandon it quickly and cheaply if it fails to fly or take it global in minutes if it takes off gives a business a strategic advantage.

So how to go from stasis to agility and leanness?

It might be helpful to consider at a high level the phases of cloud adoption.

Phase State
1 MOVE TO CLOUD - rethink/re-imagine - what is the business? what is its value proposition?
2 CLOUD PRODUCES MASSES OF DATA - data that was unavailable before learn to value data and gain insights from it
3 BUSINESS TRANSFORMATION agile, lean, competitive, responsive to demand, innovative, engaged with customer

To repeat : doing something differently because you have a better understanding of the service to the customer leads to more data about the way customers use the service which gives insight into ways to enhance the customer experience – a virtuous circle.

Shaping an Agile Lean Business Model

PROCESS TRADITIONAL TRANSFORMED
PROCUREMENT months minutes
CHANGE 1-2 weeks 4 hours peer review
ARCHITECTURE Fixed/ design authority POC re-usable assets
DELIVERY Waterfall sign offs Agile/scrum Kanban end to end teams
WORKFLOW Silos/departments Cross functional teams
GOVERNANCE Project plan, gatekeeper Guard rails
CULTURE Top down, directional Inclusion, cross functional team, openness, experimental
SECURITY Security is run by a specialised team Security is everyone’s job

There are two ingredients necessary to move to a high frequency business: 1. Operational excellence; 2. Bravery

For the first point: EXPERIMENTS lead to INSIGHTS which lead to OPERATIONAL EXCELLENCE

For the second point: BRAVERY is required to silence doubters who say that what you are trying to achieve is impossible as you seek to put into practice the insights that are supported by your data.

The transition is from traditional decision making to devolved, experimentation

# Traditional Business High Frequency Business
1 Change comes over long term > 6 months Waterfall, big projects Agile, iterative, small projects
2 Protect status quo Continuous refactor, improvement
3 Top down decision making Data driven decisions, tested and measured; But can use anecdotal ideas to spark creativity
4 Business and IT silos Small, cross skill teams span business and technology to move closer to the customer
5 Large feature sets Constantly re-prioritise and validate for relevance
6 Monolithic software and processes Reduce lead time from idea to implementation of MVP
7 Plan for best case scenario Assume attack and failure and plan accordingly
8 Security is run by a specialised team Security is everyone’s number one job

Steps to a high frequency style business

Break up monoliths into microservices
Essential

Monoliths impede change because small changes impact everything and create choke points that limit ability to scale. Microservices are decoupled, can be independently refactored and redeployed

Start looking at one line of business at a time.
Focus on what needs to be done
Kanban

What needs to be done with frequent high value deliveries that expose a small blast radius of risk.

Reduce work in progress.
Invest in the workforce
Customer focus

Put your teams closer to customers with alignment around customer value not systems or processes.

Cross functional teams.
Automate bureaucracy
Automate everything

Automate bureaucracy -if it takes three months to get a new server from purchase order to commissioning, your opportunity to rapidly roll out new value to customers is inhibited to two or three deliveries per year whereas your competitor might do new rollouts daily. The way to achieve this is through CI/CD where DevOps teams of cross skilled developers and operations take ownership for each new release with code build, testing, security, deployment pipelines run from coded scripts.

Friction in product teams comes from waiting for other people.
It is not Done until it is released to customers
Continuous CI/CD

Replace a human gatekeeper with automated controls; standardise throughout the business by re-using standard building blocks (including open source) to avoid re-inventing the wheel

High frequency deployments
Build a feature on but don’t bolt it on
Loose coupling

Functionality should be replaceable, removable, renewable without impacting the whole system. Security should be baked into the whole development/ deploy as part of everyone’s responsibility not left to a security team to add on.

Microservices

Acknowledgment - Photo by Trent Erwin on Unsplash