OpenRTB and Architectural Innovation

I sent out a good number of emails on Sunday asking for opinions on OpenRTB.  People were mainly dismissive, partly because of the secretive way in which it was concocted, partly because some think Google is better accomodated than challenged, but mainly because the current goals of the spec are slight.  After reading the spec, I was a bit underwhelmed myself.  But I've changed my mind.

In a post in April, I talked about architectural considerations in ecosystem design, taking the engineering concept of End-to-End as an analogy.   In that post I was pushing for architectural change because innovation is highly dependent on a layered and modular architecture*.  Architecture is important.

But architectural change is also interesting in determining winners and losers, and that was my deeper motivation.  From a (technically astute) businessperson's point of view, the article to read is Rebecca Henderson and Kim Clark's Architectural Innovation: the Reconfiguration of Existing Product Technologies and the Failure of Established Firms.  They point out that "architectural" change favors innovators over incumbents.

In laying out their thesis, the authors talk about the failures of incumbent firms in adapting to relatively minor market changes, despite their deep expertise in the core components of the new products being built**.  They also make the distinction between incremental change, radical change and architectural change to draw attention to the fact that seemingly minor changes in the architecture of a system are actually more likely to cause incumbent dislocation than radical changes in the underlying technology.  This is an extremely important point.

The essence of architectural innovation is the reconfiguration of an established system to link together existing components in a new way... Architectural innovation is often triggered by a change in a component... that creates new interactions and new linkages with other components in the established product...

Established firms often have a surprising degree of difficulty in adapting to architectural innovation. Incremental innovation tends to reinforce the competitive positions of established firms, since it builds on their core competencies... In contrast, radical innovation creates unmistakable challenges for established firms, since it destroys the usefulness of their existing capabilities...

Architectural innovation presents established firms with a more subtle challenge... established organizations require significant time (and resources) to identify a particular innovation as architectural, since architectural innovations can often initially be accomodated within old frameworks.  Radical innovation tends to be obviously radical--the need for new modes of learning and new skills becomes quickly apparent... the introduction of new linkages is much harder to spot.  Since the core concepts of the design remain untouched, the organization may mistakenly believe that it understands the new technology***.

Dismissing OpenRTB as not being really anything very interesting at all is missing the point.  OpenRTB is not radical change, it barely qualifies as incremental change.  But it is architectural change.  It is the reconfiguration of existing linkages, or the beginning of it

Architectural change is subtle.  It is ignorable, for the time being.  But it may--may--be enough to change the existing architecture, the architecture that is more and more contained within Google.  Those that realize this and adapt to it will prosper.  Those that dismiss it--either because it is too subtle or because they are a large incumbent and ignore those who profess to compete with them--might find themselves Xeroxed.

There's a subtle belief in our VC-backed community that technological innovation is the sine qua non, the ne plus ultra.  Build a better mousetrap and the world will beat a path to your door.  Unfortunately, we're wrong.  Build a better technology and the incumbent will copy your innovation: they will notice a better technology pretty quickly.  What we need to do is change the competitive dynamic by shaping the architecture of the ecosystem.  This is something we can do without the permission of the Incumbent, and something the Incumbent will have a hard time responding to.

OpenRTB is just as start.  But the more new linkages we can create in the ecosystem, the better chance we have to compete based on merit.

-----

* An overview of this argument and its consequences was brought to my attention by Brad Burnham somewhat after I wrote about it: Internet Architecture and Innovation.  I want to say that this book is really excellent, because it looks like it, but I haven't had the time to do anything but flip through it yet.
** I am not in love with their chosen examples.  In both cases the lower-cost/lower-functionality disruptive (as in Innovator's Dilemma disruptive) element is also present, so as natural experiments they leave something to be desired.  Christensen, in fact, draws heavily from Henderson's work in his book--IMHO, more heavily than he seems to admit.  His description of this paper, in Dilemma, mentions their thesis primarily as a study in organizational structure.  Christensen then talks about "value networks" instead of architecture--and Dilemma is an essential read--but I think Henderson and Kim's work is more directly to the point here.
*** Read the article, really.  The case studies alone are worth it (and might give some comfort to those of us who despair at the ever-incipient chaos in our little sub-industry by highlighting that this is not something we managed to invent ourselves but is, in fact, normal.)