|
Café
Bistro
restaurants. Unlike the mobile app value stream where the business
need was to reduce time to market and increase feature throughput, the
business need here was to decrease cost and increase quality. In 2013, Nord-
strom had completed eleven “restaurant re-concepts” which required changes
to the in-store applications, causing a number of customer-impacting incidents.
Disturbingly, they had planned forty-four more of these re-concepts for
2014—four times as many as in the previous year.
As Kissler stated, “One of our business leaders suggested that we triple our
team size to handle these new demands, but I proposed that we had to stop
throwing more bodies at the problem and instead improve the way we worked.”
They were able to identify problematic areas, such as in their work intake and
deployment processes, which is where they focused their improvement efforts.
They were able to reduce code deployment lead times by 60% and reduce the
number of production incidents 60% to 90%.
These successes gave the teams confidence that DevOps principles and practices
were applicable to a wide variety of value streams. Kissler was promoted to
VP of E-Commerce and Store Technologies in 2014.
In 2015, Kissler said that in order for the selling or customer-facing technology
organization to enable the business to meet their goals, “…we needed to in-
crease productivity in all our technology value streams, not just in a few. At
the management level, we created an across-the-board mandate to reduce
cycle times by 20% for all customer-facing services.”
She continued, “This is an audacious challenge. We have many problems in
our current state—process and cycle times are not consistently measured
across teams, nor are they visible. Our first target condition requires us to
help all our teams measure, make it visible, and perform experiments to start
reducing their process times, iteration by iteration.”
†
The practice of relying on a stabilization phase or hardening phase at the end of a project often
has very poor outcomes, because it means problems are not being found and fixed as part of
daily work and are left unaddressed, potentially snowballing into larger issues.
Promo
- Not
for
distribution
or
sale
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
56 • Part II
Do'stlaringiz bilan baham: |
