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


Which Business Objects?

Customers or Parties?

Purchase Orders or Stock Flows?

Should distributed business objects reproduce traditional business applications?

In other words, are we building single or multi-party systems?

August 11, 1998

© Copyright 1998 by Robert Haugen, Logistical Software LLC

Permission granted to reproduce for OOPSLA ’98 Business Object Workshop

I will use the term "business object" to include "business software component". Although I understand that different parties make different distinctions between them, they are equivalent for the purpose of this document.

Several business object/component proposals have proposed recasting traditional business applications, or business application entities, as objects or components.

Some of the ERP (Enterprise Resource Planning) system vendors (SAP, BAAN, SSA) have proposed to "componentize" their existing systems in such a way that an existing system module (e.g. Accounts Payable) becomes a "component".

Other projects (e.g the Common Business Processes of IBM’s San Francisco project) have proposed Orders as business objects (see below for a more balanced view of San Francisco).

Even Oliver Sims uses Customer as a prime example of a business object.

I understand the short-term benefits of making the new consonant with the old. I do not argue against such a tactic, where it is appropriate.

But I wish to present the case for refactoring business objects/components into smaller parts which may be recomposed into the traditional shapes if necessary, but also can take new shapes corresponding to new business practices and multi-party internet business systems (see below).

I will begin by citing some well-understood examples of business application features that want refactoring, and then suggest some ways to refactor them.

I want to make it clear that I am not the only party proposing such refactoring. Among presenters at recent OOPSLA Business Object Workshops, William McCarthy, Guido Geerts, Chris Marshall and Rine le Comte have all made similar proposals, with similar refactorings. Santanu Paul et al presented the same case for multi-party workflow systems.

I just wanted to state the general proposal as clearly as I could, separate from any particular implementation (including my own), because I had not seen such a separate statement. This separate statement is meant to include the models of all of the above luminaries, suggesting an emerging architectural style.

Refactoring wanted here:

Purchase Orders are the flip side of Customer Orders.

Everybody knows this one. Not only does the Customers Purchase Order becomes the Vendors Customer Order, but also the two application entities have exactly parallel structures and components. Accounts Payable is the flip side of Accounts Receivable. Again, the Customers Payable is the Vendors Receivable, and the business applications have parallel structures and components. Customers can be Vendors. This is a common trap of traditional business applications: when a Vendor becomes a Customer, or vice-versa, the Payable and Receivable accounts for the same business entities are not related in the business system. In a multi-company value system, the same company frequently plays both roles.

The business relationships between two companies could multiply even further (development partner, distributor, etc.), and the business system could remain clueless.

The Party pattern enunciated separately by David Hay and Martin Fowler takes care of this situation. Organizations or individuals engaged in business relationships are all Parties; the relationships are defined separately.

Customer and Vendor are Roles played by Parties. The same Party can play both Roles.
 

Silo System Syndrome This problem is also well-known: traditional business applications were developed from paper sub-ledger systems, connected only by the General Ledger.

Even in integrated ERP systems, Accounts Payable and Receivable usually do not communicate directly. Work Orders have only tenuous relationships (or no relationships) to Customer Orders and Purchase Orders, although in the real flows of products and services they are just different stations on the same line.

New systems have begun to emerge to manage the flows, often called Supply Chain Management software: for example, i2 and Manugistics. (Another telling market category name is Application Integration software: for example, Vitria and CrossRoutes.)

These systems would be better sources for distributed business objects than the traditional A/P, A/R, O/E, etc.
 

New Practices I know this section reads like a list of buzzwords, but the practices are real. I'll try to sketch a concrete example (Dell) to make it less hypeful, but to do much more would expand this paper beyond the permissible limits. Virtual organization A supply chain or value system may be composed of many companies. Moreover, the participants may change fluidly. Even if the participants at a company level remain the same, the companies may reorganize. Even if the companies don't reorganize, the individuals playing virtual-organization roles may change with every instantiation of a virtual-organization workflow.

In a virtual organization, individual companies will play a variety of roles, switching from Vendor to Customer in the same node in the same chain.

The working organization for satisfying a particular end-user demand consists of a few individuals from a few companies, assembled into a one-time organization.

For example, when I bought a computer from Dell, the one-time organization included the Dell customer service rep, assembly line and assembly crew, supply people for various components, the UPS truck and driver that delivered the computer, and some people from MasterCard who paid for it.

 

Virtual inventory

All of the inventory in a value system, regardless of location and owning company, can be viewed (profitably) as a single system. The benefits may include overall lower inventory levels in the whole system and better customer service.

For example, Dell tries to keep as little actual inventory on hand as possible.

However, the customer service rep knows at least something about what's available from their immediate suppliers. For example, he could tell me not to order a particular monitor because it would take two weeks, whereas another monitor was on hand and available in the warehouse of the local supplier.

On the other hand, Dell is not perfect, either. You may not get the same warnings if you buy online, as Jakob Nielsen learned:

I recently had to buy a new PC and tried to do so through Dell's website, following my own rule that you must live a "Web lifestyle" yourself if you want to be an Internet pundit. The Dell site had some weaknesses, but it was reasonably easy to use and allowed me to order the desired high-end machine. Three days later I received a confirmation email stating that the machine was expected to ship 6 weeks later. This was obviously not satisfactory: when you order on the Internet, Amazon.com has trained users to expect a confirmation email within a few minutes and the product within a few days, unless the website has warned them about shipping delays.

