Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

IntroductionThe idea of getting developers and operations staff to work closely together on development projects is hardly new. Talk to many IT veterans and they’ll tell you how they were doing exactly that as much as 20 years ago. Proponents of the DevOps approach, however, say the point of this method is not that it’s new, but the opposite: that it builds on what has worked well in the past.

To be sure, DevOps does involve applying tools and technology that were not available a couple of decades ago. But just as important is the organisational nature of the approach, and that’s where DevOps does mark a major departure from previous ways of working. A successful DevOps system means far more than getting two parts of a company to collaborate; it means slowly and systematically adopting a culture that ultimately can spread throughout the organisation. Those firms that have gone on the journey offer accounts of large gains in speed, quality and efficiency.

Yet despite all of the excitement surrounding DevOps, there remains a weighty challenge: evidence and reviews show that engendering cultural change for continuous improvement is one of the most difficult problems executives face. The IT experts featured in this article offer some practical ideas about what companies can do to make DevOps become a reality. From discussions with them, three themes stand out. First, and arguably most importantly, adopting a DevOps approach needs to be top-down as well as bottom-up. That may be contrary to some popular notions about innovation, but it is the only way the critical cultural component can take root. Second, companies need to focus on inclusivity. That means involving more than developers and operations staff and, crucially, bringing the business into discussions. Finally, firms need to recognise that the transition does not happen overnight and that it is an

In this article, Mike O’Hara and Adam Cox of The Realization Group investigate the

increasingly popular development method of DevOps, focusing specifically on what kinds

of organisational and cultural changes are involved in a successful transition that will

deliver real benefits. There is no question that DevOps has gained buzzword status in

the IT community. But how does a firm begin to adopt the approach and what are the

biggest challenges along the way? Mike and Adam talk to a diverse group of experts,

featuring IT specialists, consultants and corporate managers who are operating on the

front line of the DevOps world. They hear from Jane Such, Delivery Director at Certeco,

Steve Marshall, Change Delivery Manager at Nomura International, Helen Beal, whose

title is DevOpsologist at Ranger4 Limited, Bob Appleyard, Head of Consulting Project

Management at Sungard Availability Services, and Martin Moore, Business Integration

Gateway Platform Owner at Royal Mail Group. The message that emerges is that DevOps is

not so much about coding, apps and software. It’s about people, cultures and mindsets.

The DevOps Journey: Winning the battle of hearts and minds

Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

evolutionary process. Provided companies take all of that on board, there is no reason they can’t experience shorter development life cycles, greater efficiencies and faster time to market. And in today’s hypercompetitive marketplace, the value of those benefits can be enormous.

How to solve a jigsaw puzzleWhen it comes to working out the best way to transition to a DevOps approach, Jane Such of Certeco likes to offer the example of how people solve jigsaw puzzles. There are those who start with the edges and then start to fill in the middle. And then there are those who see an object in the picture such as a large red train and they set about finding all the red pieces and assembling the train.

“For me, that’s an analogy of getting these small DevOps teams – like a bottom-up approach – working. You’ve got it working for this particular system, you’ve got it working for that application, but until you put in the actual edges and understand in context where that fits, you can’t then start to join those isolated bits up to the main frame and then fill in the whole picture,” Such says.

The Certeco executive sees the outside edges of the jigsaw as a metaphor for top-down direction. And the direction that matters most in the case of DevOps is changing people’s attitudes and behaviours.

“It takes a long time to make those sorts of changes and it’s very, very difficult,” she says. “You can’t just rely on this bottom-up, getting-that-team-working approach. I think it has to be a pincer movement really. You’ve got to come top-down as well.”

Or, as Bob Appleyard of Sungard Availability Services puts it: “You need your whole organisational culture to change to effectively support a DevOps-type mindset.”

The first step, as Such suggests, comes from gaining management buy-in. Once that light bulb moment occurs, executives can set about starting to embed new practices into an organisation’s DNA. “It’s your CEO and your CTO,” says Such. “They’re the ones who have got to buy into it and I think they have to drive that initiative. I think it means training, mentoring, experiential learning.”

Leading from the top“It is very hard to change culture,” says Helen Beal of Ranger4 Ltd, a consultancy that specialises in DevOps. “What you actually do is change behaviours.”

