1) The document discusses DevOps at Hiscox, an insurance company. It describes how Hiscox is moving from separate development and operations teams to cross-functional teams that share goals and responsibilities from development to deployment. 2) A key part of Hiscox's DevOps transformation is the creation of a Platform Services Group that provides reusable tools and services to help different teams deliver changes more efficiently. 3) The document shares an example of how Hiscox used IBM's UrbanCode Deploy tool to automate application deployments, reducing the effort from over 2 weeks to just 10 minutes for one application releasing 47 times in a week.

1. © 2014 IBM Corporation
DevOps at
Jonathan Fletcher
Enterprise Architect – Technology & Platform Lead
Hiscox

2. Me
• Jonathan Fletcher
• Architect in Hiscox Group IT since 2012
• Ex Dev
• Ex Ops
• http://enterprisedevops.blogspot.com
• http://www.devops.com
• @FletcherJofanon

3. Introduction
• What DevOps means to Hiscox
• Brief history of DevOps at Hiscox
• Patterns and practises of implementing DevOps at Hiscox
• How IBM are helping Hiscox
• Q&A

4. DevOps – classical definition
Development Operations
Culture of shared goals that reduces the friction between
Development and Operations

5. DevOps friction
Moreprocessreviews
Morechangecontrol
reviews
Moredeployment
freezes
Morestandardscontrol
boards
Morefrequentchanges
Lowertolerancefor
outage
Morecomplex
applications
Morecomplex
deployments
Do more! Do less!
RFC’s
CAB
Deployment guide
Rollback guide
Daily status calls
Staff availability
Issue tracking
Environment
booking
Escalation
processes
Emergency
processes
Small change
processes
etc etc
Mr. Dev Mr. Ops

6. DevTestBizThingyOps
• Why do we think the issue of working well together and
aligning goals is limited to Development and Operations?
• Shouldn’t everyone involved in the change process should
work together to accomplish shared goals?
• DevTestBizThingyOps should be the real name © J.Fletcher

7. BermudaUS Europe London MarketsUK
Hiscox yesterday (ish!)Capability
Group
development
Group
support
Group
infrastructure
Group testing Group DBA
Group
release and
deployment
Group
architecture

8. Hiscox tomorrow (ish!)
Europe
Dev
Support
Testing
DBA
Release
and
deployment
Architecture
UK
Dev
Support
Testing
DBA
Release
and
deployment
Architecture
London market
Dev
Support
Testing
DBA
Release
and
deployment
Architecture
USA
Dev
Support
Testing
DBA
Release
and
deployment
Architecture
Bermuda
Dev
Support
Testing
DBA
Release
and
deployment
Architecture

9. Hiscox Model (in progress)
• Federated
• Cross skilled teams
• Cradle to grave responsibilities
• Shared goals and incentives
• Underpinned by the Platform Services Group
• What started out as an ambition to increase the pace of
change has evolved into “rebooting” the IT team

10. Shared goals – a DevOps example

11. Platform Services
• Growth of the business is challenging IT to find new and
better ways to do things
• Means worker smarter not harder. Doesn’t mean ever
increasing head count
• Help break down silo’s between teams by providing a change
platform that is re-usable between multiple teams
• Help others use the platform (they don’t do the doing!)

12. Core platform capabilities
• Source code management (i.e. SVN, TFS)
• Artefact management (i.e. Artifactory)
• Automated application deployment (i.e. IBM Urbancode Deploy, Octopus)
• Automated server configuration (i.e. Puppet)
• Load performance test (i.e. LoadRunner, JMeter)
• Automated regression test (i.e. Selenium, QTP)
• Continuous Integration and automated code build (i.e. Jenkins, TeamCity)
• Application Performance Management (i.e. DynaTrace)
• Agile planning (i.e. Jira, Rally)
• Defect management (i.e. Jira, QC)

13. Be careful...
• Having a team that evangelises DevOps ideas, concepts and
tooling is GOOD
• You don’t solve a silo issue by creating another silo! BAD

14. How are IBM helping?
• Currently implementing our first project using UrbanCode
Deploy
• Biggest change program Hiscox has ever undertaken
• Risky? Couldn’t deliver it any other way!
 47 releases last week in 1 application alone
 17.5 man days of effort reduced to about 10 minutes
 We went from 1 person knowing how to do a release to potentially
dozens
• Investigating proof of concept with IBM Greenhat Service
Virtualisation

15. Continuous Delivery change approach
Dev
Version
control
(SVN)
1. Check in changes
Build
(Maven)
3. Build
Artefact
repository
(Artefactory)
4. Store artefacts
Regression
test
(Selenium)
8. Test
Performance
test
(JMeter)
9. Load test
SysTest
UAT
Production
10. Deploy
CI Test
servers
7. Deploy
CI
(Jenkins)2. Monitor for changes
Continuously automated
On demand – click
button to deploy
Deployment
(uDeploy)
5. Instruct deployment
Server
config
(Puppet)

16. Convincing your boss
• Avoid lots of ROI calculations - management (in particular finance) take
these with a pinch of salt
• Do a PoC – let people see stuff
• How are you going to do it otherwise?
• Multi-releases a day?
• Availability of resources?
• Cost of those resources?
• Geographic location?
• Morale
• Consistency
• etc

17. © 2014 IBM Corporation
Thank You