Assignment for week 5: Layering

Modularity is a fundamental concept of system design. The most important modules are so-called "platforms": hardware or software standards that a wide range of other services can be built on top of. (The term "platform" is often restricted to hardware, such as the Palm Pilot, but we are using the term in a broad sense.) Examples of platforms include the Internet, the IBM PC, the cellular telephone (actually several different cellular telephone architectures), Java (and its execution environment), and XML (and its associated software tools). By providing a clearly defined functionality that the world already wants for other reasons, platforms make it much easier to develop new information services.

Perhaps the most important kind of platform is a network service "layer". Messerschmitt explains the concept of a layer at some length, but here is a simple version. Networked services are complex, and so to manage that complexity they are organized in layers. Each layer provides a distinct and well-defined service. In particular, each layer defines a clear contract that governs its interactions with the service layers upon which it is built, and the service layers that are built upon it in turn. An example of a service layer is IP, the Internet Protocol, which is a protocol for moving packets of information ("datagrams") from point A to point B across a range of interconnected networks. IP is a "middleware" layer, meaning that it presupposes the existence of lower layers (the individual subnetworks, which move bits from one machine to another within a network) and is itself presupposed by higher layers (such as TCP, which controls the flow of packets through IP). Another example of a service layer is SSL, the Secure Sockets Layer for the secure transmission of sensitive information between clients and servers on the Web. SSL is built on top of TCP and IP, and other, more complex service can be built on top of SSL in turn. All modern networked services are organized in layers.

The design of service layers is not only technically complicated; it is also socially complicated. The whole point of a service layer is support a wide range of applications, and so the designer must learn precisely what services the potential applications need and then reconcile all of these potentially conflicting needs in the design. This can be hard. The applications may not have been imagined yet, the applications designers may work in different disciplines and may therefore not speak the same language, and the needs of the various applications may change over time. A good service layer is parsimonious: it is cleanly and simply defined, and represents a powerful and easily understood abstraction. An overly complex service layer invites trouble, and should be broken into more natural parts or rethought from scratch. Yet the boundaries between service layers are not always easy to define. The best way to design the boundary between TCP and IP, for example, was not at all obvious at first. IP, for example, is a so-called "best-effort" protocol -- packets submitted to a host or router that implements IP are not guaranteed to arrive in the correct order, or indeed at all. This sounds strange, but in retrospect it is a natural consequence of the demand for parsimony: by making fewer guarantees, IP can remain simple. TCP, which is built on top of IP, does offer guarantees, and part of its task is to resend packets that are not acknowledged.

In this assignment, we will explore the process of designing a service layer that can provide a platform for a wide range of other services. This is usually an advanced topic, but I want us to begin with it because of the central importance of networked applications architecture to the future of computing. Much of what we do in this assignment will make more sense after we discuss data modeling and other traditional technical subjects. But we will proceed anyway.

We will proceed as follows: I will sketch the workings of a brand new service layer that we will call the "Suitcase Layer" (abbreviated SL). A suitcase, roughly speaking, lets someone take their data with them wherever they go. (For those who know about such things, SL will be presumably built on top of a distributed object management layer such as CORBA or COM, assuming that the world has finally gotten around to adopting an object management standard by 2010.) By creating the illusion that one's data is always present, just as one's purse is always on one's shoulder, it makes computing (somewhat) location-independent and device-independent. Applications and devices that are SL-compliant allow a person to carry an elaborate computing environment from place to place. Wherever the person might be, their computing environment will spontaneously reconstruct itself using whatever devices happen to be present. Applications developers will rejoice because they can presuppose that data, application, and device have been brought together.

Let me start with an example. A major problem in restaurants, particularly someplace like California, is that diners have dietary requirements that are too complex to negotiate with the waiter. "Does that soup have any dairy products in it?" Only at the finest restaurants will waiters know things like this. So let us employ SL to create a menu that automatically configures itself to suit the requirements of a particular diner. We will have to start by defining data structures to represent these requirements. To keep it simple, we will imagine that an authority has defined a vocabulary of potentially sensitive ingredients, and then we will provide people with an interface that lets them check off the ingredients that they will not eat. These might include whole categories such as meat and dairy products that some people avoid for health reasons, or ingredients that some people are allergic to (eggs, cilantro), or ingredients that are proscribed by some people's religions (beef, pork, shellfish). (Observe that the categories are naturally hierarchical: meat includes beef, which includes veal.) It doesn't matter where this information is stored; the individual's suitcase will make the information available whenever it is needed.