For instance, teams can be reorganised to move from a waterfall process to an agile process. Or, behaviours such as test-driven development (TDD) can be learned. There are also behaviours involving managing conflict, avoiding blame and injecting more experimentation, all of which can help a company understand what it looks like to have what Beal describes as a “friction-less culture”.

2

“ You can’t just rely on this bottom-up, getting- that-team-working approach. It has to be a pincer movement. You’ve got to come top-down as well.” Jane Such, Certeco

“ You need your whole organisational culture to change to effectively support a DevOps-type mindset.” Bob Appleyard, SunGard Availability Services

Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

3

While business gurus often stress the importance of companies being bottom-up in order to innovate, when it comes to cultural change, there is no substitute for senior management leading the way.

Says Beal: “One of the things that make people mature about culture is if the senior management view it as an asset. Is it actively talked about? Is it actively understood and worked on, and articulated and communicated through the organisation?”

Steve Marshall, who is a change delivery manager at Nomura International, also sees the right mindset as something that needs to be built. “It is about building teams, building cultures, building practices. Changing the way people work,” he says.

For senior management to do any of that, they first need to appreciate what DevOps really entails. Marshall identifies four planks that he says should be part of any successful system.

The first he calls client vision. Whether leading or supporting projects, staff need a well-articulated vision of what the client wants and requires. The second is collaborative design. Tools, teams and working methods are needed to promote collaboration. Third, development controls need to be put in place. DevOps does not mean moving to a system where essential processes such as documentation go by the wayside. And fourth, there is the adoption of continuous testing and implementation.

In fact, Marshall is so focused on getting those four aspects right, he doesn’t even worry about using the term DevOps. “I’ve transformed some of the biggest programmes in the bank using this, without ever telling them that they’re doing DevOps,” he says.

He adds: “What’s relevant is telling people that if they want to get a programme off the ground they need to build the client vision. They need to build the design. In order to do that, you need people to get together, and you build a programme that creates this structure.”

Still, all of that may be easier said than done, and that is why top-down messaging and decision-making become so vital. As Certeco’s Such notes, there often may be huge resistance because people just want to do things the way they’ve always done them. She puts this down to human nature and people’s general desire to stay safely in their comfort zones.

“It’s not enough for directors and CEOs to give permission to these teams to adopt DevOps and see how it goes, because I think then it stagnates,” she says. “If you really want to keep the momentum and you want to start doing what these bigger, more successful companies are doing, where they’re starting to tackle legacy, it’s because they get much more drive and direction from top down.”

The value of inclusivityFor Marshall of Nomura, the notion that DevOps is limited to just the Dev and Ops part of a firm is a big mistake. This is because including the business is critical to the four planks he sees as part of a smoothly functioning DevOps system. Without participation from the business, there is no way to understand and articulate the client vision, and without that, the changes may not produce the results desired.

“Just having some operations people and some development people sitting together, that’s fine. But why wouldn’t you have some business people sitting there?” he asks. Marshall understands that the focus on Dev and Ops on one level makes sense, because a target operating model is a key part of the client vision. But a DevOps approach includes many other issues. For instance,

“ It is very hard to change culture. What you actually do is change behaviours.” Helen Beal, Ranger4

Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

by the time a company starts to adopt continuous integration and is building software packages, it needs to understand that it is also building business flows and release principles for moving into production.

Such, meanwhile, sees a range of people who make the difference between a DevOps system that works well and one that does not. “You’ve got to include those people who are on the periphery because they’re just as important for the success of business change, whether they’re analysts or designers or testers or project managers or even wider than that, support personnel,” she says. “Somebody may be running the change management system and they don’t develop anything or are not even part of the integral development team. But they’re still key to improving processes and automating processes.”

Inclusivity, in fact, is about more than ensuring that all the right people are involved. It also has a psychological dimension that makes the change process more likely to be embraced. As Such notes, people need to be included in something before they will even consider if it applies to them or not. Otherwise, they simply become resistant. That is why she stresses the people who might be thought of as being on the periphery. It is also another argument for the top down approach because those peripheral people will not be brought into the process without leadership.

