../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV


From Business Objects toward Adaptive Agents

Pam Rostal


 
Compuware Professional Services Division - Minneapolis Branch
3600 West 80th Street
Suite 400
Bloomington, MN 55431
E-mail: pmrostal@mn.uswest.net



Abstract

Considering units of work as autonomous goal-driven agents emphasizes the connection between business objects and complex adaptive systems. Assigning goals to work objects, in addition to the usual attributes, behaviors and rules, allows them to act as adaptive agents. Applying user-modifiable conditions to their actions keeps the agents’ goal-driven behavior within limits dictated by volatile consumer markets, changing corporate direction, new legislative rulings, etc.

This paper considers how complex adaptive system research might be applied when building business objects in support of a non-deterministic business environment. The sample case study involves the evolution of a traditional object-oriented application into a more flexible agent-driven system. It is a work in progress whose success cannot be evaluated at the current time, but the approach seems promising and would benefit from scrutiny by the practitioners at the workshop.


Introduction

Craig Reynolds’ classic boids experiment [REYNOLDS 87] showed that flocking behavior could be achieved without the application of external rules to the entire group of "boids." Constraining the behavior of each boid by three simple rules moved the entire group in the same direction without causing stragglers. Applying comparable logic to the business objects in an evolving enterprise might allow automation of processes previously assumed to be beyond the capabilities of a computer.

Complexity theory seems applicable to the system currently being developed where I work. The old manual process was simple:

    1. A letter or phone call was received.
    2. An employee researched the request made by the sender, documenting each required action and its result.
    3. The employee contacted the sender with the results.
    4. All paperwork was filed.
The filing at the end closed the case. The goal of all work was and continues to be getting closed. The goal of our system is to automate as much of the process as possible.

This paper deals with the automation of Step 2. What makes it interesting is that the sender may request any of a dozen or so different services, some of which require the completion of related activities before they themselves can be closed.

Background

The project began with the re-engineering of the existing process, which generated an idealized workflow for the new world. The questions that arose were:

These are the same questions confronted by artificial intelligence researchers when they attack problems involving constraint satisfaction, planning, artificial life, and adaptive agents, so the original order was for an "artificial intelligence program."

As it turned out, the first requirement was for a data capture and retrieval mechanism, which could be used to assist manual processing in the current world. The business objects were modeled jointly by the business partner and the analyst. At first, all functionality was to be delivered simultaneously, but later, it was agreed that only one of the thirteen services would be delivered in the first release, and it would not be fully automated.

The first deliverable required the creation of the application model, the domain model, the persistence model and a mechanism to allow distributed processing. Because only the simplest service request was being developed, and an employee was always involved in closing the work, there was little need for the ability to handle complex conditions for system behavior. The first release revolved around business objects with the following interfaces:

A third-party workflow program had been purchased to allow user input of business rules so that as more complex services were delivered, their behavior would remain more responsive to changes in the business environment. Because it was not used in the initial deliverable, and there was some ambiguity about exactly which responsibilities it would fulfill, the architecture evolved away from its monolithic set of workflows and business processes. Instead, each business object evolved a "lifecycle" that reflected its allowable states, the triggers that caused state changes, and the conditions under which the triggers fired.
 

Lifecycles

With the advent of the second release, analysis showed that business rules had been tucked into a variety of places, such as:

Delivery of additional functionality would only aggravate the difficulties posed by the distributed code, so the decision was made to refactor. A new interface was developed for each business object - its service interface as defined in [LECOMTE 97], governed by the object’s lifecycle.

The lifecycle is designed to be the container for all business rules, whether they are to be evaluated at the user interface or in the middle layer. It consists of two groups - a group of actions, each constrained by a set of conditions, and a group of audits that represent the object’s current state as a function of its history. The condition group can contain simple conditions or groups of conditions joined by a logical "and" or a logical "or." Each condition compares a specified property to:

Therefore, each condition has a property group of one or more properties that must be evaluated.

Each condition can evaluate to true, false or unknown (if the property cannot be found on the specified object but its evaluation is required - usually an indication that corruption has occurred).

Currently, an external object asks the business object’s lifecycle if its owner can perform a certain action. If so, the external object triggers the business object’s method. If any condition fails, it is returned as the unmet condition and the return code is its failure return code. In the next release, the command interface should be developed well enough so that the external object can specify the action and pass control to the business object for evaluation of its lifecycle and performance of the specified action. At that time, unmet conditions will trigger alternate actions so that the business object never has to return control to the outside without coming to some valid intermediate or final state.

Future plans call for the external object to specify only that the business object is ready for activation. At that time, the business object should evaluate its state, remediate any invalid conditions, and move forward into its next state.
 

Comparisons to CAS

John Holland’s example of a complex adaptive system in [HOLLAND 95] references the hustle and bustle of New York City, whose merchants service the needs of thousands of customers without any governing body specifying which merchant should sell how much of what, and during assigned hours. Each merchant has a goal of staying in business, and to do so, must meet the needs of customers. The idea of a business application automating its business objects so that each one does as much as it can before either closing itself out or putting itself to a queue for human intervention seems to parallel Holland’s model.

If each business object is capable of guiding itself toward completion, the only need for outside intervention seems to be looking for anomalies that occurred because of a system shutdown or some kind of programming error that left the object in an invalid state. If an object monitored the database for invalid states, re-instantiated the business object and activated it, the object should be able to evaluate its current state, its ultimate goal and continue processing where it left off. This is the goal of our system.

The goal seems achievable because our state space is much smaller than some of those being evaluated in artificial intelligence. The business users have specified only a small set of allowable actions and states, with minimal conditions compared to a completely autonomous robot such as the Sojourner probe. Therefore, search algorithms do not play as large a role in our planning; however, search algorithms are important in locating the property owners whose properties must be assessed during condition evaluation. In some cases, a container object has multiple items, each of which contains multiple instances of the target property owner. Finding the objects involved in these types of relationships has proven to be a challenge.

Conclusion

The mental picture evoked by Brian Arthur’s "peasants under glass," [WALDROP 92] in which a colony of programmed peasants develop their own economy under the watchful eye of their creator, coincides with my own view of our work objects forging ahead like lemmings toward their predestined end, some racing straight to the finish, others meandering through various states before their inevitable fate, and still others stopping along the way to await help from their human assistants. It should be easier to build our model because we’re supplying the rules instead of letting the work figure out how to close itself.

What kinds of emergent behavior might ensue? I would expect emergent behavior more from the physical system - resource bottlenecks, lack of available work for employees while the system is trying to clear its backlog of automated work, etc. - than from the objects themselves.

Until we implement much more of the system, we can only guess, but we’ll continue to look for clues in the annals of artificial intelligence.

References

[HOLLAND 95] Holland, John H. (1995) Hidden Order: How Adaptation Builds Complexity, Addison Wesley p. 1.

[LECOMTE 97] leComte, Ing. M. G., Business Processes and Workflow Management in an Enterprise Resource Planning Context, Business Object Workshop III Position Paper, http://jeffsutherland.org/oopsla97/lecomte.html.

[REYNOLDS 87] Reynolds, C. W. (1987) Flocks, Herds, and Schools: A Distributed Behavioral Model, in Computer Graphics, 21(4) (SIGGRAPH '87 Conference Proceedings) pages 25-34.

[WALDROP 92] Waldrop, Mitchell (1992) Complexity: The Emerging Science at the Edge of Order and Chaos, Simon and Schuster p. 243.
 

../oopsla97/OOPSLA'96OOPSLA'98 Business Object Workshop IV