To use a suitcase, the would-be diner carries a device that is the size of a double-thick credit card; this device could be carried in a wallet or incorporated into some other device. (Swatch has recently announced a similar device that is incorporated into a watch.) Even though it has no switches, data ports, display screens, or moving parts, it is constantly active. It talks to wireless networks, and especially to the spontaneous wireless networking capabilities of any and every device that supports the Suitcase protocol. One of these SL-compliant devices is made from electronic paper: a computer display screen that looks and feels like parchment but includes a bunch of digital electronics and can change its "pixels" from black to white and back. Participating restaurants "print" their menus on these devices by entering the ingredients and descriptions of the dishes into another device that is capable of exchanging data wirelessly with the menus. The electronic menus look and feel exactly like traditional paper menus. People who do not carry suitcases get a menu whose display is perfectly traditional -- the one-size-fits-all menu that most restaurants use now. When the menu detects the presence of a suitcase, however, it downloads the diner's list of proscribed ingredients and displays a customized menu. Dishes that cannot be made without the proscribed ingredients are not displayed; dishes that do not contain the proscribed ingredients are displayed as usual; and dishes that usually contain the proscribed ingredients but can be prepared without them are displayed in a modified form. Waiters carry SL-enabled order pads, just to make sure that each diner's requirements are transmitted correctly to the kitchen.

Now, in reading this description you will no doubt observe that nobody would be foolish to build a system like this on a special-purpose, stand-alone basis, what Messerschmitt calls a "stovepipe". But that's not what we're proposing. Imagine a world in which the Suitcase Layer is already well-established in the market, incorporated in dozens of applications, and supported by dozens of devices. Many other platforms are also widespread in this world, including the electronic paper technology. In that world, the incremental cost of building the dynamic menu application is not great. An entrepreneur could implement a prototype in an afternoon from readily available components, and the prototype could be used to raise funds and sell the concept to restauranteurs. It is not at all clear that the restauranteurs would buy the concept, of course. They would have to contend with more special orders in their kitchens, and they would have to represent their dishes in a structured data format such an XML document type. They might regard this as a hassle and a risk to their trade secrets, or they might regard it as a competitive necessity. We would have to see.

In any case, our job in this assignment is to work out some of the details of SL. Each team should, independently of the others, choose a community of practice, sketch out some SL-enabled services that the people in that community might find useful, pitch the concepts to some members of the community, iterate their designs a few times, pick the most promising one, and work out some of the details. Having done so, prepare a seven-minute presentation that tells about the community, explains the service concept, tells us something you've learned about how the service would fit into the life of the community, and (most importantly) specifies in as much detail as you can the demands that your service will make on the design of SL.

Let me explain these concepts in a little more detail. First, communities of practice. Systems analysis and design have historically been focused on geographically localized workplaces; their "users" have either been individuals or small numbers of workers operating within a rigid division of labor. That is the industrial automation paradigm, and it is an anachronism. Another approach is to design for communities of practice. A community of practice might be defined as those people who share some important thing in common. All of the world's truck drivers form a community of practice. So do all of the world's moms, all of the world's stamp collectors, and everyone in the world who uses the Apple Macintosh. The important thing about communities of practice is that they think together. They may not have an elaborate sense of collective identity -- an organization, a flag, a concept of "us" and "them" -- but they will always have institutions (formal or informal) through which they compare notes, spread news, and accumulate a collective memory. That is what Internet discussion groups are for; it is also what professional associations are for, and quilting bees, and after-work beer-drinking sessions. To design for a community of practice means to be aware of, and try to support and amplify, the community's ways: its work practices, forms of association, genres of communication, and so on. One no longer designs for "stamp collectors" as individuals; rather, one designs for "the stamp collectors' community". The distinction is subtle, and in some cases we admit that it has no important consequences. But it is often terribly important, especially when our design processes implicitly set out to prevent, substitute for, or suppress the mechanisms by which a community of practice thinks together.

