lessons for the industrial internet (pdf with notes)

powered by

Friday, November 30, 12

“The skill of writing is to create a context in which other people can think.”

-Edwin Schlossberg


I want to start this talk with a quote from Edwin Schlossberg who said, “The skill...” And that’s exactly what GE is trying to do with its work on the Industrial Internet - framing the shape of the future so that we can all think about how best to get there.


I am excited about GE’s vision of the Industrial Internet - I believe that, as you’ve heard today, the combination of algorithms, sensor-enabled intelligent machines, and people has the potential to utterly transform the industrial landscape, and with it, the very nature of our society. Whenever people asked me what came after “Web 2.0”, I’d tell them that it was when applications for collective intelligence were driven by sensors rather than people typing on keyboards. But I was thinking about sensor-driven consumer applications - and while that is clearly happening too - the industrial internet may be even more significant.

“History doesn’t repeat itself, but it does rhyme.”

-Mark Twain


But in addition to thinking about the future, it’s worthwhile to reflect on the past, to see what lessons we can take from it. As Mark Twain said, “History...

Lessons from the Internet


So I want to see what lessons we can take from the original design of the Internet that we should keep in mind as we think about the Industrial Internet.

TCP/IP: The virtue of simplicity“Hourglass” Architecture

CTSB, NRC, “The Internet’s Coming of Age” (2001)

any task

any medium

the Internet’s not-so-secret

sauce

any device

any person


The first of these lessons is to do as LITTLE as possible. While competing standards tried to specify everything in detail, the IP protocol did the smallest, necessary thing: it specified the format of the data that would be exchanged between machines. Everything else could vary, from the transport protocols and transport medium all the way to the kinds of applications and services that were exchanging that data. Jonathan Zittrain refers to this as the “hourglass architecture” of the internet. In our work on the Industrial Internet, we shouldn’t forget to think about the smallest things we need to agree on. Vibrant platforms grow from small beginnings.

Build a simple system - let it evolve“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”

-John Gall, in SystemanticsFriday, November 30, 12

The value of simplicity was summed up by John Gall many years ago in a book called Systemantics. Besides DNA and the structure of life itself, the Internet is the best possible demonstration of how simple rules can lead over time to incredible complexity.

http://en.wikipedia.org/wiki/Systemantics

http://en.wikipedia.org/wiki/Systemantics

An “architecture of participation”


The hourglass architecture also allows what I’ve elsewhere called “an architecture of participation.” When all you need to agree on to get started are simple rules for communication, the endpoints are free to innovate. This is what makes the internet “open” and “permissionless.”


The web is a terrific example of how the simple IP-based internet enabled more complex systems to grow. Tim Berners-Lee didn’t have to ask anyone’s permission to put up an entirely new kind of service on the net. And he designed the web the same way: a communications protocol, with software designed to read and write that protocol - what we now know as a web server and a browser. Anyone could add anything to the web, as long as they spoke the same language. Everything we take for granted today came from that simple, rigorous design decision.

A new platform can be said to succeed when your customers and partners build new features before you do


The original designers of the internet didn’t create the web; but they made it possible for Tim Berners-Lee to do so. Tim didn’t create Google, but he made it possible for Larry and Sergey to do that.


Even more importantly, consider how even platforms that weren’t originally designed for extensibility cry out for it. When Paul Rademacher reverse-engineered the format of Google’s new mapping app to create the first map mashup, housingmaps.com, Google could have branded him a “hacker” and tried to shut him down. Instead, they responded by opening up free APIS for developers. Other, more closed platforms were left in the dust, and Google Maps became the preferred mapping platform for the web. Amazon’s first venture into web services began the same way. They invited in all the people who were building unauthorized apps against their service, and figured out how to open them up for innovation.

More than 50,000 iPhone applications in the first year! Now at 688,000


Even Apple had to learn this lesson. We’re all so excited about the story of the iPhone App Store, but it’s worth remembering that the AppStore wasn’t a work of Steve Jobs’ genius - he was resistant to the idea. It was the company responding to users who wanted more from the device. Apple created the App Store in response to developers “jailbreaking” the iPhone and iPod Touch to add unauthorized features. And that’s when we went from phones that had twenty or thirty apps cooked up in a back room deal to a platform that allows anyone to come up with new features.


But Apple bet too much on a closed system, and failed to take into account some key lessons from both the PC and the internet, that more open, participatory architectures with room for lots of players to succeed tend to outperform closed, controlled systems. That lesson is playing out right now, as Apple’s once seemingly unassailable hold on the smartphone and tablet markets is eroding in the face of more open systems like Android. There are some lessons here for the industrial internet as well.

