The focus on DevOps is to create a streamlined flow from development to operations, who in turn provide continuous feedback loops to resolve problems quickly.
During the late 19th and early 20th centuries, Frederick Taylor proffered a scientific approach to improve efficiency within the workplace by breaking down workloads into specific tasks. Workers would only have to concentrate on one specific activity which, when finished, allowed the next person to complete another specific task. This approach was called Taylorism and for over a century, it has been a prominent feature within manufacturing. In this model, knowledge is "siloed" because each individual is responsible for performing one task. It also requires one person, the manager, to oversee all activities and manage which tasks go to which individual.
As we moved into the digital age, the task-oriented processes of Taylorism were adopted to produce software solutions involving dedicated teams to work on specific components of the software delivery lifecycle. Business Analysts gather requirements, architects translate those requirements into design specifications, developers produce the product according to these specifications, testers validate and verify the product against the specifications, a delivery team deploys the software and finally, an operations team continues to support the product. This flow of artefacts cascading from one team to the next is described as a waterfall methodology.
The problem with the waterfall approach is that it’s not very flexible; during the whole lifecycle, the requirements may change, the market may change, or the users’ expectations change. When changes to the solution are requested, the whole process is restarted and follows through until the end of the cycle. This is an expensive and inefficient way of working.
During the 1990s attempts to resolve this problem led to the creation of the Agile Manifesto for Software Development in 2001.
The manifesto documents four values:
These four values address the main issues associated with waterfall as they give software engineers a flexible framework to deliver products that their customers want. However, often there are internal bottlenecks when Agile teams interface with other teams reminiscent of the waterfall process.
For example, although the design, development and testing phases are managed within Agile software teams, engineers are often required to hand their solution over to specialist teams for further testing, deployment and maintenance. Agile is designed to give customers what they want, but bottlenecks prevent them from receiving a solution necessarily at the time they need it.
Delays in pushing a product to market provide opportunities for your competitors - ultimately affecting your profits. Overcoming these challenges necessitated a different approach to remove the bottlenecks. Therefore, Agile development teams needed to adopt deployment and operations activities as well. This new approach has become known as DevOps, a word derived from Development plus Operations, although it is more complicated that just creating a team of development engineers and operations engineers. A team of DevOps engineers consists all of the resources required to deliver and manage a service, such as application developers, testers, operations, engineers and product owners.
The focus on DevOps is to create a streamlined flow from development to operations, who in turn provide continuous feedback loops to resolve problems quickly. This eliminates the bottleneck associated with waterfall and pure Agile frameworks. Throughout this flow and feedback mechanism, there is an ongoing process of learning and experimentation with the specific goal to continually improve a product or service.
The adoption of DevOps is a cultural change that involves reorganising teams and moving from the traditional project delivery process to a product delivery process. Within a DevOps culture, teams are small, normally between 5 and 9 people. Each team interfaces with other teams using the least amount of friction, thus removing dependencies between them. In other words, one team consumes the services of another without having to go through a lengthy engagement process. Effectively, each team becomes an internal supplier to, and customer of other teams within the organisation.
The term DevSecOps is used to describe ways of securing DevOps. However, it is important to stress that DevSecOps does not describe a team into which a security engineer is transplanted; it is not a role within a team and it’s not a process to follow. DevSecOps is a framework that requires a new approach from the way security interacts with engineering teams. Ultimately, security’s role in DevOps is based on providing solutions with which other teams within the organisation can interface. These interfaces are either collaborative, which describes a short-term programme to overcome a specific problem, or a service-oriented interface, which involves providing self-service solutions to the delivery teams.
Security teams working in a DevOps framework should at a minimum offer three ways of interfacing with the engineering delivery teams. First of all, they need to provide an education programme involving myriad measures to increase awareness of and solutions to security weaknesses. These include offering training platforms, poster campaigns, awareness programmes, and demonstrations of common exploits. Secondly, they need to actively support DevOps engineers develop safe and secure solutions. They can do this through collaborating with a team to address specific types of insecure coding practices. Finally, they need to offer self-service solutions that allow engineers to test their solutions to identify vulnerabilities within their application code and infrastructure code.
Traditionally, security teams have acted as guardians who determine which products are safe enough to go live and those that are not. In DevSecOps, security teams are enablers who provide solutions for delivery teams to produce secure software without compromising flow, feedback and continuous improvement. Their energy needs to be directed towards developing and maintaining tools and APIs that are consumed by engineering teams to develop secure applications and infrastructure. They should use their expertise to build and support platforms that improve the maturity of security knowledge and skills across the organisation. Ultimately, security teams must provide ways for engineering teams to consume security tools to continuously test and monitor their products for weaknesses and exploits, as well as provide support for addressing issues during the delivery lifecycle.
Hopefully, this article has given you some insight into DevOps and DevSecOps - and how your business can benefit from adopting the framework within your organisation.
The role of DevSecOps in digital transformation programmes is essential for building secure, customer-focused products and services for the digital age.
If you work in a Learning & Development / Talent Acquisition / HR role and would like to book a free 1-hour interactive workshop with one of our experienced instructors, take a look at our Demystify Tech lunchbreak sessions and get in touch.
