BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Hiscox CTO Emphasises DevOps Is about Survival

Hiscox CTO Emphasises DevOps Is about Survival

Bookmarks

 

A migration towards using cloud platforms has been a catalyst to fully embrace an end-to-end DevOps approach at Hiscox, said company CTO Jonathan Fletcher in a talk at the DevOps Enterprise Summit in London in June.

Fletcher’s talk was titled ‘Sorry Mr(s) Ops, We Hadn’t Forgotten You - Part Two of the Hiscox Story’. It built on his talk from 2016 and highlighted the impact of their growing realisation that, despite making improvements such as reducing the number of people involved in a release from eight to two, increasing the number of deploys from two a week to fifty a day and reducing the deployment time from four hours to twenty minutes, IT operations had been overlooked; these successes were contained within the development teams and their continuous delivery pipeline. By considering ops’ role in DevOps and how to extend their practice of DevOps principles, Hiscox identified cloud as a strategy to build a foundation for increased flexibility, stability and reduced cost into the future.

Fletcher said that their choice of cloud vendor was Azure. They made this decision based on their observation that Amazon Web Services (AWS) and Microsoft Azure were clear leaders in this space. They ultimately chose Azure based on their existing commitment to Microsoft technologies.

An initial dislike for ‘lifting and shifting’ applications into the cloud without re-architecting to take advantage of the benefits of cloud has been superseded by the view that they will move as fast as they can and then fix later. This means that by the end of 2017 three of Hiscox’s biggest systems, transacting hundreds of millions of pounds of business, will have gone live in Azure.

By 2020, Fletcher says Hiscox expect to be in the position where IT will be delivering strategic, competitive advantage rather than being a ‘subservient order taker’. The company also intends to flatten expenses costs as they grow by focusing on renting IT services rather than building them themselves.

We had an opportunity to explore Fletcher’s themes with him in more detail.

InfoQ: The audience loved the ‘IT-Less IT Team’ phrase you used – what are the steps you need to take to get to one business?

Jonathan Fletcher: From an IT point-of-view it’s about aligning tools, processes and ideas in IT and getting on a common platform. Then getting deeper integration with the business and federating IT out to the business – then removing IT as an entity and embedding IT skills into the business’ value streams. At Hiscox there is a group budget for IT that with cloud we are pushing back into the business as a discretionary spend.

It’s a really interesting this time in our lives to see how children use IT – my kid who’s two is using an iPad quite happily. People coming out of university will just have many IT skills without necessarily being in IT; so more and more IT skills will appear everywhere in a business with new generations.

And the move to cloud and consuming things rather than building them will also make this happen naturally. Using SAAS and doing due diligence to ensure that it’s the right product to use is a different skill set from designing and building it ourselves. It will reduce our IT touch points.

InfoQ: I’m sure many readers have heard the phrase you highlighted, ‘not my job’ – as you said, a classic DevOps anti-pattern. What’s the strategy for changing that behaviour?

Fletcher: It’s a cultural thing – we need to be focused on being a single team and all share the attitude that it’s everyone’s responsibility to get it over the line. Silos create handoffs. The Agile Manifesto helps with this in that the basis of it is that we are not individual parts but part of a greater team.

InfoQ: You say that cloud first is accelerating the DevOps revolution – what is the connection between cloud first and DevOps?

Fletcher: You can do cloud without doing DevOps but whether you should do it is the question. You are potentially just moving the problem. What moving to cloud gives you more is time to tackle the way you deliver stuff and make improvements around speed, quality, security and performance.

InfoQ: You say that DevOps is critical to businesses stealing a march on their competition. Why is this?

Fletcher: It’s around the changing role of IT. IT used to be a subservient order taker from the business but it’s becoming a two-way conversation.  We need to ask questions like if a process that took eight hours only takes twenty seconds, what does that mean for the business? Insurance in particular is about understanding risk, which is essentially a data problem; if we can understand the data problem we can serve our customers better.

InfoQ: Like many organisations at DOES, you have some challenges around getting ops on board - this problem we see with DevOps being done in dev. Why does this happen so much and how can we remedy it?

Fletcher: The focus on dev happens because first of all there is more obvious value in changing the development cycle because businesses want to get more change out of the door. The theory of continuous delivery gets people excited about change velocity as does the appetite for agile, which, of course, also came from a software engineering perspective. We need to try to take the ops guys on the same journey; help them move away from waterfall, get to automation, use lean tools and VSM – it’s the same approach. It’s a bigger jump though for Ops as they are unfamiliar to these ways of working – it’s a quantum leap for them. Things that can help them make that move are training, cross-skilling, mentoring and coaching – giving them the skills to just get on and do it.

InfoQ: What’s been the most valuable insight for you from the DevOps Enterprise Summit this year?

Fletcher: ITSM versus ALM is the big one for me driving lots of conversation about how to tackle this technology and process problem where these two things are so unfamiliar to each other – who wants to write a user story when they raise a support ticket?

Rate this Article

Adoption
Style

BT