By KUY.io • 15 minutes read
Table of Contents
Digital technology has brought about significant transformations across every industry sector. The Wall Street Journal even claims that every company now is a technology company. So it's no wonder that organizations everywhere are starting digital transformation programs aimed at improving internal systems, increasing employee and client satisfaction, and delivering higher quality products and services to clients, at higher efficiencies - ideally all with lower risk. However, no organization can afford to see a "digital first" program as a one-off fix, or even as a series of annual iterations.
As customers (empowered by ever-more sophisticated devices and better applications) demand more features at higher quality, and at a faster pace, businesses need new and innovative ways to serve them. In addition to maintaining existing projects and products, development teams must continue to innovate every day of week by week, and every month. This creates a real challenge for organizations that are accustomed to working in a more traditional waterfall process with gates, controls and approvals. Incidentally, these organizations are also rolling out products and updates much more slowly.
The Agile DevOps Model
Over the past decade, Agile software processes such as Scrum and Kanban have been hailed as the new standard for developing digital products. However, to bring about the organizational changes describe above, we need to extend agility beyond just the dev teams, to reach all functions in the organization that directly or indirectly touch the creation and delivery of those digital products. This is where DevOps has become the new de-facto standard for organizing digital product teams.
The Agile DevOps process model
Agile DevOps extends the Agile Scrum methodology to encompass all areas of the Software Delivery Lifecycle (SDLC) beyond development, including quality assurance efforts, deployment, operations and maintenance. The key idea behind the Agile DevOps process is to expand the Continuous Integration phase of traditional Agile processes into Continuous Testing, Continuous Delivery, Continuous Deployment and Continuous Monitoring. The key guiding principle for Agile DevOps is to provide continuous feedback loops across development, build, test and operations phases of the SDLC.
By harnessing the concept of agility to a methodology that enables constant software innovation and delivery, the Agile DevOps process allows organizations to respond dynamically to changing conditions and rising client expectations, all while finding internal efficiencies and decreasing risk, both on software quality, as well as operations and delivery.
The basic fundamental of Agile DevOps is to implement the automation in all the stages of delivery, right from the code verification to deployment, which includes code integration, builds, testing, deploying, verifying the deployed builds. This automation accelerates all the stages of software delivery so that developers get feedback and impact of their changes fast which help to speed up an overall time to market. Within this framework, Agile DevOps defines the following distinct phases of automation within the process cycle:
Continuous Integration (CI) addresses the developer group in the DevOps lifecycle. Here the key focus is to have a seamless error-free builds with best techniques & standards of version controls that are adopted and then picked up for the deployment in the specified environments. The challenge is selecting the right tool set that works for your needs. Hudson, Jenkins, Bamboo, are some of the tools used for continuous integration.
Continuous Testing (CT) is another important part of development lifecycle that certifies the quality of the product that is delivered to the end customer. DevOps emphasis on automating all the types and phases of testing. The goal of continuous testing is to provide fast and continuous feedback about the level of business risk in the latest build which is used to determine if the software is ready to progress through the delivery pipeline at any given time. Tools like Maven, Selenium, or Cucumber are widely used tools for testing.
Continuous Deployment (CD) is the core of DevOps. Continuous deployment follows continuous delivery and deploys automatically all changes that passed the automated tests to production. Some of the popular tools for deployment are Capistrano, Electric Flow, Octopus Deploy, Continuum. Applications are typically multi-tier in their architecture, which means that each application has dependencies which need to be managed properly. Hence, containers are created for fast and reliable deployment of application components on any underlying infrastructure. Orchestration will take care of the timing of container creation by order of dependency, as well as all of the necessary configurations to allow the containers to communicate and pass the required runtime properties to one another.
Continuous Monitoring (CM) of the entire DevOps lifecycle will ensure development and operations teams collaborate to optimize the user experience every step of the way. Monitoring enables to collect and analyze data is testing environments. Tools like Librato, Nagios, Zabbix, Sensu, Logstash generates the data for the team which shows whether the performance is improved or became worse and helps to take corrective measures for improving the performance.
The fully integrated continuous feedback loops across the different areas of responsibility within the SDLC are made possible with a cultural shift within an organization away from siloed centres of excellence, towards tightly coupled, vertically integrated teams that consist of stakeholders from all areas of the SDLC: development, QA and operations. This organization paradigm shift is captured in the term “DevOps Culture”.
So what exactly is DevSecOps?
A typical DevOps program will involve developers and operational staff working together to deliver software and processes that genuinely create value. Over the past years however, we have seen the increasing importance that cybersecurity plays within an organization and at a tie where hacks and data breaches can lead to significant financial and brand damage to a businesses. DevSecOps is a natural extension to this model to also include security staff throughout the software lifecycle. Agility is a key aspect of the DevSecOps model. By adopting DevSecOps, organizations are buying into a digital transformation method that allows them to collectively think on their feet and change course rapidly if necessary, all the while without compromising security.
The purpose and intent of DevSecOps is to drive a cultural mindset that "everyone is responsible for security" with the goal of safely distributing security decisions at speed and scale to those who hold the highest level of context without sacrificing the safety required.
With a cultural shift towards DevOps, Agile and Cloud Services, traditional security processes have become a major roadblock.
Traditional security operates from the position that once a system has been designed and implemented, its security defects can then be determined by security staff and corrected by business operators before the system is released. This allows for a limited supply of skills in security to be applied to outcomes and avoids the need to increase security context within the larger system. However, a process designed this way only works where the pace of business activities is waterfall and is agreed by all parties. Unfortunately, the belief that security must operate this way is flawed with the introduction of iteration and has since created inherent risks within the system because decisions need to be balanced inline and addressed at the speed of the Agile cadence.
It's hardly ever the case that a Security Team has all the information it needs to render a security decision that makes sense at the end of the software development life cycle. And as the SDLC process speeds up due to Agile DevOps, it is even more the case that a one-time tale end determination and testing of a complete system with respect to security concerns is actually destructive to the outcome.
Thus, traditional security is no longer an option: it is far too late in the cycle and too slow to be cooperative in the design and release of a system built by iteration. For this reason we see the extension of the Agile DevOps model to DevSecOps. In this model, it's not necessary for risk reduction to be abandoned by either the operations or security staff; instead, it should be embraced and made better by everyone within the organization and supported by those with the skills to contribute security value into the system. Without deliberate built-in security controls, systemic failures are certain because the mere avoidance of security puts more risk into the system.
Within the model of DevSecOps operations engineers are supplied with tools and processes that help with security decision making along with security staff that enable use and tuning for these tools. For instance, as part of the CI/CD model we can automatically apply code audit and security audit tools. In this way, the value that DevSecOps engineers supply to the system is an ability to continuously monitor, attack and determine defects before non-cooperative attackers might discover them. And because of these changes DevSecOps engineers are hugely useful as mitigating factors to external attackers. This allows for all, including security staff, within the SDLC to contribute to iterative value creation without the additional pain of attempting to acquire severely scarce security practitioners to be added to DevOps teams.
DevSecOps is not something you buy. Rather, DevSecOps represents a change in Information Technology (IT) culture, focusing on rapid IT service delivery through the adoption of lean practices in the context of a system-oriented approach. DevSecOps emphasizes people (and culture), and seeks to improve collaboration between development, operations and security teams.
Opportunities
The adoption of both Agile methodology and DevSecOps produces a variety of competitive advantages for organizations.
Industry studies by CA Technologies and BCG found that adopting Agile methodology on its own already generates significant business advantages, such as 2x-4x faster time to market of software products, 3x-4x higher client satisfaction and ROI, as well as significantly increase employee satisfaction, attraction of talent and retention. The adoption of DevSecOps can further boost these positive outcomes in a compounding effect with respect to efficiency (15%-25% overall IT cost reduction), agility (up to 90% reduction in provision and deployment time), and quality (up to 50%-70% reduction in failure rates).
DevSecOps increases efficiency. With its emphasis on collaboration, communication, automation and smaller, more frequent releases, DevSecOps can spark significant efficiency gains. Developers spend more time developing and less time waiting for machines to be configured or integrating code. At the same time, automation means fewer manual processes, red tape and gates within IT operations—which in turn results in lower costs and lower error rates.
DevSecOps increases agility. DevSecOps eliminates much of the manual orchestration required to implement new features and changes. By automating as much as possible—in testing, integration, and in some instances even deployment—DevSecOps enables companies to work with much smaller sections of code, even just a few lines at a time. This results in quicker feedback and integration as well as streamlined handling of errors—and delivers essential features and changes faster. Under the DevSecOps approach, deployments can occur 100 to 200 times more frequently.
DevSecOps replaces siloed thinking with shared responsibility. By tearing down the walls between ops and development, the cooperation fosters shared responsibility. This eliminates the expectation that “ops will fix” any software problems created when new features or functionality are added. Instead a culture of quality emerges as the cross-functional teams share responsibility for the successful implementation of their jointly developed solutions. It also accelerates the time to market, since coordination across functions is clarified and streamlined.
DevSecOps improves quality. In the Agile model, developers hand over completed development projects to the IT operations function, which then monitors and maintains those projects.. By engaging both sides throughout the entire development process, DevSecOps enables faster and easier fixes, and motivates developers to prevent future problems, therefore, embracing a mantra of “you build it, you fix it."
DevSecOps reduces unplanned work. As DevSecOps brings more automation and standardization to the development process, human errors can be reduced and best practices more easily shared across teams. The results are one-half to one-third fewer failures, about 20% less time spent on unplanned work, and one-half to one-third less time spent on remediating security issues.
Challenges
Industry studies suggest that through 2023, 90% of DevSecOps initiatives will fail to fully meet expectations due to the limitations of leadership approaches, not technical reasons . The value in adopting DevSecOps practices is vast, but if initiatives are to be successful, organizations must approach them in the right way. In a recent survey, Gartner distilled the top 5 reasons for unsuccessful adoption of DevSecOps in organization:
1. DevSecOps not grounded in customer value.
Organizations often launch DevSecOps efforts with insufficient consideration of business outcomes. Digital Transformation leaders need to ensure their staff and customers connect with the term “DevSecOps,” and the value it will bring, prior to introducing the initiative.
Mitigation Strategy: Use marketing to identify, anticipate and deliver the value of DevSecOps in a manner that makes business sense. Leaders must seek to refine their understanding of customer value on an ongoing business to evolve capabilities and further enable organizational change.
2. Organizational change not managed.
In the Gartner 2017 Enterprise DevSecOps Survey, 88% of respondents said team culture was among the top three people-related attributes with the greatest impact on their organization’s ability to scale DevSecOps. However, organizations overlook the importance of getting their staff on board with the upcoming change and instead focus efforts on DevSecOps tools. However, the tools are not the solution to a cultural problem.
Mitigation Strategy: “Tools are not the solution to a cultural problem,” says Spafford. Identify candidates with the right attitude for adopting DevSecOps practices. Individuals who demonstrate the core values of teamwork, accountability and lifelong learning will be strong DevSecOps players.
3. Lack of collaboration.
Successful DevSecOps efforts require collaboration with all stakeholders. More often than not, DevSecOps efforts are instead limited to innovation programs. Organizations cannot improve their time to value through uncoordinated groups or those focusing on innovation programs exclusively.
Mitigation Strategy: Break down barriers and forge a team-like atmosphere. Varying teams must work together, rather than in uncoordinated silos, to optimize work. This might start with seeking out an executive who can carry the teams and champion the effort.
4. Trying to do too much too quickly.
It is important to realize that a big bang approach — in other words, launching DevSecOps in a single step — comes with a huge risk of failure. DevSecOps involves too many variables for this method to be successful in a large IT organization.
Mitigation Strategy: Use an incremental, iterative approach to implement DevSecOps to enable the organization to focus on continual improvements and ensure all groups are collaborating. Spafford recommends starting with a politically friendly group to socialize the value of DevSecOps and reinforce the credibility of the initiative.
5. Unrealistic expectations of DevSecOps.
Similar to struggling with grounding DevSecOps initiatives in customer value, a disconnect exists in many organizations between expectations for DevSecOps and what it can actually deliver. Expectation management and marketing are continuous and not a one-time affair
Mitigation Strategy: Manage expectations by agreeing on objectives and metrics. Use marketing to identify, anticipate and satisfy customer value in an ongoing manner. Expectation management and marketing are continuous and not a one-time affair.
Considerations
To foster successful adoption of Agile DevSecOps processes, organizations may start by following the 8 Foundational Steps in Digital Transformation and Adoption of DevSecOps outlined in the following.
1. Clearly describe the business justification.
A DevSecOps initiative must focus on business requirements and not on “doing DevSecOps for the sake of DevSecOps,” wherein the methods and tools become more important than what customers need. Organizations must avoid the all-too-common mistake of launching a DevSecOps initiative before establishing that a business reason exists to do so.
For example, instead of focusing on release rates and doing things faster, start with the business value by asking what that will enable. The justification could be something like ‘by increasing our release rate, we will be able to innovate faster and thus support sales and marketing’s push for ordering with a mobile app.’ The most successful organizations know the business benefits they hope to realize from DevSecOps.
2. Define what DevSecOps means for your organization
Define the target state in terms that your organization will understand. Picking a label for your initiative to provide a “banner” for people to identify with and support will help to get them on board. The definition should be short, focused and supportive of the business justification.
3. Select the first application to move
Do not deploy DevSecOps in a single step. DevSecOps must be deployed iteratively, with each increment satisfying all three of the following qualities:
a. Politically friendly environment: This means that people are willing to work with the first-mover application and give the initiative a fair and honest try.
b. Acceptable value: The first mover must deliver enough value to earn credibility and approval to continue.
c. Acceptable risk: Because of the ambiguity and uncertainty surrounding DevSecOps, many people view it as risky and are afraid to begin. Organizations should identify an opportunity that involves an acceptable level of risk, because everyone — IT, operations, development, information security, regulatory compliance and audit — must learn.
The core use case of DevSecOps is in Agile development and situations with considerable uncertainty such as machine learning and Big Data, but because the DevSecOps philosophy can be applied broadly, there will be other opportunities to introduce concepts. The initial impact, however, will usually be better with systems of innovation because the existing capabilities likely can’t support these initiatives.
4. Identify initial team
People are the main ingredient in a successful DevSecOps initiative. When selecting members of the initial team, emphasize behavior over skills. Teaching technical skills is easier than teaching the correct behaviors — and the wrong behaviors will derail the DevSecOps effort. Look for a good team player who is smart, motivated, understands risk and is a committed lifelong learner, capable of working in new ways.
5. Establish objectives and metrics
Because people are the most important part of a DevSecOps initiative, understanding and implementing the right motivators is critical. In many traditional organizations, objectives are set departmentally and IT metrics are in place to solve problems and reward the person who solves them.
In a DevSecOps initiative, objectives must be at the team level and aligned to the business objective given to the team. DevSecOps team members must realize that they all have the same objective, and metrics and incentives must encourage teamwork toward business goals as opposed to metrics that reinforce risk aversion and individual problem solving.
6. Focus on constraints
Identify the largest bottleneck that is limiting throughput. The life cycle of developing and transitioning new and changed systems into production will have a greatest constraint that limits throughput. By focusing on this greatest constraint, the DevSecOps team can methodically identify what is holding them back from the required cadence and address it.
7. Develop the automation toolchain
The overall goal of a true DevSecOps implementation includes an integrated toolchain that enables an approach to evaluating and selecting tools so that each tool can be loosely coupled to its adjacent tool in the application life cycle. Linking all of the automation touchpoints and information flows speeds the movement of releases through the toolchain while reducing errors, defects, rework and outages. This will allow the tools used at each stage to be aligned and will provide a view on where automation, integration and tool hand-offs need to be achieved within and between stages.
8. Scale only when ready
Too many organizations make the mistake of believing they need to scale DevSecOps before they start in order to get approval. This leads to a vicious cycle. Because they don’t know how they will scale DevSecOps, they can’t start. And because they can’t start, they can’t learn and figure out how to scale.
Instead of derailing a valid DevSecOps initiative by trying to scale before it is ready, bring together your team, start moving in the direction that seems to make the most sense and address the constraints encountered. Learning and evolution must happen in terms of the people, the technologies and the processes. Incurring technical debt is inevitable, and managing that debt is a part of the new model as evolution occurs. When adopting DevSecOps across the organisation there are many different ways to set a path. You can take one application and go all the way to Continuous Delivery or you can take all your applications and just improve one area like Configuration Management. Clearly there is not just one correct way – the silver bullet people are looking for.
9. Not every application is a right candidate for DevSecOps.
Traditional applications are not architected for DevSecOps velocity (speed at which DevSecOps can delivery a software change to production), whereas enterprise applications designed with Agile and iterative techniques are excellent candidates for DevSecOps. DevSecOps may be an overkill for applications where the underlying business process rarely changes. Dev and IT Ops should choose one or two applications for DevSecOps style implementation.
Provision applications as part of the build process itself. During deployment, Ops should be able to execute a piece of code to identify application monitoring needs. Your automation framework should manage application health without manual intervention. - Can you fix application issues using runbooks? - Do you have scripts for scaling, maintaining, and load balancing the application? - How do you plan for new releases? - How do you upgrade the application?
10. Treat infrastructure as code.
Application configuration, deployment, and maintenance all need to be part of an automation framework. Ops should build concurrency with the application. You should be able to configure, deploy, and bring the entire application live within no time.
How Can we Help?
Interested in transitioning your own teams to an Agile DevOps or DevSecOps process model?
We're happy to talk if you are interested in learning more about KUY.io or looking for expert advise on how to make your next transformation story a success!