DevOps: What, Why, When, Who and How

The purpose of this white paper is to briefly discuss the basics about DevOps: “What” is DevOps, “Why” and “When” to consider DevOps. “Who” is involved in DevOps and “How” to start a DevOps strategy and culture adoption. By the end of this paper the idea of DevOps should be simplified in the synergy that is needed to start to plan, execute and manage DevOps; harvesting the soft and hard benefits it brings to an organization as it enables business agility. For the sake of the LinkedIn audience I have broken down this paper into 5 parts. Part 1 (What); Part 2 (Why); Part 3 (When); Part 4 (Who); Part 5 (How).

 Part 1: What’s DevOps

 What’s DevOps after all?

“DevOps is not a method nor a tool; but a cultural mind-set that focuses on bringing collaboration, processes maturity and automation to system development and system operations; with a shared common denominator of quality assurance and agility. It aspires to achieve optimized levels of continuous delivery via continuous deployment, integration, test, monitoring, alerting in the SDLC and operational Eco Systems. It enables full traceability from requirements to running assets and provides real time dashboards and analytic capabilities for the entire ITIL life-cycle for a service or an application.  DevOps brings stakeholders together in a collaborative engagement model that fosters shared ownership and responsibilities based on expertise; thus creating an environment where the synergy among the different stakeholders becomes exponentially and positively greater. It defines a new quadrant for Development, Operations, and Collaboration with Quality Assurance. It depends on and leverages existing disciplines and capabilities such as ALM (Application Life-cycle Management), Automation, Monitoring and Virtualization to achieve business agility with quality. "

There are many definitions for DevOps; this one above is my own. They key message is that all definitions point to automation, collaboration, monitoring, alerting, reporting and continuous delivery; business and IT agility via a cultural change. They point to DevOps as a way for the business to rely on IT to be more agile, successful and profitable: to a synergy that is created between development and operations as well as business and IT.  In order for one to define what something is, one has also to define what it is not. Let’s try to understand what DevOps is by understanding what it is not. There are many myths surrounding DevOps. Let’s quickly look at them so we can focus on how, where and when to start your DevOps Governance (or the corporate cultural embracing of) to realize the business value behind it and unleash its power.

Let’s look at some these myths (Reported on The Phoenix Project by Gene Kim; Kevin Behr; George Spafford) and I will comment on each in parenthesis, thus adding my 2 cents:

• DevOps replaces Agile. (DevOps is not a replacement for Agile, but it is Agile extended to IT capabilities, instead of just Agile as a SDLC methodology.)
• DevOps Replaces ITIL (or ITSM). (ITIL servers a foundation for an organization to support DevOps work streams, as it provides the baseline for the service life cycle, from the strategy to the design, transition and operation; realized by DevOps. DevOps is ITIL friendly and works as an ally to ITIL, not as a replacement.)
• DevOps means “NoOps”. (Because in DevOps a lot of the self-service for Operations is needed, it does not mean a replacement of operations, but a way to bring operations closer to the development life-cycle.)
• DevOps is only for Open Source. (DevOps as a concept is agnostic to vendor or license agreements. So it makes no sense to apply it only to Open Source. It is applicable to any enterprise.)
• DevOps is just “Infrastructure as Code” or “Automation”. (While it is true that automation is essential to DevOps, it is not true to assume DevOps is defined by automation only.)
• DevOps is just for startups. (DevOps is for any organization that has business or IT needs and wants to remain competitive and agile in time to market delivery and value creation.)
• DevOps is a tool. (DevOps is a philosophy and a culture which is implemented with tooling as well, but DevOps is not a tool itself and cannot be reduced to a tool only. It depends on tooling but tooling alone does not define DevOps.)

This list could go on and on.  The point being made here is that DevOps is not a hype: the myths around it help to mystify something that is rather simple to understand in relation to its business value. In order to understand what value DevOps can bring to an organization ask yourself a few simple questions:  

• How long does it take your organization today to go from an idea (business or IT requirement), to code successfully deployed to and running in a production environment? What is the current time to market?
• How more competitive can a business be if the time and value to market are shortened?
• How is your competition doing and how can DevOps be used to position you ahead of it?

These are questions in every CIO/CTO mind. Not only CIOs/CTOs but in other roles in a corporation. DevOps has a different meaning and value back depending on which role your play. DevOps (implementation or the lack of) will affect everyone in an organization involved in a product or service, just like Lean and Six Sigma in manufacturing. From the VP of Development and Infrastructure to portfolio, product, program, project managers, to architects, engineers and developers, to quality assurance, testers, operations, security, release, management and other stakeholders; they all have an important role in the adoption of and benefits from DevOps. They all gain by embracing it as the results and benefits will be measurable. DevOps in a nut-shell is a culture that fosters "Continuous Deployment", "Continuous Integration", and "Continuous Testing to achieve Continuous Delivery". All of which backed up by "Continuous Monitoring, Alerting and Reporting". All efforts collaborating in a more tightly coupled way with shared ownership and responsibility for the final business product: benefiting the overall business strategy via IT execution.

In part 2 of this paper we will discuss “Why” DevOps. Stay Tuned!