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
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.
Purchase Orders are the flip side of Customer Orders.
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.
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.
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.
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:
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.
"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."
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 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.
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.
Giving and taking Resources between two or more Economic Agents representing two Parties.
Transforming input Resources into output Resources.
If one wants to implement traditional Orders, Stock Flows are Line Items. But Stock Flows can also represent dependent demands, with no Orders required.
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.
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: