Breaking the Second Moore's Law: Clouds and the Two Enterprise Cultures
In the world of innovation and business strategy books, where vacuous roadmaps rule, falsifiable assertions and clear positions are rare. Geoffery Moore is an exceptionally clear signal in this bleak wasteland of noise . In his 2005 book Dealing with Darwin, he proposed a stimulating law, which I'll call the Second Moore Law:
There are two basic business model architectures, complex systems and volume operations, and the two cannot and should not mix, or share best practices. Businesses with one architecture should not covet the benefits of the other.
The distinction is a nuanced one, but has almost biblical clarity (Moore actually uses the word "covet"). Think "high touch mega-deal business" vs. "mass production of widgets" for starters. Like every good dogma, it catalyzes a lot of creative thought when you attempt to think of ways to break it. My question to the Enterprise 2.0 crowd is this: does cloud technology provide a way to break the Second Moore Law? I think it does, but it will take some extraordinary business creativity to do so.The Two Enterprise CulturesThe Second Moore's Law gets at a far more fundamental distinction in business than small/large or closed-and-hierarchical/open-and-flat. It gets at the very definition of a business, the purpose of which, if you recall your Papa Drucker, is "to create and keep a customer." Complex systems customers, like buyers of enterprise healthcare plans, or individuals buying homes, require a high-touch, high-customization approach. Volume operations customers, like individuals buying coffee, require a low-touch, a few-sizes-fit-all approach, where customization, if available at all, is in DIY form. Here are two pictures illustrating the difference, taken from Moore's book website.The complex systems model involves selling a solution which involves an integration platform over legacy infrastructure, followed by a technology architecture layer, a mix of your modules and third-party modules, a "solution architecture" that maps the bottom of the cake to the customer's needs, and topped by an icing of consulting and integration services. You may instantly think "IBM" for the whole thing, and "Dell" or "Microsoft" for the modules, but think broadly, beyond IT, to businesses like Boeing aircraft, space launch services, or commercial real-estate construction.The volume operations model on the other hand, involves starting with a base technology that spawns a portfolio of offerings which spread out through a ring of channel operations to a huge base of consumers, who generate cashflow as a river of small-ticket transactions. This is most familiar in retail, but be careful not to conflate volume/complex with consumer/enterprise or small/large (I'll leave you to work out the nuances).The book has a rich discussion of the two, but I'll highlight just a few elements. Let's return to Drucker for guidance in how to interpret the assertion that complex systems and volume operations business architectures do not mix. Two of Drucker's ideas are pertinent. First, that there are only two really essential functions in business, marketing and innovation. That's what you need to create and keep a customer. Second, maximizing profitability is not the goal of business (that, as we said, is to "create and keep a customer"). Profitability is a constraint. You have to make a profit primarily to manage risk and uncertainty in order to ensure survivability and meet the "keep customer" part of the definition of a business, which you cannot do if you aren't around. So based on Drucker's guidelines, here are the parts of the Second Moore's law that are worth pointing out:
Marketing: The marketing function (which in the broad sense encompasses everything from positioning and competitive strategy to market research, not just selling) could not be more different. The high-touch/low-touch distinction is an obvious one, as is the difference in the length of the sales cycle and the revenue balance between initial buy and post-sale. But there are more subtle ones. Complex systems architecture companies must orchestrate a large coalition of companies to deliver a solution, so reputation and collective positioning matter more. Volume operations work primarily by pull rather than push, so branding and stand-alone segment positioning is key (rather than coalition positioning). Marketers who are good at one are rarely good at the other.
Innovation: Moore's book is based on the technology adoption lifecycle and the category maturity cycle. He has a thorough discussion of 15 different types of innovation, from initial disruption to end-of-life innovations and harvesting. The big point, which he elaborates painstakingly, is that all types play out very differently under the two architectures. For example, in the first kind, disruptive innovation, which comes at the birth of a category, complex businesses disrupt via technlogy innovations (example, Oracle in abstracting databases from mainframes), while volume businesses typically disrupt through business model innotavtions (for example, Kindle and free Wi-Fi downloads).
Profitability Constraint: Each business architecture also has a very different gross margin model (set by Wall Street expectations for that architecture). Roughly, "messy cost structure, large margins, low velocity" versus "lean cost structure, tight margins, high velocity."
These three "business basics" distinctions provide powerful reasons why the two don't mix. It goes right down to the personalities and strengths in your talent base. To make it explicit, Moore offers a "worked" example with a simple 7-stage linear value chain (the "skeleton" of a business), involving [Market] Research, Design, Sourcing, Making, Marketing, Selling and Servicing. Each value chain element, he shows, ends up getting structured differently. For example, the first step in the value chain, market research is primarily driven by qualitative scenarios in the complex systems architecture, because the customer base is small and diverse (example the airlines Boeing sells to), with no useful statistical structure as a "market." Metaphors and story telling guide market research. In volume operations by contrast, quantitative market research and analytics dominat (Netflix is the classic here).So there you have it, that's the two cultures for you. And Moore is pretty much resolute in his recommendation: the two cannot mix. The meet in the marketplace, and play a countercyclical dance, as complex offerings get increasingly tightly integrated, modularized and commoditized, thus moving from "complex" to "volume" regimes (example: mainframes to PCs), leaving the complex systems incumbent to look for new value at the next layer of the offering. But despite this partnership and meeting, they cannot play each other's games.Or maybe they can. Can the cloud break this law?Clouds and the Two CulturesThough Moore's book has a brief discussion of Salesforce.com, and has an obscure discussion of how products can become platforms, it doesn't really get to the idea of the cloud comprehensively (the book was published in 2005).So is the idea of the cloud (whether it is Amazon bare-metal, Google's App Engine level, or Microsoft Azure) a game changer at the level of business models? Certainly not in the general sense. Building Boeing jetliners will never be the same game as building Hyundai cars (automobiles are the most complex of the volume operations businesses, according to Moore) or Bics. I am an aerospace engineer, and I am pretty sure there is no currently feasible way to offer air-travel platforms that scale by the seat. You'd need something like a highly aerodynamic and fuel-efficient formation-flying set of auto-piloted 1-person aircraft to get to the aerospace equivalent of Amazon EC2. Since I studied formation flight in grad school, I am fairly sure that isn't going to happen in the next 100 years.But within the narrower world of IT systems, where the laws of physics are less constraining, can it happen, at least upon maturity in a few years, if not today?I believe it can, and it can happen through the complex model becoming mostly unnecessary, and the bulk of revenue moving into the volume model. The complexity doesn't go away, it just gets absorbed into market-based on-demand coordination models that are owned by nobody, not even the "integration" vendor, who can then become the "platform" vendor.
The Free-Premium Stack: Every module vendor has grand visions of a stack where a free (possibly open source supported) base props up an SMB volume operations "premium" version, and a "super-premium" one for large enterprises. Unlike the integration challenges of 1.0 technology (like setting up special customizations to copies of Windows sold to a Fortune 100 company), there is a secret hope at work that SaaS, WebTops and XML-based SOA integration standards like RSS, integrating into a complex system will require no extra customer-specific work. Even if you are selling a 10,000 seat license. Holy grail, yes, but conceivable in a way perpetual motion machines are not.
The "Open Platform": If module vendors are dreaming low-touch integration dreams, the platform vendors have similar hopes. With the evolution of open APIs and SOA as legitimate technology strategies, there is the hope that integration work will not be demanding on the platform end either. Perhaps it can be as simple as the CIO's staff checking off a bunch of boxes for supported modules, and IT ecosystems simply culling out module species that don't talk the main integration languages.
The "Sip" Sales Cycle vs. the Mega-Deal: Another big reason to believe the Second Moore Law can be broken is that it is now possible to engineer sales models where even very complex offerings can be sold with an entry-purchase in the volume regimes. Cloud-metered by-the-sip sales in fact. Dell sells to large enterprises by the truck-load. Amazon EC2 can sell by the box-hour. The goal is still millions of dollars from a single customer, but you don't get that with a starter sale of hundreds of thousands. You can get started with one unit. Stowe Boyd just pointed out a great Niall Kennedy piece on the power of flexible pricing, and the implications for business model architectures are seriously significant. Google actually charges by the type of database access command.
Open Source as an Integration-Operations Game Changer: Moore has a quick treatment of open source, but I believe he fails to realize its true significance, which is this: much of the operational complexity of complex systems business architecture comes about because it is attacked top-down within a single umbrella sale or engagement. When your offerings are based on open source, much of this complexity is simply shunted out to the open marketplace, where it is solved by market/crowdsourced mechanisms rather than complex operations. If you think about it, the idea that complex systems integrations offer Quality of Service (QoS) guarantees within the SLA (Service Level Agreement) is a specious one. Well-organized open source communities beat formal QoS and SLA models hollow on specific fronts like bug fixing, security threat resolution and so forth. Slowly, open-source coordination models are taking on more and more of the integration challenges through their market-like models, and winning.
The Moving Target Effect: The customer isn't standing still in all this. If "bazaar" models are taking over the open economy of free agents via open source, the insides of companies are also going from cathedral to bazaar architectures. This makes the complex-systems architecture slightly less necessary. Thomas Malone's "Future of Work" (2004) chronicles many of these internal changes, and things are evolving so quickly, his book is is already outdated.
The Invisible Hand and the Single Wringable Neck: Perhaps the biggest reason complex systems architectures have been required in the past is that CEOs of Fortune 100 companies have demanded a "single wringable neck." IT systems are now so large and complex, and so critical to operations, that if something bad happens on a large scale, the CEO needs to be able to call up a single powerful VP level account manager (or even the vendor CEO) and yell. What happens when there is no single wringable neck? Everybody expecting the mix of automated plumbing systems and market mechanisms inside and outside the firewall to resolve everything? This is perhaps the biggest unknown. In a sense, the single wringable neck is replaced by the invisible hand. As with Obama and the financial crisis, there are people to blame, but no single person who can be called and yelled at to get things fixed when a complex system breaks. My opinion is simple: it is evolution. We are now at a point of complexity in IT systems, where limiting things to levels where "single wringable necks" can exist is to limit business itself. Individual large businesses must be willing to operate as mini-economies rather than controlled systems. You get the threat of meltdowns and messy recoveries, but you also get the promise of a brave new age of next-generation business model species. The dinosaurs are dying. The mammals are coming.
Venkatesh G. Rao writes a blog on business and innovation at www.ribbonfarm.com, and is a Web technology researcher at Xerox. The views expressed in this blog are his personal ones and do not represent the views of his employer.
IT's Reputation: What the Data SaysInformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business really views IT's performance in delivering services - and, more important, powering innovation. Our results suggest IT leaders should worry less about whether they're getting enough resources and more about the relationships they have with business unit peers.
What The Business Really Thinks Of IT: 3 Hard TruthsThey say perception is reality. If so, many in-house IT departments have reason to worry. InformationWeek's IT Perception Survey seeks to quantify how IT thinks it's doing versus how the business views IT's performance in delivering services - and, more important, powering innovation. The news isn't great.
InformationWeek Must Reads Oct. 21, 2014InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.