How to apply enterprise DevOps to any business.

1. Software
is
eating
the
enterprise
10
DevOps
tips
to
help
you
take
control
before
it’s
too
late
Jonny Wooldridge, CTO

2. Me:
CTO
Head of Web Engineering
Director of Platform Development
Lead Developer / Head of Development
Web Master / Lead Java Developer
2014
Board Advisor
2011
2007
2003
1999

3. Marks
&
Spencer
Founded
1884,
85,000
staff
£10.3
Bn
group
revenues
! 2011-2014 introduced DevOps to international omni-channel retailer
Marks & Spencer as part of a successful £150 Million retail re-platforming
project. The importance of DevOps now understood at board level.
! 650 Member project team, 65 new or modified applications.
! On time and on budget.
! The control of the software delivery lifecycle via Devops principles IMHO
kept the programme on the rails.

4. Cambridge
Satchel
Founded
2008,
120
Staff
£10M
total
revenues
£100M
by
2017
! Now back in start-up world at Cambridge Satchel but the enterprise
lessons are key to building a successful and relevant technology
strategy which has longevity and agility.
! $20 Million index ventures investment - clean sheet with technology
online, in store, in manufacturing and in the warehouse.
! Lessons learned in Enterprise DevOps applied everyday.

5. Cambridge
Satchel
;-­‐)
Everyone
else
Cambridge
Satchel
Affordable
Luxury

6. Lessons learned in large enterprises
are absolutely relevant to anyone
creating software
Why
relevant?

7. Define
‘enterprise’

8. TIP #1 OVER
COMMUNICATE
YOUR
PLAN

9. Over
Communicate
your
plan
What are you aiming for and what
value
will it bring?
Paces
within
enterprise
applica/ons
So2ware
Factory
/
Tooling
Why invest in DevOps, BDD, Automation?
A very valid question whether large enterprise or start-up

10. Over
Communicate
your
plan
elevator.
! Plan your attack and be prepared for the
! Make friends across the business. You have no time for
enemies. You will have to call in favours.
! Keep it simple even when it’s hard. Simple metrics.
! << Show it working to bring it to life >>
! Use Diagrams and keep in your back pocket.
! You get noticed in an enterprise if you care. So care (a lot).

11. Over
Communicate
your
plan
and the team
“It’s all about the code”
Application code, Test code, Configuration code, Script code,
infrastructure code, 3rd Party Binaries!