You'll start by choosing a community of practice to work with. Your best choice is a community that a member of your team is located on the edge of. If you are a stamp collector, in other words, don't try to design for the community of stamp collectors. You are too close to them. But if your spouse is a stamp collector, then that's ideal. You will have access to the community, but you will have the intellectual distance that you will need to be analytical about it. Alternatively, you can choose a community that a team member belongs to, but then make a big point of distinguishing between the community member's perspective and everyone else's. In any case, you should probably choose a community of practice whose members move around, and who generally might find suitcases useful.

We want you to design iteratively. You won't have time to really learn about the community, or really design in a participatory way, or to iterate more than few times, but at least you'll get a rough sense. Start with basic knowledge about the community. Then come up with a few concepts. These concepts should be very simple, back-of-the-envelope one-liners. Pitch the concepts to a few members of the community and listen really hard to what they say. Would they find it useful? Most likely you'll discover that you were clueless about the community, or that you lacked important knowledge about its workings. That's good, because now you'll be shorn of some preconceptions. Rework your concepts or invent new ones. Bring them back to your community members, and sketch them in a little more detail this time. You might scribble a picture or a diagram. Listen again. Back and forth: designing, pitching, and listening. That is the iterative cycle. Go through it a few times -- not enough to really implement your prospective service, just enough to get a solid sense of it.

At some point you will pick the most promising of your candidates, and you will work it out some more. In particular, you will ask what demands it will make of the Suitcase Layer. What kinds of information about the person will have to be carried around? What kinds of devices need to be able to support the protocols, and which kinds of applications? Do multiple people's suitcases need to be able to communicate with one another? Does the suitcase need to support access to huge databases and gigantic information services? Do you need audio? Video? Large, complex documents in different formats? What kinds of information will need to have structure imposed on it (like the menus and ingredients in the example above)? We recognize that you will not be able to answer all of these questions precisely at this point in the course. That's okay. Do what you can.

Documentation and diagrams will be important. In seven minutes you will be communicating a lot of information, and so you should work hard to define your design concept in a concise and compelling way. Draw pictures of what it might look like. Build a model out of cardboard. Install props at the front of the room to show how it might work. The hardest part to explain might be the demands you'll be making on the design of SL. We can help with this.

We want the five groups to work independently. Once we come together and hear all of the group presentations, we will listen hard to the requirements that everyone is imposing on SL. These requirements will no doubt be hard to reconcile. They may conflict; they may pull the layer's design in five incompatible directions; they may be expressed in different vocabularies that are hard to translate into a single language. Some teams will probably mention issues that other teams will not. Some teams will probably go into more detail than others, or interpret what we mean by "requirements" in different ways. All of this is normal, and our point is exactly to teach what it is like to confront the incommensurable demands that different applications can place on an incipient platform.

Remember that we are designing ten years in the future. Please go ahead and presuppose the technologies of ten years from now: processors that are 100 times faster than we have now; platforms such as spontaneous wireless networking that are widely implemented; giant databases; small batteries; and so on. This will be clearer after the presentations for week 4.

Remember, too, the long-term agenda for the class projects: we are using design to investigate the reconfiguration of interactions among people in a heavily wired world. Some activities that are now conducted face-to-face will happen through electronic mediation, once the capabilities of that electronic mediation improve, and (less intuitively) some activities that are now conducted through electronic mediation will happen face-to-face, now that people are liberated to move wherever they want. If they don't have to sit at a keyboard in front of a clunky terminal any more, they will probably want to go someplace more interesting, such as getting together with the people they want to interact with face-to-face. Think about these phenomena in the community you are studying. What if the people had lots of portable computing and high-quality interaction media? What if all their information was in digital form, and what if they had suitcases to haul it all around with them? Would they all disperse across the landscape, or would they all concentrate in one place? How are their activities tied to particular places, and what sorts of places would they (re)invent for themselves if their activities were less tethered to anachronistic computers?