5 lessons: How DevOps, cloud reinvented IT Ops at Hiscox

Source – techbeacon.com

As a global business insurer, Hiscox faces two significant challenges. The first is that, while we are growing at up to 30% per year in some markets, we don’t want our IT staff to balloon at the same pace. We also must stay nimble enough to fend off behemoths such as Amazon and Google that could use their stockpiles of customer data (and their ability to quickly roll out new services) to move into our industry by using that data to manage risk and underwrite policies.

To meet both challenges, I’m moving Hiscox into cloud computing and toward DevOps, in which developers and operations staff work together to move applications to market more quickly. The cloud, managed with the help of IT automation software, boosts productivity and frees IT staff for strategic challenges. DevOps and the rapid rollout of new services, meanwhile, allow IT to quickly roll out new applications as customer and business needs change.

But this is an ongoing journey. While Hiscox is a long way from being cloud-first, by the end of this year we plan to host 50% of the apps we care about in the cloud, achieving cost reductions of up to 30% for some workloads.

When it comes to DevOps, we’ve have made good progress changing our development practices, achieving a 97% drop in the cost of each code release, and jumping from 2 code releases per week to 50 a day. We haven’t focused too much on operations, since they’re not fundamentally broken.

From our work so far, here are five of the biggest lessons we’ve learned.

1. Have patience

After preaching the benefits of DevOps for five years, I mistakenly assumed that everyone else in IT shared my vision and was eager for change. I underestimated the time and effort required to introduce cultural change, and when facing resistance, I sometimes told people when I thought they were doing their jobs wrong. That just got people’s backs up, rather than including them in the solution.

Instead of continuing to hammer on the skeptics, I’ve learned to listen to their concerns, and I try to turn them around. A lot of people voice their concerns in such terms as “What does it mean for me?” and “Will I have a job anymore?” When you get them to open up, some operations staff are scared that DevOps is mostly about application development and that their specialized skills in server, storage, or networking won’t be needed.

We assure them that those skills, as well as their understanding of the insurance industry and Hiscox’s business history, still make them valuable. But I also point out that as organizations such as ours move more routine IT management work to cloud service providers, operations staff need to develop new skills such as programming, testing, automated IT management, and continuous deployment to stay relevant in a fast-changing industry.

2. Show, don’t tell

You can talk about the benefits of DevOps and cloud until you’re blue in the face and not get through to doubters. But if you put them on an agile team for three months, they come out saying, “That’s amazing.” When it’s theoretical, people are quite skeptical. When it’s real, people love it.

3. Be prepared to shuffle your org chart

Don’t try a “big bang” approach of moving every IT function to the cloud and DevOps at once. Instead, create teams of early adopters that evangelize and coach your staff in the use of new tools, such as continuous deployment and web-based code repositories. Be sure to stress the business benefits at every step.

Realize also that there are no easy answers to some organizational questions. We are struggling, for example, over which IT functions and technologies to manage centrally and which to federate to business units. Too much central management can keep business units from getting the capabilities they need, while too much local control risks duplicating technologies and work and wasting money. For example, Hiscox has historically been a Microsoft SQL Server shop. Now, one business unit wants to consider Oracle. But if it migrates, the central database team will lack the right skills, people, and backup solutions to manage the new deployment. That means a whole load of other costs that Hiscox must weigh against the business benefit.

4. Look for soft skills, not just technical chops

There is too much new technology available to expect one person to know it all. But the right person will go out and learn what they need. When hiring, look first for an openness to change, the ability to learn, and a willingness to work with others.

Evaluating these traits is a very unscientific process. Some of it involves gut feel. Some of it involves interviewing as many different stakeholders as possible, including members of the team the new hire would join, prospective managers, and human resources. We also test an applicant’s ability to relate to others.

The same criteria hold true for finding early adopters among existing employees. We do a lot of internal “lunch and learn” sessions and take note of the people who stick their hands up, wanting to know more. That creates a natural selection process.

We also conduct a talent-mapping process twice a year, scoring employees on such things as their ability to accept change. Those who score higher are a better bet to successfully make the leap to DevOps and cloud.

5. Share your successes—and failures

Success stories show the impact of the change you’re making and thus drive adoption. One of my favorite stories is how one of our staffers deployed a new version of an application from his smartphone while on a bicycle outside St. Paul’s Cathedral in London. That’s an exciting demonstration of the art of the possible, especially when compared to the conventional deployment process of 10 people sitting around a desk at 4 o’clock in the morning. When their peers hear something like that, they get excited and say, “I’d like to do that, too.’”

You also need to share failures to build credibility and trust. When your new tools or processes go wrong, admit you made a mistake, but also explain what you’re doing to prevent a repeat. For example, one team using the Puppet software configuration tool to reconfigure a firewall accidentally caused application instability. The team owned up to the error but went on to describe to the business how it took steps X, Y, and Z to make sure it wouldn’t happen again. No one can argue with that approach, because everyone understands that problems happen. But when you try to cover up or blame other people, you don’t get the results you need.

My final advice: Be brave, because it is a hard slog shifting your culture toward the cloud and DevOps. But the rewards are worth it, both for your own career and for the organization you serve.