When I called up Dell, I was told that the late delivery was because my requested tape drive was out of stock. How about integrating your inventory system with your website, folks? Customers need to be told about delays and inventory problems while they are still researching their purchase online and can consider alternative options. Outcome: Dell lost a $3,035 order because their website delivered poor customer service. http://www.useit.com/alertbox/980809.html

Now, should that integration include only the inventory at Dell, or also their next tier of suppliers? Chances are the tape drive was out of stock at the supplier.

Mass customization (make-to-order) The virtues of Dell's make-to-order business model have been described at length, but here is a salient example: Compaq, which reported net income of $16 million (about 5 percent of Dell's earnings) in the first quarter on worldwide sales of $5.7 billion (nearly 50 percent more than Dell's), summarized the problem in its quarterly filing with the Securities and Exchange Commission:

"In each product cycle, we confront the risk of delays in production that could impact sales of newer products while we manage the inventory of older products and facilitate the sale of older inventory held by resellers." 

Zero working capital Dell often gets paid for the computer before it is manufactured. They probably pay suppliers after parts are used in a computer that has already been paid for.

Toys'R'Us owns almost none of the inventory on their shelves; it's mostly on consignment, only washing through their books at the cash register when it's purchased.

Dependent events Many business events are really stimulated by, and dependent on, other events.

Dependent demand is a concept introduced by Material Requirements Planning (MRP) systems in the 1960's. It means that the end-use demands are the only independent demands in a value system, and all other demands are dependent in quality, quantity and timing on those independent demands.

One implication of this idea is that Purchase and Sales Orders for dependent demands are unnecessary baggage. (In other words, most Order Entry is a waste.)

Similarly, Jeff Sutherland suggested that when a hospital patient is admitted, the diagnosis triggers many dependent requirements for tests, facilities, skills, etc.

Another example is backflushed payments for components when the end item is sold.
 

Business Objects for the new practices: I am going to use REA terminology to describe some examples of the kinds of Business Objects that I think are appropriate for fluid, networked virtual organizations. However, all of the example systems cited above have analogs to these objects, usually organized in roughly the same way.

Technically (logically?), they could all be characterized by Riné le Comte's phrase from last year's Business Object Workshop: "timed colored petri nets". Petri nets are a form of finite state machine with places, transitions and tokens. Transitions can fire when the required tokens inhabit the required places. In the schema below, Stock Flows are places, Activities are transitions, Resources are tokens, and Events move the tokens from one place to another. Colored means different types of tokens (different Resources). Timed should be obvious.

Note: these are not all of the required Business Objects - and similar refactorings could be accomplished in different ways. These are meant to illustrate the required granularity.

Economic Resource The REA model considers all economic resources as subtypes with significant shared behavior.

Product

Service

Human

Machine

Money (or financial instrument)
Economic Activity Guido Geerts's REA Activity Model (from OOPSLA'97 Business Object Workshop) contained two main subtypes:

Exchange

Giving and taking Resources between two or more Economic Agents representing two Parties.

Conversion

Transforming input Resources into output Resources.

Stock Flow In the REA model, Stock Flows connect Activities. William McCarthy and I had a long dialog about the best-factored way to merge the base REA model, which deals with actual Economic Events, with planning, which deals with Events that we expect to happen in the future. My conclusion was that Stock Flows are the proper unit of planning in an REA world.

If one wants to implement traditional Orders, Stock Flows are Line Items. But Stock Flows can also represent dependent demands, with no Orders required.

Economic Event The increase or decrease of an Economic Resource - usually related to consumption, production or change of ownership. Economic Agent The authorized representative of a Party, playing a Role in an Economic Activity. Role This concept is not explicitly stated in the REA model. I am borrowing my usage from Chris Marshall's BOMA model. In this context, the same Economic Agent or Economic Resource may play different Roles in different Economic Activities. IBM San Francisco Project (and OMG BOTF) I am using the San Francisco business object documents as an example of the layers of some business object proposals, where the Core Business Objects are pretty atomic, but then the Common Business Processes jump directly into reproducing traditional single-party business applications.

The San Francisco Core Business Objects are pretty well factored: for example, San Francisco's Business Partner (BOTF Involved Party) is certainly is better than Customer and Vendor for representing distributed value systems.

It is at the next level, of Common Business Processes, where San Francisco reverts to single-party systems.

Their Warehouse Management process does not understand that it is part of a distribution network. Its Inventory assumes a single Owner.

San Francisco Order Management at least understands that Purchase and Sales Orders are basically the same. But the Order Detail Lines are not independent. In other words, there is no consideration of dependent demand chains, where each demand takes on a life of its own in relation to its parents and children, not needing to be part of an aggregate Order and certainly not requiring Order Entry.

As I said before, I do not deny the tactical value of reproducing traditional business apps in new clothing, so this is more of a contrast with San Francisco than a criticism.

Summary Multi-party business systems are evolving on the internet: for example, internet-enabled supply chain and procurement systems. Such systems will require business objects/components that are factored differently from the traditional business applications, e.g. Order Entry, Accounts Payable and Receivable, etc.

This does not mean that the traditional business applications will go away, just that they were designed to be single-party systems and will not work well in a fluid multi-party value system.

Business objects that will work in multi-party internetworked systems will be factored into different and smaller objects - more like the REA model. Such systems are now being designed and/or delivered by several participants in recent OOPSLA Business Object Workshops, including those listed in the following references:

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