This issue may come up in particular as companies dip their toe in the water with a small, targeted DevOps project before deciding to roll out a wider change programme. “If you are not on one of those teams, you’re an outsider. Psychologically speaking, you’re then going to become more resistant because you’re going to feel excluded from the new stuff,” says Such. With proper leadership, those who are not part of the initial team can still feel engaged and will be waiting to embrace the change when it’s their turn.

The switch to DevOps also can end up changing the nature of people’s roles. There will still be specialisms; but in a DevOps environment, when talking about testing, the idea is that everybody becomes responsible for the quality of what is being produced, not just the tester. The tester, in that scenario, may take the lead role and constantly remind others that they too are responsible.

The journey is long but rewardingAs with all new methods that gain buzzword status, expectations of how immediately transformative DevOps will be for a company run the risk of running ahead of reality. Those who understand and have experience with DevOps systems say the adoption needs to be seen as part of a long-term transition.

“We prefer to use the term evolution to transformation, because it really is incremental change,” says Beal.

Her firm’s process, when working with companies looking to embrace DevOps, is to think about where firms are versus where they would need to be from three perspectives. The consultancy looks through an organisation lens, an interactions lens and an automation lens, in seeking to understand how far along a firm is and how much further there is to go. All of that becomes part of what it calls a DevOps Maturity Index.

“Everyone’s path is slightly different, but there are definitely common problems that we see,” Beal says. “Testing, generally, is a very immature area for almost everyone that we analyse. Testing automation is a big piece that most people have to do that they haven’t yet got nailed.”

4

“ Just having some operations people and some development people sitting together, that’s fine. But why wouldn’t you have some business people sitting there?” Stephen Marshall, Nomura

Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

Marshall of Nomura also stressed both automation and the long-term nature of such change. He, like many other change agents, is a big fan of automation but he says the key is to do it gradually. “There’s automation in all parts, all the way through this. But you’ve got to gradually automate everything you do, from step one to step one hundred.”

Royal Mail Group is one company that is experiencing the evolutionary nature of a DevOps transition.

“If we use that term ‘journey’, Royal Mail are fairly early on,” says Martin Moore, who is responsible for introducing DevOps and agile working methods to one of the group’s six main platforms. “However, we have had examples of DevOps working in our digital labs area and to an extent, our e-business area.”

He notes that his team is building the enterprise DevOps tool chain that ultimately could be used across the group. The company is doing it all internally rather using suppliers because it wants more ownership of the tooling and an understanding how its systems work and how they are designed, implemented and deployed.

“Our guys are learning the tools, they’re piecing them together,” Moore says. “We’re trying to get our continuous integration and testing and deployment up and running, which we’re doing right now. So it’s very early days.”

Already, Moore says there has been a 30% speed-up in terms of time to market and an equal increase in efficiency in the area he manages. But the company is looking to go further. “The natural extension is to ask: Is there software that can actually speed things up even faster, run automated testing, help us to run a build every time code changes, et cetera, to what we’re now looking at? So that should take us from a 30% saving to substantially more than that, we hope.”

Royal Mail Group, like many companies, has recognised that it needs to be able to react faster and deliver faster to improve quality, and it sees the DevOps approach as a sensible means to that end. “We want to break down our large, monolithic programmes that have thousands of requirements and take 18 months to two years to deliver, by which time the business has moved on or the market has moved on.”

He also agrees with Beal about the need to look at changing from that old way of working gradually. “I realise that the whole culture of the business does need to change. But in my view you can also make isolated changes within technology to do that build-test-deploy part of the project much faster and much more efficiently,” he says. “We can accelerate certain areas even if we’re still struggling to get a product owner from the business. We can still do things in a much more efficient way and capitalising on this tooling that we’re putting in place.”

Embracing the conceptListening to Moore’s account, DevOps sounds less like a radical change and more like a series of practical, business-focused steps designed to inject speed. But that does not mean it is anything less than a multi-layered and far-reaching proposition that requires engagement at every level of an organisation.

The challenge for firms is recognising those dynamics and realising the breadth of the DevOps concept. In that sense, Royal Mail Group’s Moore sees the journey his company has embarked on as an extension of one that it actually started in the last century.

5

