A Business System Deals with Humans and Applications

When an application designer/developer builds an application, he or she "bakes in" a certain amount of semantic knowledge. When the designer/developer decides to have a field in the inventory system to maintain average cost per item, we say that the application now has this semantic. Users of this system don't get the opportunity to redefine this. They communicate with other users through the application at this level of granularity.

This is self-evident. However, there are four distinct arrangements that each have different implications for semantics. The key distinction is whether (really to what degree) the semantics are maintained or interpreted by which player (the human or the application).

Semantic origination refers to the case in which either the human or an application system is aware of the semantics of messages it produces.

Semantic interpretation means that the recipient human or application is semantically interpreting the message being sent (Figure 3.2).

Figure 3.2: Semantic interpretation and origination.

Primary Semantic Flow

This gives us four primary semantic flows: human to human (H2H), human to application (H2A), application to human (A2H), and application to application (A2A).

Consider the case where, as in Figure 3.3, the message and the semantic meaning of the message are not traveling together. This occurs whenever context or some form of agreed and implied labeling of the message is needed to understand what the message means. When someone says "200 at 22" we don't know whether this means 200 shares of a particular stock at $22 per share, 200 people in room 22, or any of hundreds of other potential explanations.

Figure 3.3: Message and meaning.

Substituting either end of the communication illustrated in Figure 3.3 with humans and applications gives us the four types of interaction shown in Figure 3.2.

H2H

Our most flexible business systems involve human semantic interpretation at both ends. We won't refer to normal face-to-face communication here because there is no capital investment in the transmission of the message or the semantics.

• Telephone—A telephone is a classic and extreme example of this. The telephone system does not interpret any of the conversation being held on it. It is simple to deploy because it relies on the humans working out what they mean to complete a transaction.

• Email—Email is another classic H2H system. The email system knows nothing of the messages passing back and forth.

• Office productivity—The same is true of word processing and spreadsheets. It should be apparent by now that word processing is widely used in part because it has left the issue of semantic interpretation to the users. Although spreadsheets appear to have more rigor, very few enforce a semantic on the user. (This, by the way, is part of the reason why a study found that approximately 30% of the spreadsheets [in a sample] that were being used in business contained errors.) The alignment of data into columns and the choice of which cells to total and which factor to use in multiplying are strictly determined by the author of the spreadsheet; the spreadsheet itself has no semantic knowledge beyond knowing the difference between a number, text, and a date.

A2H

Application to human means the application has a semantic model of the messages to be communicated and that the intended recipient is a human who will interpret them.

• Flight monitors—Airline arrival and departure monitors at airports are a good example of an A2H system. The application has a strict semantic to the information contained in its database. The semantic is well enforced (you never see data in the wrong column, or invalid data where it could have been prevented). The application knows if a flight is late (it has a semantic definition of "late"—basically a revised estimated time of arrival later than the planned arrival time, or an estimated arrival time earlier than the current time, and no notification of arrival) and will mark it appropriately.

• Reports—A report of the state of a database, whether it is graphic or not, is an application, usually with a precise semantic meaning, that moves from the application to the human, for a human's interpretation.

• Imaging—Computer-aided design (CAD) systems and systems to create images for entertainment, such as Pixar, are A2H systems, because there is no real interaction on the human's part.

• Content Web sites—A Web site that is primarily structured content (e.g., a stock portfolio tracker) has a semantic meaning that it displays for the user (20-minute delayed stock price in the second column, annualized gain in the third column, etc.). However, it imposes nothing on the user's interpretation and interaction with it.

The airline monitor is an extreme example. What makes it extreme is that its placement and the current time are sufficient to imply what you would normally enter as parameters.

The more normal case (Web sites, reporting systems, etc.) is that you enter data or navigate to get to some subset of a vast database to find information.

One of the many implications is that the data you enter as parameters to your query are not meant to be saved. These data are not like transaction data, which you typically expect to be saved to a database; the data you enter are meant to advance you from one point to another or to narrow down the data you are viewing. This is true even if the data are entered on a form, which by its appearance might normally be used to make data persistent. (Interestingly, the current explosion in data storage volume is largely coming from capturing navigational data that was previously not captured—click stream analysis, for instance).

H2A

Human-to-application systems take potentially unstructured data from the world of the human and "massage" it to comply with the semantics of an application that is on the receiving end.

