Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Laws of motion
Search
Lindsay Holmwood
April 05, 2017
Technology
1
180
Laws of motion
Overcoming the challenges of digital transformation in your organisation.
Lindsay Holmwood
April 05, 2017
Tweet
Share
More Decks by Lindsay Holmwood
See All by Lindsay Holmwood
Protecting sensitive data in DynamoDB with searchable encryption
auxesis
0
14
Your API ain't as secure as you think
auxesis
0
150
Footguns and factorisation: how to make users of your cryptographic library successful
auxesis
0
1.5k
Levelling up database security by thinking in APIs
auxesis
0
140
How to thwart your devops transformation with counterinsurgency doctrine
auxesis
1
92
Microservices are an antipattern
auxesis
0
220
Mirrors, networks, and boundaries
auxesis
0
120
Managing remotely, while remotely managing
auxesis
13
4.5k
Testing Conway’s Law in open source communities
auxesis
6
690
Other Decks in Technology
See All in Technology
SoccerNet GSRの紹介と技術応用:選手視点映像を提供するサッカー作戦盤ツール
mixi_engineers
PRO
1
170
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
11
77k
Green Tea Garbage Collector の今
zchee
PRO
2
390
多様な事業ドメインのクリエイターへ 価値を届けるための営みについて
massyuu
0
110
バイブコーディングと継続的デプロイメント
nwiizo
2
420
How to achieve interoperable digital identity across Asian countries
fujie
0
110
SOC2取得の全体像
shonansurvivors
1
370
生成AIとM5Stack / M5 Japan Tour 2025 Autumn 東京
you
PRO
0
210
神回のメカニズムと再現方法/Mechanisms and Playbook for Kamikai scrumat2025
moriyuya
4
520
KMP の Swift export
kokihirokawa
0
330
社内お問い合わせBotの仕組みと学び
nish01
0
240
Where will it converge?
ibknadedeji
0
180
Featured
See All Featured
Writing Fast Ruby
sferik
629
62k
Stop Working from a Prison Cell
hatefulcrawdad
271
21k
A better future with KSS
kneath
239
17k
Done Done
chrislema
185
16k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
52
5.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Visualization
eitanlees
148
16k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Transcript
Laws of motion Overcoming the challenges of digital transformation in
your organisation Lindsay Holmwood
1. Where are we now? 2. Where do we want
to be? 3. How do we start? 4. What happens next?
High-performing IT organisations report experiencing: 200x more frequent deployments
High-performing IT organisations report experiencing: 24x faster recovery from failures
High-performing IT organisations report experiencing: 3x lower change failure rate
High-performing IT organisations report experiencing: 2,555x shorter lead times
High-performing IT organisations report experiencing: 22% less time on unplanned
work and rework
High-performing organisations decisively outperform their lower- performing peers in terms
of throughput.
None
Where are we now? (In the APS)
IT as a cost centre
Delivery approach: Buy and adapt
custom product & commodity
Buy and adapt: Upfront requirement gathering
Buy and adapt: Long procurement cycles
Inward looking
Supporting people and activities within your organisation
Guardians of legacy heritage
Heritage: Systems that are why our organisations are still here
Fragile software
High defect rates
High-performing IT organisations report experiencing: 3x lower change failure rate
Low user satisfaction (if we know what it is at
all)
Slow turnaround on even simple changes
Hierarchical management
“Cylinders of excellence”
People grouped around functional specialties
“The developers”
“Ops team”
PMO
Work bounces between groups
High-performing IT organisations report experiencing: 2,555x shorter lead times
Resilient
Where do we want to be? (if we’re serious about
digital transformation)
• IT as a cost centre • Technology as a
value driver nope
Outward looking
User Centred Design
“What is the user need?”
Delivering services to support users outside your organisation
Who are your users?
The public is a user
Your organisation is also a user
You can not sustainably meet user needs if you are
not meeting your own needs at the same time.
Sustainable, resilient, internal capability
Multidisciplinary teams
Augmented by private sector expertise
Teams organised around services
Services built for end-to-end task completion
Do the hard work to make it easy for users
Delivery approach: Leverage and iterate
Leverage and iterate Knowing when & where to re-use, build,
or buy
Leverage and iterate Eliminate undifferentiated heavy lifting
commodity custom
Leverage and iterate Use Open Source
Leverage and iterate Use the ☁ (Software & Platforms &
Infrastructure as a Service)
☁ Software
Leverage and iterate SaaS: Support and ticketing systems (JIRA, Zendesk,
GitHub)
☁ Software ☁ Platform
Leverage and iterate PaaS: Application runtime and resiliency (Heroku, Cloud
Foundry)
☁ Infrastructure ☁ Software ☁ Platform
Leverage and iterate IaaS: Hosting (AWS, Azure, Vault, GCP) IRAP
accredited by ASD
☁ Software ☁ Infrastructure ☁ Platform digital service
Risk management approach:
minimise technology investment risk
integration not adaptation
“Give me an API, or give me death”
interoperability through high quality APIs
more options down the road
your systems end up being more resilient in the face
of change
But harder work because you must grow & maintain a
high performing culture
But harder work that supports a highly skilled software engineering
workforce
Redesigning the org to better meet policy and service delivery
outcomes
Feedback loops built in to the software we ship
Feedback loops supporting hypothesis driven development
Meeting objectives on-time & on-budget
High-performing IT organisations report experiencing: 22% less time on unplanned
work and rework
Meeting objectives on-time & on-budget: data driven
Meeting objectives on-time & on-budget: weekly granularity
Meeting objectives on-time & on-budget: reported up and out
Trending towards state of devops metrics 200x more frequent deployments
24x faster recovery from failures 3x lower change failure rate 2,555x shorter lead times 22% less time on unplanned work and rework
“People with targets […] will probably meet the targets -
even if they have to destroy the enterprise to do it.” – Deming
Where do we start?
Start on the edges
Pick a small problem
Understand and serve a user need (as well as a
government need)
You can not sustainably meet user needs if you are
not meeting your own needs at the same time.
Use the Digital Service Standard as the guide for what
good looks like
Start with this
Then do this
Then this
Create small, multi-disciplinary teams
Template: 1x front end developer 1x back end developer 1x
user experience designer 1x agile coach (part time)
Use the Digital Service Standard as the guide for what
good looks like
No executive sponsorship? Don’t even bother.
Set delivery constraints
⏰ Time Budget Scope (pick 2)
Build the smallest, simplest thing that meets a user need
“You build it, you run it” – Vogels, AWS
Don’t change what tech you use
Change how you use that tech
Don’t blow your innovation budget on experimenting with tech
All changes go through a Continuous Delivery pipeline
deploy to production acceptance tests integrate unit tests code done
Continuous Delivery Manual Auto Auto Auto
Multiple deploys a day
High-performing IT organisations report experiencing: 200x more frequent deployments
Code doesn’t create value until it is running in front
of a user
Ship usable software multiple times a day
Write high level acceptance tests (like Cucumber)
An executable specification
Feature: Refund item Scenario: Jeff returns a faulty microwave Given
Jeff has bought a microwave for $100 And he has a receipt When he returns the microwave Then Jeff should be refunded $100
Nail your automated delivery pipeline from the start
Decouple what you build from existing systems
Build in isolation
Don’t create dependencies
Manual processing is OK
No point investing in automation until you have validated the
service meets a user need
Risk: you automate the wrong thing
automation is a means
meeting a user need is the end
manage team workload by: only sending a percentage of the
workload to the service
Bonus: build empathy with users by doing the grunt work
What happens next?
DO NOT DISBAND THE TEAM
The team don’t get reabsorbed
The service doesn’t get lobbed over the wall
It’s not a one-off
It’s not a project
It’s a long lived service
Team and service need to be resilient
Team continues with the service
No executive sponsorship? Don’t even bother.
“This worked well! Let’s scale it up!”
Limit scope creep
Amazon’s two pizza teams rule
Don’t aim for economies of scale
Scale out, not up
The goal: Simple, self contained systems, interacting with one another…
The goal: … supported by teams who are iterating each
system independently, to meet complex user needs.
Prefer duplication over dependency
Dependencies introduce blockers
You don’t want blockers when you’re iterating quickly
But what about legacy?
“APIs for applications”
Teams create APIs for services they consume
legacy system new service intermediary API new system
Longer term: modernise your existing systems
Longer term: upgrade functionality, peicemeal
legacy system new service intermediary API ❌ ⬅ manual at
first
Event sourcing
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
https://developers.soundcloud.com/blog/building-products-at- soundcloud-part-1-dealing-with-the-monolith
Short term: It’s not about modernising your legacy
It’s about providing services that meet user needs
It’s about organising people in your organisation to meeting those
user needs
It’s about building the future of how your organisation works
The biggest challenge:
Minimal software engineering culture in the APS
Leverage and iterate Knowing when & where to re-use, build,
or buy
Limiting and managing risk
commodity custom
We must drive a cultural change in technology delivery
We do that by attracting talent & cultivating the talent
we have
We do that with modern technology delivery practices like continuous
delivery
We do that by reinforcing the resiliency of our organisations
“If the government was a private company, it would go
out of business”
Great sound bite
Counterfactual
Government is not a private company
Businesses are designed to fold
When a business fails: People become unemployed.
When a business fails: Assets are liquidated.
When a business fails: Creditors are paid.
When a business fails: Shareholders loose cash.
When a business fails: If there is demand, other businesses
in the market will fill that gap.
Governments are designed not to fail
Government is designed to be resilient
When a government fails: The underpinning of a society disappears.
When a government fails: Folk-systems emerge to fill the gaps.
When a government fails: Inequality and inequity thrive.
When a government fails: People get hurt. People die.
Government has built-in inertia
Inertia is linked to resilience
Government is designed to be resistant to change
Digital transformation of government means changing something designed not to
change
Resilience is our greatest strength and our greatest weakness
Newton’s first law an object at rest stays at rest
Newton’s first law an object in motion stays in motion
Newton’s first law an object in motion stays in motion
with the same speed
Newton’s first law an object in motion stays in motion
with the same speed and in the same direction
Newton’s first law unless acted upon by an unbalanced force
Digital transformation is your unbalanced force
We must drive a cultural change in technology delivery
We do that not by changing the technology we use
We do that by changing the how we use that
tech
We do that with modern technology delivery practices like continuous
delivery
We do that by attracting talent & cultivating the talent
we have
I’m Lindsay
Thank you