Wednesday, November 09, 2005
Next Big Things - Pull Models
John Hagel has been developing a very powerful and cool idea lately, which I highly recommend you check out.
Before I get into it, here are the links - an introductory post at his site, a lightweight article at the McK Quarterly, and the biggie, the working paper itself (PDF).
Now, I've been reading quite a few papers lately, and was recently thinking how big ideas have been few and far between. John and JSB's latest idea is killer. It's the kind of big idea that you can literally think for a looong time about, and not exhaust the ramifications. It's beginning to inform a huge amount of my new work.
It's about how pull models - models that let resources be pulled through the value chain, or more complex ecosystems, like what John calls global process networks, rather than pushed through them - are emerging as dominant designs in what I would call a world of cheap information and cheap coordination (or what John calls a world of abundance and uncertainty).
This is hyperefficient for many reasons. Pull models naturally evade traditional sources of friction, like transaction costs. Because they rely on minimal coordination - coordination is ex post, not ex ante, huge specialization gains are unlocked (ie, you pull a learning module you need, rather than having it pushed to you by a costly training manager).
This is a huge concept, that ties together many, many threads of emerging thought for me. For example, pull models help me understand why I've been so preoccupied with the evolution of cheap information to cheap coordination for a while now: cheap coordination can enable resource transformations like pulling, which unlock huge amounts of value.
Alternatively, pull models have emerged naturally across the decentralized Media 2.0 space, because the efficiency gains are simply too high to ignore. That is, they're so high that prosumers have been able to easily set them up in spaces where firms continue to fail (P2P, communities, MP3 blogs, micromedia in general).
On a bigger level, it even nicely unifies all this stuff with another idea I've been thinking about lately - something I call the Demand Singularity; which is that most strategically crucial costs are shifting to the demand side of the economy (which is a big deal, because it blurs industry boundaries, etc). Now, for one idea to unify all this stuff so elegantly is pretty cool.
That said, I wish there was a more game-theoretic (aka, dynamics of pull models used strategically) analysis in the paper, because, honestly, I can't do it. I'd also like to hear pull models related back to more econ lit - cheap info, the boundaries of the firm, transaction costs, etc.
John has been one of my biggest influences for ages. I think that if you're playing in 2.0 markets, this paper is essential reading - be sure to check it out.
Sorry Umair, but this is one of the most destructive Web2 memes today - I'm surprised to find it here.
The root of this mistake is that RSS has been so successful ... to the point that it is being incorrectly implimented to solve problems far beyond the (accurate) constraints of its acronym.
"Pull" is the worst possible protocol for orchestrating complex processes - it's a syndication-only architecture. It does not apply to event-sensitive business process (basically, any non-syndication busines process).
When it is (applied to events), as suggested in this post, the results are ...
1) process latency (this is why you ping technorati) and,
2) massive processing overhead (this is why they don't ping you more often).
Beyond those problems, where business process require that the process remain state of the objects they impact, PULL can't do it.
The pull architecture is headed for major scalability challenges - and the user experience is truly suboptimal for most processes. Believe me, I've seen this fail spectacularly in Enterprise-size Internet companies.