DevSecOps is a term which has gained popularity recently, and there is debate on what it actually is, and whether it has a place in modern software development. A natural evolution from DevOps, a cultural and mindset change to increase agility and promote innovation, DevSecOps aims, perhaps unsurprisingly, to implement security at the speed of DevOps.
DevOps, as its constituent components suggests, involve combining development and operations. These are traditionally different and separate sub-functions within the “IT” function in an organisation, typically with contrasting objectives and KPIs. Whilst development want to produce new code and features, operations are tasked with keeping the IT environment stable. DevOps aims to combine development and operations into a single unit to operate the end-to-end development -> testing -> operations with increased agility. To reduce the risks to the operation environment, code releases are incremental, with rapid feedback, allowing teams to pivot out bad code rapidly and with minimal impact.
Another cultural shift is that, unlike traditional management with centralised command and control, executives can simply articulate their requirements and knowledge workers will be able to autonomously produce solutions. This empowers teams to define their own destinations. This does not have to mean reduced compliance and governance; indeed, these should be complemented with management support and guardrails to encourage the right behaviours. Teams who have transitioned successfully to DevOps / DevSecOps have reported improved engagement and productivity.
Decentralised teams can exacerbate one side effect, the proliferation of multiple toolsets which are all capable of performing the same goals; this is already a common disadvantage within large corporations that work with geographically and culturally diverse footprints. Multiple toolsets performing similar functions are inherently inefficient, both financially and for collaboration, with the organisation potentially being less able to leverage experience due to different technologies and platforms being implemented in different functions and business units.
Top-down enforcement of specific toolsets is unpopular and could alienate one of the organisation’s most valuable asset - the employees. One way to start toolset rationalisation is to work closely with development teams: understand their requirements, and identify opportunities for consolidation. As long as the toolset aligns with the company strategic goals, it makes sense to focus support and investment on the main toolsets as this will bring the biggest benefit to the biggest number of developers, whilst still supporting the entire organisation.
Due to rapid changes in the industry, management can also assist by continuous review of the technical and development environments to ensure toolsets remain suitable. Transformation journeys across geographical boundaries require patience, particularly when the ask may involve significant cultural and mindset change. Technology changes will be more effective if they are supported by education and training, which can include external specialist support.
Implementing DevSecOps across a large enterprise is no simple feat; most of the success stories involve deployments amongst relatively homogeneous, self-organising teams which emphasise agility and speed. Unfortunately, this can pose a problem within the varied environments in multinationals, which can result in a myriad of tools and processes. A degree of rationalisation and standards-setting in this context will help to leverage economies of scale in a large enterprise, whilst maintaining the speed and agility advantages of DevOps and DevSecOps.
