October 2010 Archives

(image from 1986 LAN course guide via Google Books)

Before we can have an Internet of Things, we will need to have a LAN of things. Remember local area networks? They formed a key step in the development of the Internet: rather than everything being connected to the Internet, and communicating that way, LANs connected small handfuls of devices. Perhaps one of the devices had a connection to the outside world, but that may have not mattered much. Most of the utility of a LAN came from its local functionality. Thus, before we can build a useful (from a user perspective) Internet of Things, we need to learn to build useful LANs of Things.

A place to start understanding LAN of Things utility is by looking at what made actual LANs useful. Here's a definition of LANs from 1988:

"A local area network, LAN, is a communication and data storage system made from building blocks that can be added and shaped as required. They combine transmission, storage, and processing operations to meet specific user applications."

There are several points to this definition that are quite relevant to the current state of ubiquitous computing (and the Internet of Things):

• Devices are "building blocks" that serve specific functions. Printers, tape drives and modems all served specific functions in the early LAN ecology.
• They "combine transmission, storage, and processing operations." In other words, each device works standalone, but it is the combination of the devices that provides greatest value ("synergy" in the business language of 80s).
• Components are "added and shaped [...] meet specific user applications." This implies that not all LAN have the same components and that LANs are built as needed, rather than defined in its entirely beforehand.

In the 80s, this arrangement was one of necessity: devices had to be specialized because making a general-purpose device with all of those functions was prohibitively expensive (remember computers that had built-in printers? Probably not. I suspect the price premium for that combination of functions probably put them outside of people's budgets).
In a post Peak MHz era we don't need to worry nearly as much about creating specialized devices to mitigate the cost of processing. However, functional specialization is still a valuable for helping people (users and designers) apply technology to specific use contexts.

If we look at books on The Internet of Things (I'm currently reading Interconnecting Smart Objects with IP) the examples of how the technology will be used has changed little since MIT's Auto-ID center was founded in the late 1990s. It's still focused on:

• Inventory control
• Home automation
• Logistics
• Energy management
• Etc.

These are all important topics, but in each case the use cases are still discussed from a highly top-down, centralized perspective. The writing seems to say "If we can attach a small processor to every box/bulb/person/etc. then we will be able to aggregate that information in these incredible ways." Great, but what happens when it's not on every box/bulb/person? What if it's only on a small number? Such top-down planning misses the way that technology is actually adopted. Technology adoption starts in small clusters, where there's a clear value to the people immediately present. Many failed websites are based on the idea that if everyone (or a sufficiently large group of people) uses the site, then there will be all of these great benefits for all. That may be true, but before it can be useful to many people, it needs to be useful to a few, since only a few will be using it initially. Ideally, a product still provides utility even if someone is using it alone. For example, it's possible to have a lot of fun, and advance levels, in World of Warcraft alone, but it's even more fun (and advancement is faster) in a group. It's possible to only use Slideshare just as a tool to publish your Powerpoints on your blog, but it's even more useful when you can look at other people's presentations.

This type of "useful alone -- even more useful with others" model applies to the ubicomp technologies underlying the Internet of Things, and is responsible for the slow adoption of these technologies. Metcalfe's Law almost always needs a jump start, and that's local utility. Thus, I think it's important to start thinking about what the highly localized uses of sparsely distributed technology can be.

• What can we do when there are only a couple of things with RFIDs in our house?
• What totally great service can be built on having two light switches that report their telemetry in the house?
• What totally valuable information can you tell me if I only wear my motion sensor every once in a while?

Small-scale utility is at the heart of the LAN of Things. If we can identify narrow, but highly valuable uses for distributed information processing, we can begin creating islands of utility that will, at some point, be practical to link and see the full hockey stick effect of network value. One example of this is RFID pet identification. It's been around for years, and in retrospect people will realize that their pets joined the Internet of Things about a decade before they did. Why did it succeed there? Because pets are very valuable and we only have a couple of them (unless you're that Russian lady with all the cats, but I suspect her cats aren't chipped). Our cars have machine-readable VINs. Why? Because we only have a couple and there are good financial reasons for why we want to keep track of them easily.

• What else is like this?
• How can we use these existing LANs of Things (cars, pets, UPC bar codes) and build networked services on them?

I don't know, but these are some of the questions I'll be working on over the near future. We'll see where this goes.