54 • Part II
Kissler concluded, “From a high level perspective, we believe that techniques
such
as value stream mapping, reducing our batch sizes toward single-piece
flow, as well as using continuous delivery and microservices will get us to our
desired state. However, while we are still learning, we are confident that we
are heading in the right direction, and everyone knows that this effort has
support from the highest levels of management.”
In this chapter, various models are presented that will enable us to replicate
the thought processes that the Nordstrom team used to decide which value
streams to start with. We will evaluate our candidate value streams in many
ways, including whether they are a
greenfield
or
brownfield
service, a
system of
engagement
or a
system of record
. We will also estimate the risk/reward balance
of transforming and assess the likely level of resistance we may get from the
teams we would work with.
GREENFIELD VS. BROWNFIELD SERVICES
We often categorize our software services or products as either greenfield or
brownfield. These terms were originally used for urban planning and building
projects. Greenfield development is when we build on undeveloped land.
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 nor are there 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, where we build our appli-
cations 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. Furthermore,
because we are starting from scratch, we can worry less about existing code
bases, processes, and teams.
Greenfield DevOps projects are often pilots to demonstrate
feasibility of public
or private clouds, piloting deployment automation, and similar tools. An
example of a greenfield DevOps project is the Hosted LabVIEW product in
2009 at National Instruments, a thirty-year-old organization with five thousand
employees and $1 billion in annual revenue. To bring this product to market
quickly, a new team was created and allowed to operate outside of the existing
IT processes and explore the use of public clouds. The initial team included
Promo
- Not
for
distribution
or
sale
Chapter 5 • 55
an applications architect, a systems architect,
two developers, a system auto-
mation developer, an operations lead, and two offshore operations staff. By
using DevOps practices, they were able to deliver Hosted LabVIEW to market
in half the time of their normal product introductions.
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.
In the Nordstrom example
presented earlier in this chapter, both the in-store restaurant systems and
e-commerce systems were brownfield projects.
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. In these cases, there
was a large performance gap between what the customer needed and what
the organization was currently delivering, and the DevOps transformations
created tremendous business benefit.
Indeed, one of the findings in the
2015 State of DevOps Report
validated that
the age of the application was not a significant predictor of performance;
instead, what predicted performance was whether the application was archi-
tected (or could be re-architected) for testability and deployability.
Teams supporting brownfield projects may be very receptive to experimenting
with DevOps, particularly when there is a widespread
belief that traditional
methods are insufficient to achieve their goals—and especially if there is a
strong sense of urgency around the need for improvement.
†
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. How we overcome these issues
are discussed throughout this book.
Examples of successful brownfield transformations include:
†
That the services that have the largest potential business benefit are brownfield systems
shouldn’t be surprising. After all, these are the systems that are most relied upon and have the
largest number of existing customers or highest amount of revenue depending upon them.
Promo
- Not
for
distribution
or
sale