Business Systems as Semantic Factories

People process data, turn it into information, and take action (Figure 8.1). As we saw in Chapter 7, humans interpret stimuli. This chapter examines the process of determining what to do with this information. First, though, we turn our attention to the matter of partial delegation—specifically, delegating some of this processing to a software system.

Figure 8.1: Human as information factory.

To delegate some of this "data processing" to a system, we have to build the system. Figure 8.2 is a schematic representation of this process, in which knowledge is transferred from one person to another, processed, and converted into a form that allows a machine to process it similarly. In this chapter, we look inside the box and see how this knowledge is represented, and just what that has to do with semantics. Chapter 9 takes up the issue of getting the information out of the heads of those who know and into a format that can be formalized, reasoned about, and implemented.

Figure 8.2: Partial automation of the information factory.

Traditional Business Software

Typically, what is "in the box" in a traditional business application is third-generation, procedural code. Still, as often as not, it is COBOL code, millions of lines of it.

These systems represent the "hard automation" approach to the information factory. We have all heard tales of how hard it is to make seemingly small changes to legacy systems. This is because these systems have developed the same characteristics as inflexible automation (recall from Chapter 3 the cost of change from rigid automation). However, in the case of application systems, the causes are mostly semantic in origin.

Before we dive into the business rules/flexible automation solution to these problems, let's spend a bit more time with the way things are now. We'll start with the question, "What is an application?"

What Is an Application, Really?

For 25 years I designed and built commercial and enterprise applications; in all that time, I never gave much thought to what an application was. We didn't have to. Applications were mostly bundles of functionality that vendors sold, such as "payroll," "human resources management," "shop floor control," or "enterprise resource planning." Some applications were leftover bits of functionality that didn't fit into any packaged application and therefore had to be built in-house. In most cases the boundary of what was in an application was what could be budgeted and managed. So "tool crib" might be an application, as well as "raw material stores" or "trip planning."

These boundaries are somewhat arbitrary, although guidelines and rules of thumb exist. Most applications are a coherent group of programs centered around some key entities and processes. Typically, applications that handle inventory transactions also have screens to update and report on inventory. However, these boundaries are becoming more and more arbitrary.

How Big Is an Application?

Applications have incredibly elusive boundaries. Once you've included some part of an application, it is easy to see that there are parts missing, but it is not so obvious on the front end what those missing parts are.

The smallest an application can be is large enough to perform a single type of interaction. For example, an application could capture time collection data. However, almost any application has a series of other interactions that are typically performed less often that would be greatly aided if they were also applications, and were integrated. So in the time collection example, the application is more useful if we have a structured way to create information about the person submitting the time report (i.e., employee record). That application, in turn, is augmented by information about the organization that employs the person (i.e., department record). In a similar fashion, the application needs information on the tasks or projects the person is working on.

Often the boundary of the application is extended to cover additional organization of the information. For example, a summary of time spent for the month, or time extended by billing rate, would each be additional information created by another application. (Whether it is part of "this" application, or part of some other, is an example of the arbitrariness of the boundaries.)

A second benefit to the partitioning of systems into applications is that each application has a manageable size and scope. This is discussed in more detail in Chapter 12.

The previous discussion merely restates what we currently think of as an application. If we look at applications through a semantic prism, we see that an application is a device for constructing more ordered information from less ordered information. To put it another way, it is a way to reduce information entropy. Let's explore this.

Noise

Applications exist in noisy environments. Not necessarily environments of high decibels, but environments where the orderliness of data is highly chaotic. The classic application is form-oriented software that is used by someone dealing with a customer.

Figure 8.3 shows what is still typically done in business systems. Either the randomness in the world is reduced to fields in a paper form, and then that paper form is entered and edited in a computer system, or (in the case of more modern systems) the "form-based entry" occurs directly in the system.

Figure 8.3: Business applications are form-oriented data entry.

To appreciate how the application fosters the creation of orderly data, imagine what would happen in the absence of the application. A customer might walk in and start talking about what he wants, or some experience he has had. He might blather on for minutes on end. Have you taken an order? Have you checked on availability for the product or service? Have you even found out if you sell what the customer wants to buy? No, to all of the above.

With an application, the customer walks in (or phones) and says, "I'd like to buy something," or words to that effect. The salesperson takes out a form or starts an application, requesting the customer's name and account status; if the customer doesn't have an account, one is set up. The salesperson then asks about the product and quantity desired, and information is exchanged about the price. Ideally, the customer then commits to making the purchase.

The end result is a structured and simple set of information that represents the transaction. The key to the semanticness is the degree to which the application leads the user to create the most precise, accurate, and structured representation of what just happened or what is about to happen.

Other Types of Applications

Sometimes the noise that the application deals with is not from customers or users. An application that searches through vast tracks of data to find and extract information of interest (e.g., data mining, or trend analysis) is creating more ordered information from less ordered. But the direction is the same—using programming to create order, information, and meaning from chaos.