Simulate a Smile

Were past the stage of ITs evolution where people come to a computer in the manner that they pick up a power tool, having a specific task in mind and probably some training in how to do it. The fastest-growing model of computing today, with no end to the trend in sight, is one of systems that seek to recognize a situation or an opportunity to be of service—whether were talking about a process-to-human or a process-to-process relationship.

When this service-based model meets the real-world environment, system builders will find that their task is much more complicated than it seems when theyre crafting a scripted technology demonstration.

A vivid example of the challenge is in voice-synthesis notifications for active environments—for example, those that try to assist the driver of a car. This merely begins with the challenge of meeting rising expectations for a natural-sounding voice that correctly pronounces same-spelled words: for example, “close” (“you are close to an object behind you”) and “close” (“please close the trunk lid before driving”). Navigation systems must also deal with database entries that were meant to be read by a person, not spoken by a machine: A now-ancient Digital Equipment Corp. demo showed an algorithm correctly inferring from context to pronounce the text string “St. James St.” as “Saint James Street.”

Problems like the ones that Ive just described can be solved by experts in speech synthesis who dont know anything about the task environment of driving. Other domains also pose distinctive technical challenges that may seem to represent the crucial problems to be solved—but it may turn out that those milestones, once reached, arent enough to yield a useful result.

Additional perspective is needed to prioritize tasks: in the automotive case, for example, so that warnings about what might be a child playing behind a car thats in reverse are issued more immediately and with greater urgency than warnings of traffic problems or routine service reminders. Allocation of processor cycles, sensor network bandwidth and “air time” on the driver cockpit audio channel all depend on task knowledge and the provision of scalable infrastructure to provide any needed “mother ship” support.

Developers crafting service-oriented architectures for enterprise IT operations should also have this kind of perspective. They need to maintain a big picture of the resources that theyre allocating themselves and also the resources that theyre consuming. They need to consider the manner in which services should best be prioritized by urgency, and enabled to communicate with each other and with the user based on task-related models of what will happen if a request is not fulfilled or a piece of information is not delivered.

Its one thing to build a system thats impressive when its working as planned. Its quite another to build one thats not ridiculous, or worse, when its best-case assumptions arent valid.

Tell me what youd call good service at peter_coffee@ziffdavis.com.

Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.