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 signiﬁcant.

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

-Mark Twain

But in addition to thinking about the future, it’s worthwhile to reﬂect 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
any
any device
task
any
person

the Internet’s
not-so-secret
sauce

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

The ﬁrst 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 speciﬁed 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 Systemantics
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.

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 terriﬁc 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 ﬁnd particularly useful as a starting point
for the discussion of robustness is so-called “Robustness principle” of the original TCP speciﬁcation. 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.

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 deﬁne 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 Failure of the deHavillands Comet and the Rise of Boeing
“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 ﬂawed, 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

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.

Key design goals for the Industrial Internet

Simplicity
Simplicity Generativity Robustness
Standardize as little as Create an architecture of Tolerate failure and
possible, but as much participation that leads to degrade gracefully.
as needed, so the system unexpected innovations
is able to evolve. and discoveries and builds
a new ecosystem of
companies that add value
to the network.

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 ﬁnal 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 reﬂecting on what we’ve learned.

powered by

Thank You


Lessons for the Industrial Internet (pdf with notes)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Lessons for the Industrial Internet (pdf with notes)

Similar to Lessons for the Industrial Internet (pdf with notes) (20)

More from Tim O'Reilly

More from Tim O'Reilly (20)

Recently uploaded

Recently uploaded (20)

Lessons for the Industrial Internet (pdf with notes)