Adopting DevOps for continuous innovation


The current business environment makes many demands of organizations and their ability to deliver software:

  • Business owners are demanding agility.
  • Developers are churning out capabilities and features on a daily basis.
  • Operations are able to provision environments on demand.
  • Customers want the latest features available and accessible through all the platforms they use.

These are just some of the factors that are driving the DevOps movement. Current applications offer complex processing from hand-held devices, but they must also access enterprise applications, legacy data warehouses, and external, third-party APIs to provide the business features that customers want

As with any new technology or technology-related movement, "DevOps" has become a buzzword. Although companies such as Etsy, Facebook, and Netflix are often cited as examples of DevOps organizations disagree about the best approach to DevOps. For some organizations, DevOps implies "NoOps," in which developers assume responsibility for all operations. Others counter that such an arrangement is not suitable for large enterprises. As the industry defines DevOps, different approaches evolve, based on each company's assessment of their risks, required value, and needs.

This article introduces DevOps, explores the business value that an organization can achieve with DevOps, and presents paths to adopting DevOps.

What is DevOps?

DevOps is an approach for software delivery that is based on the principles of lean and agile development, in which all of the stakeholders – lines of business, development, quality assurance, and operations – collaborate to deliver software that is based on real customer feedback. DevOps principles make it possible to deliver software applications in a more efficient and effective manner and to base changes and enhancements on real customer feedback.

Deming, lean manufacturing, and Kaizen

The principles behind DevOps based on principles made popular by thought leaders in the lean manufacturing movement. As shown in Figure 1, Dr. William E. Deming proposed a Plan, Do, Check and Act (or Adjust) (PDCA) cycle to continuously improve manufacturing quality. The lean manufacturing movement is based on this core approach to be continuously improving the product being manufactured and continuously reducing the waste in the manufacturing process. The Japanese industry adopted these continuous improvement principles decades ago using the Kaizen approach.

Figure 1. Demmings Plan, Do, Change, and Act cycle
Quality improves after each PDCA cycle
Quality improves after each PDCA cycle

In recent years, the software development industry applied agile methodologies, which are based on these lean principles. As shown in Figure 2, the basic idea is to develop a small piece of functioning software in fixed, time-limited iterations known as sprints in the scrum methodology, to get immediate feedback from the customer, and to create iterative builds to implement software requirements. Agile methodologies are based on the four key values covered in the Agile Manifesto:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
Figure 2. DevOps: Small releases to production for rapid feedback
DevOps Deploy-feedback cycle
DevOps Deploy-feedback cycle

DevOps extends this lean and agile approach to the entire software delivery lifecycle and to all of the included stakeholders, including lines of business and operations teams, rather than just development and quality assurance.

The original purpose of the DevOps movement was to remove the barriers between the development and operations teams. The lack of communication and trust between these teams challenged their ability to deploy software. Lack of effective communication made it difficult for development teams and business stakeholders to receive user feedback. Without an effective user feedback mechanism these teams were unable to respond and benefit from the feedback.

The DevOps movement was driven by the need to deliver systems of engagement applications, which require rapid and continuous change and a very focused product-to-market fit. Because these applications are used by the customers themselves and not by employees of the business, they provide an opportunity for the business to deliver innovative capabilities directly to the customer. For example, a bank might make it possible for customers to manage their accounts directly from their mobile phones.

DevOps principles attempt to remove these barriers between development and operations teams. The principles help to build communication and trust, to deliver small sets of capabilities to the production environment and to customers as quickly as possible, to get feedback and act upon it, and to improve the software delivery processes to reduce waste, rework, and overproduction. With DevOps, organizations can focus on innovation, delivering quality, reducing time to value, and lowering costs.

IBM view of DevOps

As DevOps matured, these principles extended across the entire software delivery lifecycle, so that feedback gets sent back to the business owners and line-of-business stakeholders. The PDCA cycle influences the functionality of the software, the release plans, requirements, testing, environments, and the process of delivering the software. As DevOps principles have matured, they are applied to systems of engagement applications and the more traditional systems of records applications. Businesses struggle to keep the balance between innovation and stability in the myriad applications they deliver to their customers in rapidly evolving and competitive markets.

IBM defines DevOps to be "Enterprise capability for continuous software delivery that enables clients to seize market opportunities and reduce time to customer feedback."

Four adoption paths of DevOps

DevOps capabilities span the software delivery life cycle. An organization determines where and how to implement DevOps based on business objectives, goals, challenges, and gaps in the organization's software delivery capabilities.

To help organizations in the adoption of DevOps, IBM proposes four adoption paths:

  • Steer
  • Develop and test
  • Deploy
  • Operate

Steer adoption path

The steer adoption path consists of one practice that focuses on the lines of business and their planning processes: continuous business planning. Businesses need to be able to react quickly to customer feedback. Consequently, many businesses employ lean startup techniques. These techniques involve starting small by identifying the outcomes and resources needed to test the business vision or value and then continuously adapting and adjusting based on customer feedback.

