What is it?

All businesses need secure software applications which meet their requirements, can be implemented quickly, can evolve and represent value for money. For the last 50 years or so numerous development methodologies have attempted to meet this challenge: waterfall, prototyping, spiral, rapid application development (RAD), joint application development (JAD), agile and – most recently – DevOps.

DevOps is much more than merging the development and operations teams; it’s a step change improvement on the previous approaches. DevOps is a mix of new cultural philosophies, practices, organizational change, standardization and automation. It aims to release applications at high velocity through a continuous delivery pipeline – a reference to the end-to-end solution, from backlog management to release into production.

There are many DevOps tools, Jenkins, Vagrant, Prometheus, Splunk and Azure DevOps Services to name but a few.  Initially provided on-premise, many of these tools are have now moved to the cloud. Because DevOps covers such a wide span of activities, there is no single tool to cover everything. Rather, it is often implemented using a mix of tools and some activities remain manual. The tools cover:

• collaboration and communication between team members (supporting site, national and global teams);
• planning and resourcing for team members (in and across different DevOps projects);
• requirements gathering (based on an agile approach);
• Integrated Development Environment (IDE) for developers;
• code repositories for version control and code reviews;
• software component libraries (with specific versions to match the target infrastructure);
• build automation;
• testing automation;
• infosec policy configuration and management;
• infrastructure configuration and management;
• release automation (from development to test to production environments);
• application containerization;
• serverless computing (with automatic resource and billing reporting); and
• real-time automated reporting for applications and infrastructure.

Its important to stress that DevOps is much more than just a set of software tools and methodologies, its a mindset and a major cultural shift for staff. The irony is that whilst new systems often require major business change the staff who introduce the change are not necessarily always the most flexible and open to change. When technology staff fear that their jobs may be altered in unexpected ways they may mount subtle and overt resistance to change. This requires considerable management attention.

DevOps is not just about teams from development and operations. Infosec specialists are one additional group who are now arguing that the many security layers are too important to be engineered down-stream when the applications have already been built, when major architectural changes at this stage can incur significant additional cost and cause delay. Rather, infosec requirements must be addressed upfront, leading to the development of the concept of DevSecOps.

Why is it important?

DevOps is important because organizations are forever grappling with the applications backlog from demanding business priorities: the explosive growth of data from personal devices and the internet of things (IOT); increasing infrastructure complexity and shift to the cloud; and – in some areas – acute skill shortages. The argument goes that this failure to manage the applications backlog has been caused by a failure to standardize on infrastructure, create unified processes and teams; invest in automation and skills.  DevOps is being put forward as a big part of the solution.

DevOps is a new way of thinking and working, although it builds on a lot from the past, particularly an agile approach to development. Many organizations now have at least some early-stage experience and interest continues to grow. The “2018 State of DevOps Report” (presented by puppet and splunk) showed a continuing year-on-year increase on respondents working in DevOps, standing at 29 per cent in 2018.

What are the key legal issues

Although the concept of DevOps is relatively new, the legal issues in our experience have a rather familiar ring to them:

• who is paying for the upfront investment – implementing DevOps requires a substantial and sustained upfront investment in people, training, software tools, learning and external consultants. The starting point should be a credible business case.  If the DevOps implementation is being outsourced then the usual procurement issues apply (single or multiple supplier, selection, price, performance, planning, acceptance and change management).  In particular, how will the customer measure the benefits (productivity and quality improvements) and who takes the risk that the upfront investment is never achieved?  Suppliers might argue that DevOps is not an end state but rather a changing journey but nevertheless there should be some measurement of success along the highway.
• Licensing of software tools – there are many aspects to this. It may involve buying the latest integrated tools, linking these tools to a variety of third party tools – all in accordance with the relevant vendor licences.  Additionally, the IDE may come with access to an open source component library to enable higher productivity and fewer errors.  These licences need to be sufficiently broad for the purpose for with the applications will be distributed and used.  If the IDE vendor has already completed this analysis or provides online tools to undertake this task then this should be reflected in its contract with the customer.
• identifying responsibility for failure – DevOps spans end-to-end delivery which requires short and frequent delivery cycles and involves a mix of experts along the way: product owners, architects, business analysts, developers, subject matter experts (SME), quality assurance, infosec, operations, testers. If the applications are unstable or flawed, then which group or supplier, if part of the process is outsourced, takes responsibility for poor performance or failure? Major decisions must be traceable and auditable and ideally captured automatically as part of the DevOps delivery cycles.
• ensuring regulatory compliance – creating or modifying applications may require strict adherence to regulatory and industry specific rules and guidance. This is particularly the case, for example, with medical devices, financial products and online advertising.  This will often be provided, in the first instance, by a specialist business analyst or SME, backed up by a specialist lawyer to support particularly challenging areas or providing legal quality assurance.
• assessing the impact on existing licence and maintenance contracts – faster and more frequent releases will probably have an impact on customers, regardless of whether they are internal or external. For example: do customers have the right to refuse to implement new releases and on what basis; what testing and assurance processes are customers entitled to see evidenced; do the embedded user terms need updating; and how will the latest release be rolled back and recovered in the event of a failure in the production environment?

In short, the above list – although far from exhaustive –  contains serious legal issues to be addressed.  The key takeaway from this article is to stress that the legal team need to be involved in DevOps and that legal advice needs to be proactive, pragmatic and upfront.

• Share this blog

• Twitter
• Facebook
• Linkedin