DevOps theory is great, but DevOps good practice is a bigger challenge

DevOps: spend more than five minutes looking at any IT-related website or magazine and it would be easy to assume that it is the saviour of modern-day software development. Based on the concept of breaking down the traditional barriers between software development and operations teams, it promises a more collaborative and transparent working environment. The potential benefits are attractive: faster time-to-market, delivery of what customers and the market want, in a continuous, responsive and agile way. Those are goals to which pretty much any financial firm can relate. No wonder there are various studies reporting that most enterprises, both inside and outside the finance industry, have or are adopting DevOps into their IT strategies. 

However, theory is one thing, reality quite another. DevOps represents a huge learning curve and there is much that can go wrong, yet when it is done well, the rewards are worth the effort. A good starting point is to understand what has – and what hasn’t – worked for other early adopters of DevOps, whether in this market or others. Here is what we’ve witnessed and what we’ve been informed by some of the organisations on DevOps journeys we’ve worked with in recent years.

Adapt the parts of DevOps that work for your organization.

There’s a huge amount of information out there: courses, books, MeetUps….you name it.  But there is no ‘one size fits all’ DevOps recipe. Instead, it is best to learn the essentials and then adopt the parts that make the most sense for your organisation. 

Agile and DevOps together are a powerful combination.

There is growing evidence that when these two complimentary approaches work in tandem, they are bigger than the sum of their parts. While Agile may not always be thought of as a natural fit to a compliance-driven market like financial services, this is less and less the case, particularly when using hybrid Agile project planning, to help build in the predictability and control (even over budget) that more traditional methods like Waterfall offer.

Get buy-in early, educate and communicate.

At management, team and even customer-level, getting people behind DevOps from early on can make a huge difference to ultimate success. Invest not just in training, but advice from external DevOps and Agile consultants, who can get you where you want to go more quickly. Communicate early successes with other teams, share best practice and lessons.

It’s a blend of the right culture, processes and tools.

Choosing the right software systems to support DevOps adoption is essential, but they are not a means to an end in themselves. Engendering an internal DevOps culture is what will make the difference. Tools play supporting - not star - roles. The stars that will make this happen are the people. Moving from entirely separate organisational structures to shared responsibilities and accountability between development and IT operations can be unsettling to many people. However, top performers will embrace the transition because they will already be aware of the potential. Being seen to embrace Agile and DevOps will help attract top talent into the organisation too. However, whether for existing or new recruits, careful planning and communications around changes to – or additional – roles is critical to success. 

But choose tools wisely.

To be a proper fit for a DevOps culture, supporting software tools need to be able to work with multiple applications, systems, platforms, file types and contributors (often non-technical ones too). Make sure tools can scale – particularly important in fast-paced financial services, where code repositories can grow large, quickly – and support distributed and dispersed teams.

Give users guidance, but don’t be prescriptive – sometimes this this is effective and sometimes it creates chaos.

In a regulatory and compliance environment, development and IT professionals are likely very aware of the “guard rails” that should be followed in making tool selection. However, it is vital to be explicit about what they are, and provide a process where tools can be “accepted” by the necessary stakeholders, such as security personnel. Guidance may prescribe that, for instance, they can continue to use their preferred tools so long as they meet the requirements and do not impede automation or further siloes. In reality, they will probably come around to using the preferred choice of tools in the end (at least, this is what the companies we work with are telling us).

Compliance and risk management can sit alongside DevOps.

The greater transparency that DevOps helps to create also supports compliance. Beyond that, techniques and tools such as standards-based static code analysis, automated code review processes and scalable version control systems that promote traceability and auditability, as well as controlling who has access to code and non-code assets in a repository, will all contribute towards achieving compliance and managing risk in a DevOps environment. 

DevOps represents a seismic shift for many organizations, particularly large enterprises where there are many teams involved, and especially with the added pressures that regulatory compliance necessitates. Is it worth all investment of time and additional resources? Yes, the productivity and velocity benefits can transform a business. Choosing the right cultural approach and toolset for the organization, learning from peers, ongoing review of  system efficacy, plus keeping an open mind to innovation and change, are what will contribute to DevOps success.

www.perforce.com