DevOps for Beginners

What is DevOps, and why are organizations migrating to a "DevOps Operating Model"?

Let's start with two definitions, both from hyper-scale cloud vendors - Microsoft and Amazon:

The definitions agree on several key factors that are important for the DevOps beginner to understand -

• DevOps is "more than just tools" - it combines people, culture, processes, practices, tools, and technology
• DevOps is customer-centric - it strives to deliver value and better serve its customers.
• DevOps is about improving time-to-market - delivering value at "high velocity" (or continuously) but, importantly, without compromising the stability, availability, or security of your applications/services.

Why is DevOps needed, anyway?

Before we dive deeper into these three areas, it's important to ask, "Why DevOps"?

What was wrong with existing ways of managing Development and Operations (the "Dev" + "Ops" of "DevOps") that spurred the need to change?

This is also an important question to ask yourself before starting your own DevOps transformation - what customer needs are you currently NOT meeting with your current delivery model, and can you measure (quantify) the gap between what you're currently providing and what your customers need? This will help you build the "business case for DevOps" to get the investment and resources you need to achieve your DevOps transformation goals.

The short answer to this question is that in many organizations, Dev and Ops were silos with different objectives, different management reporting lines, and different cultures. This meant that work - particularly new application releases - didn't flow quickly and easily from the developer's workstations via the release pipeline into production environments. Changes to systems were seen as high-risk, introducing bugs, and leading to instability and poor availability of the production systems.

This, in turn, leads to customer dissatisfaction and complaints. This resulted in Operations, which were incentivized around stability and availability, being constantly in conflict with Development, which was incentivized around getting new features into customers' hands as quickly as possible.

This conflict and misalignment intensified as many Development teams adopted Agile and Continuous Delivery software development methodologies, emphasizing smaller, more frequent releases. Operations didn't have the "cultural philosophies, practices, and tools" to meet this need, at least not without risking the stability of production systems. Hence, DevOps evolved to meet this need for BOTH Speed AND Stability.

What should be in your DevOps model?

So, given that DevOps is about "more than just tools," what are the key elements of a "DevOps Model"?

A popular framework in the DevOps community is the CALMS model, first discussed by Jez Humble in "The DevOps Handbook." Table 1 - The CALMS Model breaks down the five elements of the model.

The challenge in moving to a DevOps Operating Model, particularly for technologists within the IT Department, is that we are great at implementing automation and tools but have far less experience in things like curating a strong culture, doing Lean process analysis, or effectively measuring customer outcomes as opposed to just monitoring system metrics. This highlights the need for the DevOps Transformation people to reach beyond the IT department to help foster the change. For example, the HR department should have people with more experience in fostering cultural change. If your organization is involved in manufacturing, you might find deep Lean experience in other parts of the business. The shift to a DevOps model is not a change that can be undertaken by the IT department in isolation from the rest of the organization.

Customer-centricity and aligning stakeholders

Next, we must look at what being "customer-centric" means as part of a DevOps Transformation.

For anyone in a leadership role, particularly in large, distributed Enterprise organizations, the complaint that "IT" isn't "aligned" to "The Business" is probably a familiar one.

Many [internal] customers or end-users in other departments feel that IT "isn't giving them what they want or need" to meet the needs of their real, external customers. IT is seen as a separate silo within the wider organization that is too slow, too inward-looking, and too focused on "doing nerdy IT stuff" than delivering customer value.

As unfair as this may seem to many inside the IT department, we only have to look at the structure of many IT departments to see the truth of this statement. Most traditional IT departments are organized around technological silos, e.g., DBAs in one team, networking and comms in another, server infrastructure in yet another, and so forth. To achieve an end-to-end customer outcome, e.g., the launch of a new product or service, requires coordination across all those different silos, which can be costly and time-consuming to achieve.

Is "product-alignment" part of the answer?

As part of their DevOps transformation, many organizations are moving to a "product-aligned" model, i.e., multi-disciplinary teams that slice across the traditional IT silos to focus on delivering a product/service that meets a particular customer need. These are also called "value-stream aligned teams" because they are aligned to a customer value stream and can deliver new products or product features "end-to-end," from the initial idea through the development phase to deployment and operations in production. These teams "own" their product, and their success metrics should align with real customer metrics like customer satisfaction, adoption, growth, etc.

Accelerating change

Finally, when we look at "time-to-market" and how DevOps can achieve "speed AND stability,"

Many traditional IT organizations, burnt by disastrous product rollouts marred by poor code quality, inadequate testing, and error-prone, manual release processes, are afraid of change. As a result, they release infrequently, sometimes even on annual or quarterly cycles. These "big bang releases" are, paradoxically, even harder to manage and coordinate, which increases risk. As discussed earlier, this also leads to intense frustration from "The Business" that IT is too slow and cumbersome. In turn, this leads the business users to try and bypass the IT department... the dreaded "shadow IT" - IT products and services not under the control of the IT department - and this can pose security and other risks to the business and its customers.

At the same time, users' appetite for new features and impatience around long-promised features yet to be released is ever-increasing. Organizations that can quickly meet or anticipate customer needs, with little or no disruption to existing services, at a lower cost, and with higher quality, can win market share from those that can't. DevOps research has shown that organizations that embrace DevOps, particularly those that excel in the four DevOps metrics discussed earlier, can exceed their goals in customer growth, market share, and profitability.

By fostering a culture that embraces change and leverages technical practices like automation to improve quality, reduce human error, and provide fast feedback if things go wrong, DevOps empowers organizations to release smaller changes far more frequently, with less risk. Many organizations are releasing hundreds, if not thousands, of changes to production every day, with a very low change failure rate and rapid lead-time-to-change. This delights internal and external customers alike, improves customer satisfaction, and starts a "virtuous cycle" of improved performance at every step of the value stream.

Good luck on your DevOps journey!