78 • Part II
and our work so that Conway’s Law works to our advantage. Done poorly,
Conway’s Law will prevent teams from working safely and independently;
instead, they will be tightly coupled together, all waiting on each other for
work to be done, with even small changes creating potentially global, cata-
strophic consequences.
An example of how Conway’s Law can either impede or reinforce our goals
can be seen in a technology that was developed at Etsy called Sprouter. Etsy’s
DevOps journey began in 2009, and is one of the
most admired DevOps orga-
nizations, with 2014 revenue of nearly $200 million and a successful IPO
in 2015.
Originally developed in 2007, Sprouter connected people, processes, and
technology in ways that created many undesired outcomes. Sprouter, shorthand
for “stored procedure router,” was originally designed to help make life easier
for the developers and database teams. As Ross Snyder, a senior engineer at
Etsy, said during his presentation at Surge 2011, “Sprouter was designed to
allow the Dev teams to write
PHP code in the application, the DBAs to write
SQL inside Postgres, with Sprouter helping them meet in the middle.”
Sprouter resided between their front-end PHP application and the Postgres
database, centralizing access to the database and hiding the database imple-
mentation from the application layer. The problem was that adding any
changes to business logic resulted in significant friction between developers
and the database teams. As Snyder observed, “For nearly any new site func-
tionality, Sprouter required that the DBAs write a new stored procedure. As
a result, every time developers wanted to add new functionality, they would
need something from the DBAs, which often required them to wade through
a ton of bureaucracy.” In other words, developers creating new functionality
had a dependency on the DBA team, which needed to be prioritized, commu-
nicated, and coordinated, resulting in work sitting in queues, meetings, longer
lead times, and so forth. This is because Sprouter created a tight coupling
between the development and database teams, preventing developers
from being able to independently develop, test,
and deploy their code
into production.
Also, the database stored procedures were tightly coupled to Sprouter—any
time a stored procedure was changed, it required changes to Sprouter too.
The result was that Sprouter became an ever-larger single point of failure.
Snyder explained that everything was so tightly coupled and required such a
high level of synchronization as a result, that almost every deployment caused
a mini-outage.
Promo
- Not
for
distribution
or
sale
Chapter 7 • 79
Both the problems associated with Sprouter and their eventual solution can
be explained by Conway’s Law. Etsy initially had two teams, the developers
and the DBAs, who were each responsible for two layers of the service, the
application logic layer and stored procedure layer. Two teams working on two
layers, as Conway’s Law predicts. Sprouter was intended to make life easier
for both teams, but it didn’t work as expected—when business rules changed,
instead of changing only two layers, they now needed to make changes to
three layers (in the application,
in the stored procedures, and now in Sprouter).
The resulting challenges of coordinating and prioritizing work across three
teams significantly increased lead times and caused reliability problems.
In the spring of 2009, as part of what Snyder called “the great Etsy cultural
transformation,” Chad Dickerson joined as their new CTO.
Dickerson put into
motion many things, including a massive investment into site stability, having
developers perform their own deployments into production, as well as begin-
ning a two-year journey to eliminate Sprouter.
To do this, the team decided to move all the business logic from the database
layer into the application layer, removing the need for Sprouter. They created
a small team that wrote a PHP Object Relational Mapping (ORM) layer,
†
enabling
the front-end developers to make calls directly to the database and reducing
the number of teams required to change business
logic from three teams down
to one team.
As Snyder described, “We started using the ORM for any new areas of the site
and migrated small parts of our site from Sprouter to the ORM over time.
It took us two years to migrate the entire site off of Sprouter. And even
though we all grumbled about Sprouter the entire time, it remained in pro-
duction throughout.”
By eliminating Sprouter, they also eliminated the problems associated with
multiple teams needing to coordinate for business logic changes, decreased
the number of handoffs, and significantly increased
the speed and success of
production deployments, improving site stability. Furthermore, because small
teams could independently develop and deploy their code without requiring
another team to make changes in other areas of the system, developer pro-
ductivity increased.
†
Among many things, an ORM abstracts a database, enabling developers to do queries and data
manipulation as if they were merely another object in the programming language. Popular
ORMs
include Hibernate for Java, SQLAlchemy for Python, and ActiveRecord for Ruby on
Rails.
Promo
- Not
for
distribution
or
sale
80 • Part II
Sprouter was finally removed from production and Etsy’s version control
repositories in early 2001. As Snyder said, “Wow, it felt good.”
†
As Snyder and Etsy experienced, how we design our organization dictates
how work is performed, and, therefore, the outcomes we achieve. Throughout
the rest of this chapter we will explore how Conway’s Law can negatively
impact the performance of our value stream, and, more importantly, how we
organize our teams to use Conway’s Law to our advantage.
ORGANIZATIONAL ARCHETYPES
In the field of decision sciences, there are three primary types of organizational
structures that inform how we design our DevOps value streams with Conway’s
Law in mind:
Do'stlaringiz bilan baham: 
