Mike Dilworth, Technical Director, Capgemini, explains how to evangelise DevOps, as well as create and implement strategies to achieve DevOps at scale within the public sector

Dilworth has more than 25 years’ of experience in the IT field, holding roles onshore and offshore within software, systems and network engineering. In 2012, when he returned back to the UK, he began to head up infrastructure and operations for Thomas Cook’s E-commerce Centre of Excellence.

“Here, as part of data centre consolidation, rationalisation and cloud strategy, I began to implement key technologies and ways of working that today form the mainstream of DevOps,” Dilworth explains.

“Following this, I perfected my work within DevOps at Sainsbury’s where I had the opportunity to deliver DevOps at scale and implement an AWS cloud first strategy as part of a major digital transformation programme.”

DevOps culture

Now working for Capgemini, he continues to evangelise DevOps within large-scale cloud migration and transformation programmes for the UK public sector. He has been engaged with the Home Office’s Immigration portfolio project and contributed to delivering a double award-winning large-scale AWS migration. Nevertheless, for him, DevOps is the catchall.

“DevOps is not a software development methodology. It is not a role or a job title, nor is it a team or a group name. Instead, DevOps is a culture which the whole organisation should be doing for it to succeed,” says Dilworth.

“Very often you see agile development working in isolation. Unfortunately, water – scrum – fall are very prevalent. Yet, with DevOps, it is all or nothing. However, you can implement aspects of DevOps to achieve pragmatic improvements in value streams and thereby demonstrate the worth of pursuing further improvements and rolling such initiatives out to the wider community.”

According to Dilworth, if an organisation is “really doing DevOps”, then all software testing is tightly integrated into the value stream.

Creating secure software

“We shift things left and we don’t wait until the product or service is ready for launch before starting security tests. From a delivery perspective, we build security testing into the continuous integration (CI) pipeline so that we can detect and fix issues early. It is much easier, faster and cheaper to fix problems at integration rather than in production,” he continues.

Furthermore, Dilworth advises to follow the following principles to create secure software:

• apply security measures per story
• encrypt at rest and in transit
• use SSO for offshore and onshore users’
• have a way of providing auditable information
• have authentication/authorisation between services
• enforce protected branches
• enforce reviews via pull requests
• require signed commits
• have a well defined, understood and enforced code review process
• ensure you have fast, repeatable deploys with automated testing
• monitor security advisories and patches.

To evangelise DevOps, as well as create and implement strategies to achieve DevOps at scale within the public sector, Dilworth believes it’s important to engage with leadership to describe and show, using key business metrics, for the art of the possible.

DevOps transformation

Dilworth adds: “Whole scale transformation to DevOps is not possible unless you can issue “Jeff Bezos style” mandates! Cultural change is very difficult, especially as many do not understand what DevOps or lean is.

“What we do in the public sector is to educate at the higher levels, and then attempt to scale by providing either shared services or centres of enablement which have been created by successful localised initiatives.

“In this way, you can make smaller incremental improvements in more manageable and controllable environments.  These can then be rolled out to larger communities. We aim to create self-service, commodity services that are easily and cheaply consumed and thereby demonstrate that doing the “right thing” has wider benefits.”

Dilworth also adds that, when creating key advisory relationships with senior clients and internal stakeholders don’t tell them you dislike their product or service; look for and communicate the positives of what the client is doing; always have a constructive message, or offering, to partner any criticism; help the client succeed; accept that sometimes you are wrong and respect clients’ delivery pressures!

Written by Leah Alger