To achieve these goals, organizations measure progress, find out what customers really want, and then shift direction by updating their business plans accordingly. With this approach, organizations can make decisions in a resource-constrained environment.

Develop and test adoption path

The develop and test adoption path involves two practices: collaborative development and continuous testing. As such, it forms the core of development and quality assurance capabilities.

Collaborative development

Software delivery efforts in an enterprise involve large numbers of cross-functional teams that include line-of-business owners, business analysts, enterprise and software architects, developers, quality-assurance practitioners, operations personnel, security specialists, suppliers, and partners. Practitioners from these teams work on multiple platforms and might be spread across multiple locations. Using collaborative development practices, these practitioners work together to provide a common set of practices and a common platform to create and deliver software.

Continuous integration, one aspect of collaborative development, is the practice in which software developers continuously or frequently integrate their work with that of other members of the development team, as shown in Figure 3.

Figure 3. Continuous integration
Component builds contribute to the integration build
Component builds contribute to the integration build

The practice of continuous integration, made popular by the agile movement, is based on the idea that developers regularly integrate their individual work with the work of the rest of the development team and then test the integrated work. For complex systems made up of multiple systems or services, developers also regularly integrate their work with other systems and services. Regular integration of results leads to early discovery and exposure of integration risks. In complex systems, continuous integration exposes known and unknown risks that are technical and schedule-related.

Continuous testing

Continuous testing has several goals:

  • Enable ongoing testing and verification of code
  • Validate that an individual developer's code can be integrated with that of other developers and other components and ensure that it performs as designed
  • Continuously test the application being developed

Continuous testing means that software is tested earlier in the life cycle and is continuously tested across the life cycle. Continuous testing results in reduced costs, shortened testing cycles, and continuous feedback about code quality. Automated testing and service virtualization improve the efficiency of continuous testing. Service virtualization makes it possible to simulate production environments and makes continuous testing feasible. Service virtualization provides simulated instances of the external services and applications that the application under test needs to interact with. These simulations or virtual instances can be made available at any time and cost little to run. With service virtualization continuous testing is not dependent on external services and applications. Service virtualization reduces the cost of testing.

Deploy adoption path

Most of the basic DevOps capabilities were developed in the deploy adoption path. The principle of continuous release and deployment takes the concept of continuous integration to the next step. Adopting continuous release and deployment requires the creation of a delivery pipeline. This pipeline facilitates efficient, automated continuous deployment of software throughout the delivery lifecycle. The goal of continuous release and deployment is to make new features available to customers and users as soon as possible.

The capabilities required to create a delivery pipeline are shown in Figure 4. The core capability that facilitates the delivery pipeline is continuous delivery. Continuous delivery is the capability to regularly deliver the application under development to different environments in the delivery pipeline, such as development, quality assurance, integration test, user acceptance test, and production. Using a repeatable, reliable, and automated approach, software is delivered to these environments for validation and potential release to customers. The delivery might be the entire application, a component that has changed, or only a configuration or content change. Continuous delivery includes more than a simple transfer of files. It requires coordinated deployments of code, content, applications, middleware, environment configurations, and process changes.

Figure 4. Delivery pipeline
Develop, build, package, deploy, test, production
Develop, build, package, deploy, test, production

Most of the tools and processes of the DevOps technology exist to facilitate continuous integration, continuous release, and continuous deployment.

Operate adoption path

The operate adoption path includes two practices that make it possible for businesses to monitor how released applications are performing in production and to receive feedback from customers. This data helps businesses to react in an agile manner and adapt their business plans to meet requirements and feedback.

Continuous monitoring

Continuous monitoring provides data and metrics to operations, quality assurance, development, lines-of-business owners, and other stakeholders about applications at different stages of the delivery cycle. The metrics are not limited to production. Stakeholders can react to the metrics by enhancing or changing the features being delivered and by changing the business plans required to deliver them.

Continuous customer feedback and optimization

The two most important types of information for a software delivery team to receive are data about how customers use the application and feedback from those customers about using the application. New technologies make it possible for businesses to capture customer behavior, identify customer issues, and gauge customer sentiment as they use the application. Based on this feedback, stakeholders can take appropriate actions to improve the applications and enhance the customer experience. Lines of business owners can adjust their business plans, development can adjust the capabilities it delivers, and operations can optimize the environment in which the application is deployed. This continuous feedback loop is an essential component of DevOps. The feedback helps businesses to be more agile and responsive to customer needs.


DevOps provides organizations with a set of practices based on lean and agile methods. With these methods, organizations reduce the risk developing software that does not meet requirements, and increases the effectiveness and efficiency of software development and deployment. Organizations can deliver innovations to their customers in a timely manner and rapidly apply customer feedback to enhance the innovations being delivered. Most organizations rely on their capability to deliver software to address their customers' needs, balancing stability of the business capabilities that customers need with the innovations that the market demands. DevOps provides organizations with the capabilities to achieve this balance.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

ArticleTitle=Adopting DevOps for continuous innovation