Skip to content

November 30, 2021

Where to Start with DevOps Part 1: Selecting which Value Stream to Start With

By Gene Kim

where to start with devops #1

Choosing the best value stream for your DevOps transformation deserves careful consideration. Not only does the value stream you choose dictate the difficulty of your transformation, but it also dictates who will be involved in the transformation, how you organize teams, and how you can best enable those teams and the individuals within them.

In the first part of our Where to Start with DevOps series, adapted from the fully updated and expanded second edition of The DevOps Handbook, we’ll look at three key components for selecting the best value stream to start your DevOps transformation with:

  • Whether they are a greenfield or brownfield service
  • Whether they are systems of engagement or systems of record
  • Best practices for expanding DevOps across your organization

Determining whether to Start with a Greenfield or Brownfield Project


Originally used for urban planning and building projects, greenfield development is when we build on undeveloped land; while brownfield development is when we build on land that was previously used for industrial purposes, potentially contaminated with hazardous waste or pollution.

In urban development, many factors can make greenfield projects simpler than brownfield projects—there are no existing structures that need to be demolished and there are no toxic materials that need to be removed.

In technology, a greenfield project is a new software project or initiative. Likely in the early stages of planning or implementation, greenfield projects are where we build our applications and infrastructure anew, with few constraints.

Starting with a greenfield software project can be easier, especially if the project is already funded and a team is either being created or is already in place.

On the other end of the spectrum are brownfield DevOps projects—these are existing products or services that are already serving customers and have potentially been in operation for years or even decades.

Brownfield projects often come with significant amounts of technical debt, such as having no test automation or running on unsupported platforms.

When transforming brownfield projects, we may face significant impediments and problems, especially when no automated testing exists or when there is a tightly-coupled architecture that prevents small teams from developing, testing, and deploying code independently.

Although many believe that DevOps is primarily for greenfield projects, DevOps has been used to successfully transform brownfield projects of all sorts. In fact, over 60% of the transformation stories shared at the DevOps Enterprise Summit in 2014 were for brownfield projects.

One of the most popular examples of a brownfield project is Etsy (see the Etsy case study here).

 


Systems of Record vs. Systems of Engagement


The Gartner research firm has recently popularized the notion of bimodal IT, referring to the wide spectrum of services that typical enterprises support. Within bimodal IT there are systems of record, as well as systems of engagement.

  • Systems of record typically have a slower pace of change and often have regulatory and compliance requirements (e.g., SOX). Gartner calls these types of systems “Type 1,” where the organization focuses on “doing it right.”
    Example: Think ERP-like systems that run our business (e.g., MRP, HR, financial reporting systems), where the correctness of the transactions and data are paramount.
  • Systems of engagement typically have a much higher pace of change to support rapid feedback loops that enable them to conduct experimentation to discover how to best meet customer needs. Gartner calls these types of systems “Type 2,” where the organization focuses on “doing it fast.”
    Example: Think customer-facing or employee-facing systems, such as e-commerce systems and productivity applications.

While it may be convenient to divide up our systems into these categories; we know that the core, chronic conflict between “doing it right” and “doing it fast” can be broken with DevOps.

The data from the State of DevOps Reports—following the lessons of Lean manufacturing—shows that high-performing organizations are able to simultaneously deliver higher levels of throughput and reliability.

Furthermore, because of how interdependent our systems are, our ability to make changes to any of these systems is limited by the system that is most difficult to safely change, which is almost always a system of record.

Scott Prugh, VP of Product Development at CSG, observed, “We’ve adopted a philosophy that rejects bi-modal IT, because every one of our customers deserve speed and quality. This means that we need technical excellence, whether the team is supporting a 30-year-old mainframe application, a Java application, or a mobile application.”

Consequently, when we improve brownfield systems, we should not only strive to reduce their complexity and improve their reliability and stability, we should also make them faster, safer, and easier to change.

Even when new functionality is added just to greenfield systems of engagement, they often cause reliability problems in the brownfield systems of record they rely on.

By making these downstream systems safer to change, we help the entire organization more quickly and safely achieve its goals.


Expanding DevOps Across Our Organization


Within every organization, there will be teams and individuals with a wide range of attitudes toward the adoption of new ideas, while others with more conservative attitudes resist them (the early adopters vs. the late majority, and laggards).

Our goal is to find those teams that already believe in the need for DevOps principles and practices, and who possess a desire and demonstrated ability to innovate and improve their own processes. Ideally, these groups will be enthusiastic supporters of the DevOps journey.

Especially in the early stages, we will not spend much time trying to convert the more conservative groups. Instead, we will focus our energy on creating successes with less risk-averse groups and build out our base from there.

Even if we have the highest levels of executive sponsorship, we will avoid the big bang approach (i.e., starting everywhere all at once), choosing instead to focus our efforts in a few areas of the organization, ensuring that those initiatives are successful, and expanding from there.

We also want to follow a safe sequence that methodically grows our levels of credibility, influence, and support.

The following list, adapted from a course taught by Dr. Roberto Fernandez, a William F. Pounds Professor in Management at MIT, describes the ideal phases used by change agents to build and expand their coalition and base of support:

1. Find Innovators and Early Adopters

In the beginning, we focus our efforts on teams who actually want to help—these are our kindred spirits and fellow travelers who are the first to volunteer to start the DevOps journey. In the ideal, these are also people who are respected and have a high degree of influence over the rest of the organization, giving our initiative more credibility.

Especially in the early stages, we will not spend much time trying to convert the more conservative groups. Instead, we will focus our energy on creating successes with less risk-averse groups and build out our base from there.

2. Build Critical Mass and Silent Majority 

In the next phase, we seek to expand DevOps practices to more teams and value streams with the goal of creating a stable base of support. By working with teams who are receptive to our ideas, even if they are not the most visible or influential groups, we expand our coalition who are generating more successes, creating a “bandwagon effect” that further increases our influence. We specifically bypass dangerous political battles that could jeopardize our initiative.

We must demonstrate early wins and broadcast our successes. We do this by breaking up our larger improvement goals into small, incremental steps. This not only creates our improvements faster, it also enables us to discover when we have made the wrong choice of value stream—by detecting our errors early, we can quickly back up and try again, making different decisions armed with our new learnings.

3. Identify the Holdouts

The “holdouts” are the high profile, influential detractors who are most likely to resist (and maybe even sabotage) our efforts. In general, we tackle this group only after we have achieved a silent majority, when we have established enough successes to successfully protect our initiative.

Ultimately, expanding DevOps across an organization is no small task. It can create risk to individuals, departments, and the organization as a whole.

But as Ron van Kemenade, CIO of ING, who helped transform the organization into one of the most admired technology organizations said:

By choosing carefully where and how to start, we are able to experiment and learn in areas of our organization that create value without jeopardizing the rest of the organization. By doing this, we build our base of support, earn the right to expand the use of DevOps in our organization, and gain the recognition and gratitude of an ever-larger constituency.


Continue reading the Where to Start with DevOps Series:


- About The Authors
Avatar photo

Gene Kim

Award winning CTO, researcher, and author.

Follow Gene on Social Media

No comments found

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…