“ Those of us who are operationally minded, worked out, probably 20 years ago, that the best way to get a trouble-free and bug-free application into production was to get the ops team involved in the beginning of the development lifestyle.” Martin Moore, Royal Mail Group

Fina

ncia

l Mar

kets

INS

IGH

TS

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

“Those of us who are operationally minded, worked out, probably 20 years ago, that the best way to get a trouble-free and bug-free application into production was to get the ops team involved in the beginning of the development lifestyle,” he says.

For Such of Certeco, DevOps ultimately is more a human than technological issue. “For me, I think the biggest challenge is people, and people, and people.”

6

For more information on the companies mentioned in this article, visit: www.certeco.co.uk www.ranger4.com www.sungardas.comwww. nomura.com www.royalmailgroup.com

Seven dos and don’ts for firms on the DevOps journeyHere are some of the practical suggestions experts give for companies looking to reap the benefits of a DevOps approach:

1 Start smallJane Such of Certeco says: “I think the way a lot of organisations have got started is to pick a team or an area that is the easiest to adapt to a more DevOps way of working. You start small. You start with a focus group. You’ve got a team who are all geared up to do that. I think that is a really good way to start and I think we’ve seen that across a lot of companies.”

2 Don’t adopt the “stealth approach”“What I find is a lot of people are doing it by stealth,” says Such. “They’ve got a small team working on it. No one else in the company really knows what they’re doing other than they’re doing something, but it doesn’t include them.”

3 Think about the areas where DevOps makes most sense“If you’re looking at something that’s got a GUI – you might have it on your phone, or it might be on a webpage – DevOps could lend itself quite nicely to that,” says Bob Appleyard of Sungard Availability Services. “It’s all about functionality that’s been brought out to keep ahead in the market. It’s understanding where the demarcation lines are, and where the benefits that you’ll get from not throwing out the baby with the bathwater.”

4 Make the business central to the processSteve Marshall of Nomura International stresses the importance of the business playing a role: “When you’re building requirements, or you’re trying to get a vision, who gets the vision? Well, developers, operations, and the business. The people who are trying to work out what they’re trying to do and deliver.”

5 Focus on testing early onMartin Moore of Royal Mail Group says: “Testing should be as early as you possibly can to really, really make sure you understand your requirements. It’s about having the constant feedback loops so that you can correct sooner rather than later to keep yourself on course, so you’re less off course by the time you get to the end.”

6 Retain a focus on development controls.“I worry, slightly, that people will use it as an excuse to rapidly develop things, move it into production, without necessarily going through all the right levels of documentation,” says Appleyard of Sungard Availability Services. He says he’s heard people say the approach means “the end of process”. “My argument is, ‘Well if that’s the case, you’ve got your process wrong.’”

7 Adopt a learning cultureSays Helen Beal of Ranger4: “In DevOps, we have this cultural principle that we embrace failure, because we embrace failure as a learning opportunity. We treat it as part and parcel of what we do when we innovate.”

Cop

yrig

ht ©

201

7 T

heR

ea

liza

tio

nG

roup

A

ll rig

hts

rese

rved

www.TheRealizationGroup.com7

The Realization Group is a full service marketing and business development services company specialising in the capital markets. Our team contains industry practitioners from both the trading and post trade disciplines and we have expertise equally in the on-exchange and OTC trading environments. We apply our comprehensive set of marketing programs and wide-ranging media and business networks to complement the business development requirements of our client organisations.

Financial Markets Insights from The Realization Group, is a series of interviews with thought leaders in financial and capital markets. The purpose of the series is to provide exclusive insights into industry developments, through in-depth conversations with C-level executives and key experts from banks, exchanges, vendors and other firms within the financial markets ecosystem. For more information, please visit www.financialmarketsinsights.com

Other topics in the series: Naturally Intelligent - Embedding operational AI in financial services download Powering up - Handling high-performance computing to boost alpha and risk management download The future of trade surveillance - Separating the Spoof from the Truth download Go with the flow - Are financial firms ready for the data capture challenge? download Future proofing for FinTech with Network Innovation download Keeping a watchful eye - Best practices for maintaining trade surveillance download Digital transformation - Challenge & Opportunity download AI & Machine learning - Building the future of finance download MiFID II creates cross-asset revolution across buy & sell side download