The Robustness Principle

“TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.”

-Jon Postel in RFC 761 (Transmission Control Protocol, 1980)


This idea goes back to the very roots of the internet. There’s a mythology in which the network was designed to be decentralized in order to withstand a nuclear war. The reality is more humble. What I find particularly useful as a starting point for the discussion of robustness is so-called “Robustness principle” of the original TCP specification. This was also a key element of the web, which violated every principle of prior hypertext systems, which required every link to resolve. That is what we now know as the 404 - a standard page that just announces that what you’re looking for doesn’t seem to exist. That is, a web connection fails gracefully.

http://tools.ietf.org/html/rfc761

http://tools.ietf.org/html/rfc761

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Failing Gracefully


I believe that failing gracefully needs to be a key characteristic of the Industrial Internet as well. There will be a temptation to try to define rigorous protocols that take into account every eventuality, but such systems will be rigid, and when they fail, failure will be catastrophic. This may sound like heresy to those with an industrial mindset where you try to take into account every eventuality.


But there are many different kinds of graceful failure. For example, in search, we don’t get a single search result, we get a range of them. Redundancy is a kind of graceful failure. Failing gracefully is clearly a characteristic of cloud computing infrastructure today as well. I like to say that unless you’re able to fail, you are unable to scale. Internet operations at scale require a kind of robustness that includes tolerance for failure.

“The way people think about security, especially security on computer networks, is almost always wrong. All too often planners seek technological cure-alls, when such security measures at best limit risks to acceptable levels. In particular, the consequences of going wrong—and all these systems go wrong sometimes—are rarely considered.”

-Bruce Schneier


This is also true in security.

“The view of fracture [Paul] Paris brought to Boeing was dramatically different from the one that had guided construction of the Comet. Cracks were the centerpiece of the investigation. They could not be eliminated.They were everywhere, permeating the structure, too small to be seen. The structure could not be made perfect, it was inherently flawed, and the goal of engineering design was not to certify the airframe free of cracks but to make it tolerate them.”

http://stillness.ph.utexas.edu/~marder/BrokenEducation2011.pdf

The Failure of the deHavillands Comet and the Rise of Boeing


While it may seem that this philosophy of the internet is inappropriate for the highly engineered systems of the Industrial Internet, I’ll remind you of the failure of the deHavillands Comet in 1954 and the rise of Boeing as the dominant provider of commercial aircraft. Over the course of three years, three Comets fell out of the sky for initially unexplained reasons. It eventually became clear that the problem was metal fatigue. deHavilland tried to eliminate all cracks, Boeing learned to live with them.



SimplicitySimplicity Generativity RobustnessStandardize as little aspossible, but as much as needed, so the systemis able to evolve.

Create an architecture of participation that leads tounexpected innovationsand discoveries and buildsa new ecosystem of companies that add valueto the network.

Tolerate failure and degrade gracefully.

Key design goals for the Industrial Internet


In summary, as we think hard about the future, let’s remember what we can learn from the original design of the internet that can make the Industrial internet more simpler, more participatory and generative, and more robust.


There’s one other thing I want to touch on. I was really impressed by GE’s inclusion of people and job roles in their thinking about the industrial internet, because the industrial internet will not just transform the world of machines. It will transform the world of work. In that regard, I want to share some thoughts from an intriguing new ebook by Michael Schrage called “Who Do You Want Your Customers to Become”. The fundamental idea of this book is that great transformative innovations don’t just create new products or even new business processes, they fundamentally change the nature of their customers.


Henry Ford is a great example of this. He created not just the Model T and the assembly line, but also the kind of society in which people expected that they could own and drive one. He created the weekend, so people would have leisure to drive his product. Similarly, the internet and smartphones have changed forever our expectations of access to information. To succeed, the Industrial Internet will also change who we are and what we expect from our infrastructure and machines.

“What I learned from Google is to only invest in things that close the loop.”

- Chris Sacca


There’s one final lesson from the internet that I want to talk about. Investor Chris Sacca, who used to run special projects for Google, once remarked “What I learned...” One of the powerful things about both the consumer internet and the industrial internet is the use of data to extract meaning in real time, “closing the loop” and making systems more intelligent.

There’s another sense in which we can close the loop. In the following panel, we’re going to explore the ideas we’ve talked about so far today as a way of closing the loop and reflecting on what we’ve learned.

powered by

Thank You


lessons for the industrial internet (pdf with notes)

Technology