Key to understanding where you are in your organization’s journey is by defining DevOps
Much has been written about the compelling benefits of DevOps. However, the lack of a commonly agreed definition and clear prescription for implementing DevOps have left many people puzzled. Ask a group of experts, “How do you know when you have achieved DevOps?” and you are likely to get different answers.
It is tempting to dismiss definitions as academic. However, there are many incomplete, floundering and costly DevOps implementations that fall short of expected business benefits. This article explains some of the key challenges of defining DevOps, and the importance for having a definition at least within the scope of an enterprise. This article includes suggestions to help enterprises navigate their DevOps journey toward successful business outcomes.
An enterprise needs to know when it has accomplished DevOps to justify investments that support business goals. Pinning down a universal definition that satisfies the diverse community of stakeholders and survives the test of time has proven elusive. DevOps spans an evolving body of knowledge covering multiple humans, process engineering and technology disciplines. DevOps is never really “done” because the highest level of maturity, “The Third Way,” continuous improvement, defies setting boundary conditions.
To reconcile this dilemma, some have defined DevOps using vague or transient terms such as a “cultural movement.” Others have skirted the problem of definition with rambling statements describing what is involved to do DevOps, rather than state what it is in concise and concrete terms. Despite these challenges, acceptance of a definition by enterprise stakeholders is a key first step in any successful DevOps transformation. Any meaningful project progress measurements hinge on clear definitions.
I have found the following DevOps definition useful, relatively concise, and stable: “DevOps is the application of continuous flow, feedback and improvement to people, processes and technology for the benefit of agility, stability, efficiency, quality, security, availability and satisfaction.” Defining DevOps in this way is broad enough to stand the test of time, yet specific enough to answer key questions addressed by a good definition including “What is it?” “How it is done?” and “Why do it?” without too much rambling.
Whether you create of choose another definition, or decide to use mine, it is important that your cross-functional teams agree on one to align their goals and implementations and to have a basis to measure your DevOps progress and business outcomes.
DevOps and Continuous Delivery Partnership
DevOps is often said to refer to cultural aspects of high-performance software development and operations including leadership, teams and collaborative practices. Nevertheless, technical mechanisms involved in architecting applications and toolchains are essential for continuous delivery pipelines. Culture, without the technology associated with continuous delivery pipelines, will not achieve the expected benefits of DevOps and vice versa. Therefore, a practical measure of DevOps maturity really must include the technology and not only the culture.
Continuous Flow is a Practical Baseline
DevOps benefits are derived primarily from applying lean manufacturing methods to software development and operations. The “First Way of DevOps,” continuous flow, is first because it is a prerequisite to the Second and Third Ways. Therefore, the realization of continuous flow for at least one application in an enterprise can be considered a baseline for “having DevOps.” If you accept this point of view, then the answer to the question, “How do I know when I have DevOps” can be equivalent to the question, “What is the minimum requirement for continuous flow for an application?” In the context of continuous delivery toolchains, a continuous flow pipeline is achieved when it allows code submissions from development to successfully transit all pipeline stages to deliverable packages acceptable for production deployment.
A DevOps Model Application
Enterprises typically have many applications moving toward DevOps at different paces. Identifying one application as a model for DevOps is useful. The model provides a focal point for DevOps investments, and experiments. Other application product teams learn from the model application as it matures from discontinuous flow to continuous flow and higher levels of DevOps maturity.
A practical answer to, “How do you know when you have DevOps” depends on having a definition. While defining DevOps itself has been elusive, an enterprise definition is needed for alignment and progress measurement. Considering that DevOps needs continuous flow to accomplish business goals, it can be said you have DevOps when you have implemented continuous flow for at least one model application.