Assignment for week 8: Service design
The task of system design is to move from a concept to a specification that is sufficiently detailed that the technical people can take over and build it. Traditional design methodologies are cumbersome and linear, with little room for iteration or backtracking. In this course, by contrast, we want to emphasize that design is a discovery process, and that discovery takes place through iteration. Therefore we are dispensing with most of the cumbersome methodology and notation, and instead going for the underlying idea. We are also emphasizing several aspects of the design of information services that move to center stage in a world of cheap computing and ubiquitous networking, for example the way that one's information service fits into the patterns of daily life and cooperative work.
Accordingly, we asked you last week to sketch an information service that you might like to design to support collaborative work activities. We focused particularly on the data model because that's a concrete place to begin. But your work from last week is only a first iteration, and soon you will probably throw it out and start over, or at least your design will evolve considerably. Because design is a matter of reconciling diverse constraints, this week we want you to iterate the design of your information service by taking a wide variety of factors into account. This assignment will explain the factors, and we hope that in confronting them you'll be compelled to iterate your design. Work out the details of each factor in a rough way, and then see if any problems arise. And see whether you've been inspired to reconceptualize your design to make it more interesting or useful. If all goes well, the result will feel more like a discovery than a preconceived idea. You will need a consciously chosen group process that reconciles divergent thinking -- throwing out lots of ideas without promising that they make sense -- and convergent thinking -- structured work that selects the most promising options and works out their details in an exploratory way. This cycle works best if you have a lot of paper in front of you, and lots of things to write with. The resulting materials will help document your work process.
Here, then, are the factors that your information service design should take into account. Each factor comes with a list of questions. Your answers to these questions do not need to be overly precise at this point. The important thing is to have thought about them, and to have made conscious choices. You should also go for answers to the questions that are interesting, that is, that explore a potentially novel and useful region of the design space. Your presentation does not need to work its way mechanically through all of these factors. Instead, you should find the conceptual center of your design -- the unifying theme that makes sense of the design on every level -- and organize your presentation around that. Beware of excessive complexity: a good design expresses a clear concept in an easily grasped way. If your design feels like a utility belt with dozens of disparate tools then you're not doing it right. Your job is not to support every aspect of the activity. Rather, your job is to use the iterative process of design to explore a single aspect, preferably an interesting one. We have gone to great lengths in the past several weeks to develop a good vocabulary for such things; now is the time to convert that vocabulary into design.
Roles. We have banned the word "user" in this course because the roles that people play in the vicinity of any interesting information service are more differentiated than that. Potential roles include author, editor, manager, system administrator, seller, buyer, customer service representative, and the ongoing role of the system designer. In other words, your roles should sound more like job titles -- or social roles anyway -- than the generic "user". Because your information service is going to support some type of team work, "team member" is probably an important role. Do the team members all have the same role, or are their roles differentiated? Does the same team member take up different roles at different times? If so then your data model will want to make that distinction. Does your service tend to rigidify the roles, so that team members are stuck more firmly in their roles than they had been? This might be a bad idea, or it might not. Remember that we are talking about the technology of 2010, when ubiquitous networking will make it possible to invent new roles or reinvent old roles through the mediation of the network. Who would the team like to be able to reach out to? What kinds of ongoing to loosely coupled relationships would it like to be able to maintain? Perhaps the service keeps track of everyone's network of professional relationships?
Geography. Where is everyone? All in one place? Mobile? Does the service provide different modes of work depending on whether people are together or apart or whatever? If the people occupying the various roles can be spread all over the map, where should the data be stored? A great big centralized database can be convenient for administrative purposes, but it can also be slow for people who have to open a connection over an unpredictable network every time they need any item of information. You may not have the numbers you need to specify in a rational way how the data is distributed, but just thinking and mapping the geography of the activity is a good way to start on the service architecture.
Access. Who gets access to what information? Perhaps everybody who occupies a certain role gets access to certain types of information, or perhaps the service needs to differentiate among specific individuals. Concerns might include security, privacy, theft, and trade secrets. Think about a service that supports and structures a relationship with a competitor, a customer, or a subordinate. Think about the potential consequences of information getting into the wrong hands. For example, partial work products can be interpreted as evidence of bad work practices, and brainstorming notes can seem foolish out of context. Think, too, about the ways that people in various roles get access to the data. Do they subscribe to it, that is, have it continually updated on a display on their wrist or a diagram drawn on a large bit-mapped flat-panel display on their office wall? Do they have a way of specifying what data they are subscribed to in this fashion and how it is presented? Do they enter a traditional boolean search query? Do they pass it around to one another, for example in links in an electronic message? Do they call in for it on a phone or other device? Does everyone have their own particular window on the data?
Capture. You've decided what kinds of data go into your database, but who creates this data? Are the occupants of a particular role responsible for typing it in? Is it captured by an environmental sensor? By specialized devices that talk to one another over a (wireline or wireless) network? Is the data produced as a by-product of computer-mediated work activities whose deliverables are themselves part of the service's data? Does everyone have incentives to create the necessary data? What happens if the data is not created in a timely fashion, or if it gets out of date? Will data entry be an ongoing, complicated burden? Will the person who creates the entry be required to make a lot of gray-area judgement calls about the way that things (e.g., diseases, concepts, arguments, qualities, materials, tasks) should be classified? Can the data be used to control people, watch over them, or otherwise generate consequences for their lives? Can the data be used for additional purposes once the service is under way? These questions can raise real difficulties for a draft design, and send you back to reconceptualize it.
Structure. What data should be structured, and what data should not be? A traditional e-mail message, for example, includes some semi-structured data -- the header with its repertoire of distinct fields with fixed meanings and constrained formats -- and some unstructured data -- the body of the message, along with the contents of the Subject field and some other items. An eBay auction item likewise includes both structured and unstructured data. Most documents are this way, and the "document" perspective provides a valuable contrast to the "data" perspective. Of course, even the body of an e-mail message is "data" in a narrow sense: it consists of a sequence of characters from a standardized character set. Structured data can be processed in more and better ways than unstructured data, but it also imposes more constraints on whoever or whatever creates and captures it.
Actions. What actions do the various role occupants need to take? That is, what commands do they issue to the service? An eBay customer, for example, might take actions such as putting a product up for auction, placing a bid in someone else's auction, and leaving "feedback" about another customer. Likewise, everything that appears on a command menu (such as long the top edge of the Macintosh screen) is an action. Some actions are aimed at retrieving information; others constitute institutional acts like ordering a product or committing to a contract; others are part of an interaction with someone else. Just describe the activities involved in using the service and then look for the verbs whose subjects are people. Don't forget "boundary" actions such as signing on, logging off, creating an account, undoing an action, reporting an error, or destroying a record that's not needed any more.
History. Does the service maintain a history of past actions? Why? If so you will need a data model for that history. Who gets access to the history? And so on.
Interfaces. What existing services does your service exchange data with? One type of interface is the one between your service and the hardware or software platform(s) it is built upon. A database can be an interface when more than one service uses it; for example, if your service draws information from a database whose contents are generated by another service, that's an interface. Your service will also have an interface, called a device driver, to any electronic device that it interacts with -- a sensor, an actuator, any kind of input or output device, a handheld or portable device, a device that is built into a car, a cell phone, etc. Every interface will have its own data model, which will be a subset of the data model for your service as a whole.
Processes. How does the data flow? Perform a rough sketch of a hierarchical decomposition of the system, just enough to make its overall structure clear. You absolutely needn't expand your functional decomposition down to the level of individual machine instructions such as adding, storing, comparing, and printing. Understand which processes get commands (and possibly data) from people in specific roles. Understand which processes can create new records in which databases, and which processes can change old records. Understand which processes can read records from which databases. Remember that a data flow must always pass through a process: there is no such thing as a data flow directly from one database to another, or from a database to a person, or a person to a database. Give your processes common-sense names, not ones that sound technical.
Versions. List the functionality that your service provides, and ask whether the service comes in different versions. It is common, for example, to have an underpowered free version that builds up a critical mass of customers who might want to buy a feature-filled advanced version. Also, get a rough sense of the order in which features -- that is, which databases, which actions, support for which devices -- should be implemented. It is more important to get a prototype into people's hands than to spend years building a monster that nobody might want.
Other issues in information service design. Back up and think about your service as a service. What other issues arise? Will it work economically? Will enough people use it to pay back the cost of development? How can you make it more widely useful? Return to your notes from the first class where we listed a batch of issues on the board.