I just finished reading this great book on architecture. It talks about
governance, optimizing ROI, the importance of precision measurements,
the opportunity found in inefficiency and how that inefficiency is often
perpetuated by “conventional wisdom” that needs to be overcome or even
disregarded in order to realize the opportunity.
You just have to get past the baseball on the cover.
The book is
Moneyball and it
about the Oakland Athletics, one of the best teams in baseball despite
having the second lowest payroll in the game. The author, Michael
Lewis, chronicles the A’s 2002 season when
they won 103 games and had a winning percentage second only to the
Yankees, who spend literally three times as much on players than the A’s
can. The A’s are successful because they precisely measure the
contribution of individual players and exploit the inefficiency of how
players are valued by other teams. In the process, they make decisions
that fly in the face of “traditional” baseball, but you can’t argue with
the fact they’ve been to the playoffs four years in a row. You could
say, the Oakland A’s have been architected to win.
I found the methodology that the A’a use to determine a player value
facinating. Where other teams value batting average and RBIs, the A’s
care much more about on-base and slugging percentage. The reason? The
A’s have figured out that on-base and slugging are much more important
to the team’s success. Obviously, batting average and on-base percentage
are related stats, but they aren’t identical and that difference leads
to an inefficiency the A’s can exploit. Players who get lots of walks
have lower batting averages but higher on-base percentages and are
typically undervalued by the market.
We’ve seen similar inefficiencies from valuing the wrong attributes in
our industry. For example, early on in the web era, there was little
understanding of the importance of scalability over performance. As a
consultant in the late 90′s, I often saw systems designs that optimized
performance at the expense of scalability. It took a long time for
people to realize how much more important scalability was. It didn’t
help that scalability was harder to measure and was often
counter-intuitive. Throwing away objects between method calls? What
lunatic came up with that idea? Of
course, MTS turned out to be a big success and defined the processing
model we still use today.
Today, everyone has pretty much figured out the value of scalability
over performance. The question is, what will the next opportunity be?
Or, to use the A’s terminology, what are people overpaying for?