12. Over
Communicate
your
plan
High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Team
So[ware
Agile/Lean
prac^ces
Great
So[ware
Good
prac^ces
Good
So[ware
Poor
working
prac^ces
Poor
So[ware
Bad
working
prac^ces
Bad
So[ware

13. Over
Communicate
your
plan
High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
$$$
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
$$$$
$$
$
Understand
the
cost
to
the
organisa^on
of
slow
releases
Integra^on
test
costs
Cost
of
rework
Cost
of
delay
and
hand
off
Cost
of
building
the
wrong
thing
Cost
of
not
asking
the
right
ques^on

14. DEFINE
THE
TIP #2
PACE
OF
YOUR
APPS

15. Define
the
pace
of
your
apps.
“Let’s do DevOps” << Grass roots desire from IT
Energising
“What the..” << Middle managers
Distracting
“Why can’t we release 10x a day” << Board Directors
Scary – expectation setting required

16. Define
the
pace
of
your
applica^ons

17. Define
the
pace
of
your
applica^ons
Pace of
Delivery

18. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Not
all
applica^ons
should
be
treated
in
the
same
way
Understand
the
pace
layers
of
your
apps
and
governance
needed
How
good
are
the
major
vendor
Ecommerce
and
Finance/ERP
systems?
Define
the
pace
of
your
applica^ons
Front
End UI!
Finance!
Systems!
Payment!
Order !
Mgt!
Core!
Ecomm!
Digital!
Asset!
Cust.!
Mgt!
Apps!
API
API
API
API
API
API
API
API

19. High
The team’s level
of agile working
practices
(Agile/lean)
You
want
to
be
here!
For
everything?
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Fight
the
right
bafles
with
your
legacy
Where
you
invest
your
$$
is
cri^cal.
Invest
in
DevOps
where
it
mafers.
Define
the
pace
of
your
applica^ons
DevOps
without
legacy
is
easy.
Front
End UI!
Finance!
Systems!
Payment!
Order !
Mgt!
Core!
Ecomm!
Digital!
Asset!
Cust.!
Mgt!
Apps!

20. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Moving
exis^ng
legacy
apps
to
faster
delivery
is
hard
Don’t
make
the
mistake
of
over
promising!
Trying
to
improve
all
of
your
applica^ons
just
won’t
be
prac^cal.
Define
the
pace
of
your
applica^ons
Really?
Legacy
Zone

21. KILL
DEPENDENCIES
TIP #3
AT
ALL
COSTS

22. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Components
have
no
dependencies
that
require
tes^ng
in
a
shared
test
environment
with
corporate
applica^ons
Many
corporate
dependencies
that
require
tes^ng
with
each
other
and
co-­‐ordina^on
of
data
/
process
Kill
dependencies
at
all
cost
Legacy
Zone

23. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Reduce
your
legacy
and
create
new
capability
Reduce
size
and
complexity
of
slow
moving
applica^ons
Kill
dependencies
at
all
cost
E.g.
consider
crea^ng
a
Front
End
separa^on
layer
enabling
parts
to
be
independently
released
NEW
Legacy
Zone

24. Kill
dependencies
at
all
cost
Great Book.
Everyone now wants to deploy a
‘minimum viable product’
Define ‘viable’ in an enterprise

25. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Many
organisa^ons
want
to
be
lean
and
get
value
to
their
customers
quickly
Understand
what
is
really
a
viable
MVP
Kill
dependencies
at
all
cost
A
change
considered
fast
is
now
very
slow
as
it
needs
to
be
coordinated
with
a
corporate
release.
Legacy
Zone
NEW

26. Kill
dependencies
at
all
cost
! Only when you have end
to
end
visibility
of
speed of delivery across your ecosystem will
you be able to define an MVP.
! Product Owners need to understand
the
dependencies to prioritise.

27. Kill
dependencies
at
all
cost
! Understand
ALL
of
your
dependencies: Obsessively understand
and control your dependencies. It is your dependencies with other
applications, particularly corporate systems that will slow you down.
Try to avoid the dreaded corporate Integrated Test phase.
! Decouple
your
applicaIons
&
architecture:
– create services and
separate the layers of your application wherever possible.
! Decouple
your
people:
Give your teams more responsibility end to
end and greater autonomy. Remove dependencies on other teams
wherever possible.

28. Kill
dependencies
at
all
cost
! Integrate
with
3rd
parIes
carefully. Bad choices with 3rd
party integrations can kill your speed of deployment as you can
become dependent on their deployment cycles, which ultimately
slow your own.
! Stubbing: Intelligent stubs can be a good solution but is hard
and requires a strategy on ownership.
! TesIng
is
easier
with
less
dependencies:
Test scenario
complexity is reduced, test data alignment is less onerous with
fewer external dependencies.

29. DON’T
TIP #4
CREATE
NEW
‘LEGACY’

30. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
An
example
project:
part
1
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
STEP
1:
Start
with
good
inten^ons
In
this
example
the
team
are
aware
of
DevOps
and
start
automa^ng
build/deploy/
test
and
using
Con^nuous
Integra^on.
The
Opera^ons
team
are
involved
early.
Enterprise
Project
Methodology/
Governance/Finance
promotes
integrated
test
phases
and
big
bang
deployment.
The
inten^on
is
to
deploy
independently
hence
it’s
posi^on
on
the
grid.
The
plan
is
to
think
about
Con^nuous
Delivery
later
in
the
project
Don’t
create
new
‘legacy’
NEW
Legacy
Zone

31. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
An
example
project:
part
2
Level of Independently testable and
deployable software
Low
High
STEP
2:
The
inevitable
project
pressures
show
up
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
The
team
is
under
pressure
and
func^onality
is
priori^sed
over
keeping
automated
test
and
deployment
scripts
updated.
Ops
team
not
as
engaged
as
they
had
been.
The
team
tried
BDD
but
did
not
con^nue
with
it
as
the
value
wasn’t
being
seen.
Project
Manager
requests
a
detailed
plan
for
all
tasks
un^l
go-­‐live.
Agility
starts
to
slip.
Technical
debt
increases.
Don’t
create
new
‘legacy’
NEW
Legacy
Zone

32. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
An
example
project:
part
3
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
STEP
3:
Find
corporate
legacy
dependencies
The
applica^on
was
on
track
to
be
delivered
but
new
dependencies
are
found
(e.g
with
corporate
repor^ng
and
finance
systems
or
corporate
middleware)
The
new
applica^on
is
now
^ed
into
a
corporate
release
cycle.
Importantly
the
applica^on
might
now
always
be
^ed
into
corporate
release
cycle
un^l
the
dependencies
are
broken
(if
that
is
possible)
Don’t
create
new
‘legacy’
Legacy
Zone
NEW

33. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Set
the
bar
high
for
new
ini^a^ves
/
programmes
When
a
new
ini^a^ve
comes
along
and
a
new
team
is
built
to
deliver
it
set
the
bar
high
with
DevOps
opera^onal
requirements
and
ways
of
working.
Encompass:
• Behaviour
Driven
Development
• Con^nuous
Integra^on
• Con^nuous
Delivery
• Full
automa^on
• Robust
configura^on
management
Don’t
create
new
‘legacy’
NEW
Legacy
Zone

34. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Ensure
your
corporate
project
methodology
encourages
DevOps..
…else
you’ll
create
legacy
every
^me
Don’t
create
new
‘legacy’
Legacy
Zone
NEW
How
do
you
measure
success
of
your
projects?

35. Don’t
create
new
‘legacy’
! <<
Make
end-­‐to-­‐end
process
a
deliverable
>>:
You need to find a way to
ensure that the full end to end process of delivering software is part of the project. If it is not
the teams will lose focus and potentially slip into traditional ways of working that are more
familiar.
! Product
Teams
vs
Project
Teams:
Product teams are far more likely to want the
end-to-end process to be fast, for the software to have low levels of technical debt and be
easily supportable.
! Legacy
≠
old:
Many teams, and perhaps the majority in an Enterprise (even those using
agile methods) are set up to deliver legacy. It might be functionally rich and value creating
legacy, but it will be difficult to move into continuous delivery.
! Coaching
and
Mentors:
It is crucial that help is on hand to show the teams what
good looks like and to keep them on track both from a team point of view and technology

36. DEVOPS
IS
NOT
TIP #5
JUST
AN
IT
PROBLEM

37. DevOps
is
not
just
an
IT
problem
! Project
Methodology.
A gated Waterfall based project
methodology will lead to a focus on dates not necessarily value creation
and customer satisfaction.
! HR,
recruitment
and
rewards
- in the same way that Agile was
disruptive, DevOps is even more so as it affects the wider team and
end-to-end processes. Often organisational structures at a high level,
and the bonus and rewards received encourage silo thinking.
! Finance
&
Procurement
– funding allocation and total cost of
ownership. A better built app today is worth the investment but may not
get funding. Tool purchases can stall waiting on the procurement
process.

38. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Wrong
3rd
Party
Suppliers
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Enterprise
equilibrium
tends
to
push
your
DevOps
adop^on
backwards
DevOps
is
not
just
an
IT
Problem
Make
the
wrong
choice
and
the
forces
may
be
working
against
your
goal
Wrong
technology
of
faster
delivery.
choice
Wrong
hiring
policy
Wrong
contractual
&
financial
frameworks
Wrong
team
objecIves
&
rewards

39. You
are
unique.
TIP #6
Think
for
yourself

40. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Cloud
Adop^on
Level of Independently testable and
deployable software
Low
High
A
shared
DevOps
capabilty
can
speed-­‐up
other
team’s
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
DevOps
adop^on
A
shared
capability
to
assist
environment
crea^on
and
tool
setup
You
are
unique.
Think
for
yourself
Oil
the
enterprise
machine
by
removing
common
impediments
Automa^on
Ways
of
Working
Shared
Tooling

41. You
are
unique.
Think
for
yourself
High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
You’re
going
to
have
to
think
for
yourself.
?
There
are
s^ll
a
lot
of
areas
of
enterprise
DevOps
that
s^ll
need
to
be
answered
?
?
✔
Keep
an
open
mind
and
innovate
yourself

42. TIP #7 MAKE
YOUR
TOOLS
WORK
FOR
YOU

43. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
Expensive
Tooling
won’t
move
the
needle
on
its
own
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Wrapping
en^re
legacy
applica^ons
in
new
automa^on
deployment
so[ware
isn’t
the
answer.
Don’t
automate
your
legacy
processes!
Make
your
tools
work
for
you
Legacy
Zone
$$$

44. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
MULTIPLE
DIGITAL
TOOLSETS
Mul^ple
sets
of
tools
need
to
co-­‐exist
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
New
Ways
of
working
dictate
new
flexible
connected
tooling
..specifically
don’t
be
^ed
to
your
corporate
toolset
Make
your
tools
work
for
you
Embrace
best
of
breed
Open
Source
and
make
sure
you
don’t
get
^ed
to
a
par^cular
tool..
TRADITIONAL
TOOLSET

45. Make
your
tools
work
for
you
! <<New
Digital
Toolset
>>:
Create a decoupled toolset of best of
breed tools. You don’t need the same tools for all paces.
! Don’t
be
held
back
by
corporate
toolset:
Corporate tools generally
don’t cut it
! Make
your
tools
work
for
you:
Don’t change the way you work
because you have a new tool. Make sure the tool works for you not
the other way around.
! Embrace
OpenSource
where
possible:
but don’t rule out paid for
products if it makes sense.

46. BUILD
TIP #8
A
SOFTWARE
FACTORY

47. Build
a
So[ware
Factory
You wouldn’t manufacture any other product at scale with
ad-hoc methods and so little visibility and traceability

48. Build
a
So[ware
Factory
for
control
and
visibility
! Build
a
so^ware
factory,
why?
! Let developers focus
on
creaIvity
– the creative aspects of
writing code, not how their code gets into environments for
testing
! Connect
your
tooling
to get value and increase visibility.
Network affect.
! Don’t
forget
informaIon
security! Add them into your build
pipeline.
! Get visibility
of
everything
– visibility of every code commit,
every requirement, bug and release. Auditors will love you!

49. Build
a
so[ware
factory
! Thanks to Magentys for following factory slides:
! www.magentys.io

50. Slave
Controller
Prepare
Master
Controller
Build
Code
Run
Tests
Build
ApplicaIon
Tooling
Setup
Run
Tests
Deploy
Code
Provision
Source
Code
&
Binary
Store
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Live
Dashboards
Wiki
/
Documenta^on
Plans
Data
Test
Lab
results
Tests
✔ ✔ ✔ ✔ ✔ ✖
Scripts
Test
Environment
images
Base
apps
Store
Prepare
images
Base
apps
Scan
Slave
Controller
Unit
test
Tests
Binary
Binary
Build
a
So[ware
Factory
©

51. Source
Code
&
Binary
Store
Build
a
So[ware
Factory
Plans
Live
Dashboards
Scripts
images
Base
apps
Master
Controller
Code
Tests
Binary
ApplicaIon
Tooling
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Wiki
/
Documenta^on
Data
Fully
Integrated
tools:
• Requirements/Wiki
• Source
©
Code
Mgt.
• Binary
Store
• Code
check-­‐in/build
• Code
Quality
scan
• Environment
Mgt.
• Deployment
• Test
• Log
Storage

52. Build
a
So[ware
Factory
Master
Controller
Code
Source
Code
&
Binary
Store
Plans
Live
Dashboards
Scripts
images
Base
apps
Tests
Binary
ApplicaIon
Tooling
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Wiki
/
Documenta^on
Data
Fully
Integrated
tools:
• Requirements/Wiki
• Source
©
Code
Mgt.
• Binary
Store
• Code
check-­‐in/build
• Code
Quality
scan
• Environment
Mgt.
• Deployment
• Test
• Log
Storage

53. Build
a
So[ware
Factory
Slave
Controller
Prepare
Master
Controller
Build
Code
ApplicaIon
Tooling
Source
Code
&
Binary
Store
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Live
Dashboards
Wiki
/
Documenta^on
Plans
Data
Scripts
images
Base
apps
Build
Code
Scan
Unit
test
Tests
Fully
Integrated
tools:
• Requirements/Wiki
• Source
©
Code
Mgt.
• Binary
Store
• Code
check-­‐in/build
• Code
Quality
scan
• Environment
Mgt.
• Deployment
• Test
• Log
Storage
Store
Binary
results

54. Slave
Controller
Prepare
Master
Controller
Build
Code
Run
Tests
Build
ApplicaIon
Tooling
Setup
Run
Tests
Deploy
Code
Provision
Source
Code
&
Binary
Store
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Live
Dashboards
Wiki
/
Documenta^on
Plans
Data
Test
Lab
results
Tests
✔ ✔ ✔ ✔ ✔ ✖
Scripts
Test
Environment
images
Base
apps
Store
Prepare
images
Base
apps
Scan
Slave
Controller
Unit
test
Tests
Binary
Binary
Build
a
So[ware
Factory
©

55. Master
Controller
Build
Code
Code
Test
Lab
Tests
ApplicaIon
Tooling
Setup
Run
Tests
Source
Code
&
Binary
Store
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Live
Dashboards
Wiki
/
Documenta^on
Slave
Controller
Plans
Data
Scripts
images
Base
apps
Tests
Binary
Provision
Deploy
Prepare
Run
Tests
Slave
Controller
Prepare
Build
Store
Scan
Unit
test
Test
Environment
images
Base
apps
Binary
Build
a
So[ware
Factory
©

56. Master
Controller
ApplicaIon
Tooling
Requirements,
Issues/Bugs
and
Workflow
BDD
GUI
Live
Dashboards
Wiki
/
Documenta^on
Data
Code
Source
Code
&
Binary
Store
Plans
Scripts
images
Base
apps
Tests
Binary
Build
a
So[ware
Factory
©

57. Test
Lab
Test
Environment
Source
Code
&
Binary
Store
Build
a
So[ware
Factory
ApplicaIon
Tooling
✔ ✔ ✔ ✔ ✔ ✖
Build
Code
Provision
env
&
Run
Tests
©

58. Build
a
So[ware
Factory
for
control
and
visibility
! Have insight into your offshore suppliers like never before
! Have control of your offshore suppliers like never before
! Software Delivery data and information in one place

59. MAKE
YOUR
PARTNERS
USE
YOUR
FACTORY
! Control
the
deliverables
from
your
partners
! Do you really understand who is working for you?
! Do you know the quality of the development?
! Maintain ownership of your delivery pipeline at all costs
! Force all suppliers through your
delivery
pipe
without exception
! Builds are created from your
code
repository and all 3rd Pary
binaries versioned and centrally stored.
! Again, if you show
you
care, your partners will care.

60. START
BEHAVIOUR
DRIVEN
TIP #9
DEVELOPMENT
TODAY

61. Start
Behaviour
Driven
Development
Today
! Absolute Game
Changer
in all companies I’ve introduced it
! BDD is more than TDD as it engages
the
business
– usually the
business switch off when talking tests
! Keeps DevOps
on
track
– forces the right kind of automation
! Keeps arIfact
aligned
with Code (Test code, Config, Test Data)
If you do nothing else today – read up on BDD.

62. PREPARE
TO
BE
THE
LARGE
TIP #10
ENTERPRISE
OF
TOMORROW

63. Prepare
to
be
the
large
Enterprise
of
tomorrow
..so as discussed earlier make the right choices
today with:
! Technology
! Hiring, Retention & Training
! Contracts & Procurement
! 3rd Party Suppliers and Vendors.
Make the correct choices to keep
on the correct DevOps trajectory

64. High
The team’s level
of agile working
practices
(Agile/lean)
Continuous
Delivery
Level of Independently testable and
deployable software
Low
High
So[ware
Design
Team
Low
Slow
Fast
Daily/Weekly
Independent
Monthly
Coordinated
Quarterly
Enterprise
Front
End UI!
Apps!
Cambridge
Satchel
Focus
on
systems
that
will
be
key
to
innova^on
We
will
be
here!
25%
Custom,
75%
SaaS
SaaS
solu^ons
where
possible
for
back
office
Strategy
to
stay
on
high
alert
for
crea^on
of
any
new
dependencies
or
Silos
Order !
Mgt!

65. Thanks
for
listening!
Thank
you
Jonny.wooldridge@cambridgesatchel.com
My
blog,
these
slides
and
other
musings
available
at:
www.enterprisedevops.com
/
www.enterprisedevops.io

66. HERE’S
WHAT
I’D
LIKE
HELP
ON

67. Here’s
what
I
would
like
help
on
If you’ve got the answers to any of these I’d love to hear
from you:
! managing test data in complex environments where
systems need aligned data
! Ensuring your Behaviour Driven Development scripts
(e.g. gherkin files) can be easily version managed across
multiple branches of code.
! Out of the box DevOps Factories?