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?