Dynamic Categorization

There are other ways to model systems using more precise taxonomies, more elaborate ontologies, or object-oriented hierarchies arranged differently. But that's not how we think. We may make more semantic progress when we realize how people think, and any categories they are likely to make are going to be subject to the prototype effect; therefore we may want to embrace it, rather than work around it. Two design approaches embrace this style of dynamic categorizations: metapatterns and associative databases. In Metapattern, Context and Time in Information Models, Pieter Wisse^[19] argues that the current approach of classifying items by what class they belong to (e.g., in an Object Oriented system) is far too restrictive and suggests an approach whereby instances can morph their behavior by shifting "contexts." Each "context" is like a class, except it is dynamic and additive. Simon Williams's "The Associative Model of Data"^[20] suggests that all properties can be treated as "associations," which can vary by instance and are thereby not restricted to the properties set up in schemas or classes.

State and Status

State and status are terms that are used freely in business system development, often without giving a lot of thought to what they mean. As we'll see, they are a special case of categorization.

For many people, state means "state machine," as in "finite state machine" or "finite autonoma." The assumption with a state machine is that there are a limited number of discrete states and a countable number of transitions from one state to another. In Figure 4.9 we show a state machine for a garage door opener. In this case, because the transition between open and closed is not instantaneous, and because the interesting differences are what happens when a car or a child breaks the electric eye beam near the flow, we model "opening" and "closing" as states. This gives us some assurance that we know what is going to happen. It also lends itself to a table-driven structure—the arcs, or actions, can be entries in a state table, letting the system know what the allowable transitions are from any given point. As such, it is tempting to want to apply this to anything that appears to exhibit statelike behavior.

Figure 4.9: Garage door state machine.

People like to think that things such as purchase orders move through a similar set of discrete states. However, for use in business systems, this concept suffers from two flaws:

1. Most states in business systems are not discrete; in fact, most of the things that we want to move from state to state can be in multiple states simultaneously.

2. Most business systems do not obey the rigid constraints of a state machine when moving from state to state.

So you may start with purchase orders being statelike: They are approved, issued, partially received, completely received, and closed out. At each stage, you have a set of allowed behaviors (you can change the quantities before the purchase order has been issued, but not after; you may have some ability to cancel before it is received).

But what happens if you want to use state behavior to answer questions such as the following: Have we received an invoice for the item? Does this purchase order require additional approval? If so, by whom, and how do we know this? Where will the process stop while we're waiting for approval? Do we need a letter of credit? Have there been changes to this purchase order? Somewhere along the line you find that the purchase order can be in several states at once. You find that transitions can occur at any time, because there are humans involved (unlike with the garage door opener). So although we can restrict some choices, we can't necessarily restrict the transitions. Like prototype categories, states have fuzzy edges.

Using State as a Proxy for Behavior

We need to rethink state machines in the context of categories. This will enable us to merge some interesting concepts. Let us recap what we've just discussed:

• The state (or status) of an item is really just a shortcut for the set of behaviors that can be executed on the item.

• These behaviors are not limited to the behaviors that lead to another state.

• The item is dynamically changing its "class" over time. This is not handled well in object-oriented systems.

• As we learn more about an item, or as an item goes through a state change, we can continually challenge its membership in the category (rule in/rule out) and thereby affect its potential behavior.

Status and Roles

The term status is often used interchangeably with state, as in "What is the status of that purchase order?" The main difference is that status tends to be associated more with permanent entities (customers and vendors) whereas state tends to be used more with shorter-duration transactions. This explains why medium-duration entities, such as purchase orders and contracts, tend to have either term applied to them.

A "role" is a relationship-specific way of referring to a person or an organization. For example, a person might have the role of an employee in an organization, a patient in a hospital, or the on-call doctor at a clinic. The existence of the role sets up one kind of categorization for the entity, so there are properties we would expect of an employee (hire date, salary, etc.) that we would not expect of a patient. The role itself also runs through states, mostly independent of the individual being referred to (on leave, probation, etc.).

^[19]Pieter Wisse, Metapattern, Context and Time in Information Models, Boston: Addison-Wesley, 2001.

^[20]Simon Williams, The Associative Model of Data, Bucks, Great Britain: Lazy Software Ltd, 2000.