• Card punch—The clearest and most extreme example is card punching. In the early days of data processing the primary input mechanism was punched cards. But you couldn't put just anything on the punched card; you had to enter information in exactly the columns the system expected, using the coding scheme the system used. Typically this was a two- to three-person job. One person might interpret what had happened in the world (what the customer ordered, or how many hours the employee worked on a given day). This person typically had the job of converting this information into a rigid format and converting it to the appropriate codes (1 for straight time, 2 for overtime, 3 for shift differential, 4 for holiday double overtime, etc.). The second person had the job of punching (typing) this information onto the cards (one transaction per card). Often a third person was involved to do the second person's job a second time to make sure the errors introduced at this stage were minimal. The cards were then submitted to the computer, which interpreted each one based on a program. The computer determined which cards were valid and would be allowed to be processed and which cards were invalid and would be rejected. It should be apparent that the program is the final arbitrator of semantics of this system, and it will impose itself on the inbound side of the transaction.

• Data entry—The system needn't rely on off-line data entry to be an H2A system. Any system that is predominated by human data entry is primarily an H2A system.

• Form-oriented systems—Most applications that have been deployed over the last 20 years have been dominated by their form-based data entry screens. This has been such a popular interface metaphor that it is used even when the system is displaying information that it already has stored. The aspect that makes it most obvious that the system is imposing semantics on the human is in the area of "constrained choice"—for example, when a drop-down list requires you to select from one of the system's choices, the system has imposed its semantics on your interpretation of whatever you are recording.

The implication of H2A systems is that what you have entered is stored and may later be retrieved. Further, some validation is done when information is entered, so there must be an error detection and correction procedure. The stricter and more consistent the validation, the more you can rely on the integrity of the system.

H2A2H

Most traditional applications (e.g., client/server) are a combination of H2A (the data entry part) and A2H (the information that comes back on queries or reports or the display of entity information that is already stored). I call this an H2A2H application, as shown in Figure 3.4.

Figure 3.4: Application types based on their interactions.

• "Green screens"—Green screens were the original H2A2H applications. For most of the last 30 years we've been overlaying H2A and A2H systems in the same user interface. Starting with most of the mainframe on-line terminals (3270 and the like), there was typically an input form on the screen. If you wanted information about a record that was already there, the system brought up a similar (often identical) form with the data already populated.

• Client/server—When interactive graphic systems became available, most of them continued the form-oriented interface, similar to the 3270, but with nicer graphics and mouse control.

• Model/view/controller (MVC)—With the advent of object-oriented development came a new slate of patterns and paradigms. The MVC paradigm recognized the separation of the model (the semantic content of the system) from the view (the A2H presentation) from the controller (the H2A portion where the user could change the state of the model). However, the generally accepted practice was to overlay the view and the controller to give the user the illusion of direct manipulation of the model.

A2A

In an application-to-application system, the semantics are known by each of the applications and little or no human intervention is needed to get them to communicate.

Of course, humans set up the semantic structure so that the applications can communicate, but at run time there is generally little or no need for humans to semantically interpret the messages. The four main A2A strategies are shared databases, systems integration, electronic data interchange, and messaging.

• Shared databases—One of the most popular ways to have two applications communicate is to have them share all or part of a database. Rather than have explicit messages traveling between the applications, each application waits until it needs information and reads the appropriate database record. This is perhaps the simplest way for two applications to communicate and has led to ever larger combinations of applications, to the point where they become unwieldy to implement or maintain.

• Systems integration—Systems integration is a general category and in some respects is an industry in itself. For our purposes it is the art of interfacing two applications by constructing custom programs that read data from one system, reformat it, and write it to another. There are many technologies for this, but they all share the problem of linking the interface program with the semantics of both systems with which it communicates. As a result, any change to either system not only potentially affects the interface, it may invalidate the message transmission entirely.

• Electronic data interchange (EDI)—In many industries electronic data interchange (EDI) has become a common way for two applications to communicate. (Generally EDI is used only for applications that are not owned by the same organization, because the overhead is usually greater than the effort to do something else, such as shared databases or systems integration.) With EDI the message is unintelligible without the spec. The message is typically a string of characters and numeric fields separated by delimiters or of fixed length. The spec supplies all the semantics for the message. The specs go through a long review period and are published for conforming members. In effect, the semantics are defined by a consortium and are generally rigid.

• Message-based systems—In message-based systems, some of the semantics are carried in the content of the message body. XML is the best known and most popular example of this. Each field in an XML message is enclosed in a pair of tagged delimiters. The tags in turn are defined in a reachable location (either in the header of the message or at a reachable site on the Internet). Currently most of the XML standard messages are defined by consortia and are relatively rigid, but recent developments have created the potential for semantic discovery and bootstrapping (discussed later in this book).

Combining A2A with H2A and A2H

Until now the world of A2A communication has been completely separate from the H2A2H world. Developers built user interfaces for their applications and systems integrators built interfaces between applications, and never the twain shall meet.

With the advent of XML it is now potentially feasible for humans and applications to begin sharing message definition. A well-crafted A2A message can be wrapped for human consumption.