Business Object Component Workshop VI: Enterprise Application Integration

REA, a semantic model for Internet supply chain collaboration

by Robert Haugen, CTO, Logistical Software LLC
and William E. McCarthy, Arthur Andersen Alumni Professor, Michigan State University

1/21/2000

Table of Contents

Introduction

We need languages for expressing the relationships between different sorts of data: a "semantic Web" which will let all the data be seen as one big database. The semantic Web will be revolutionary for ecommerce.
--Tim Berners-Lee (Source)
    This paper will argue that REA is the appropriate model for creating a semantic Web for Internet supply chain collaboration, because:
  • supply chain collaboration requires a standard semantic model that all trading partners can use;
  • to achieve Tim Berners-Lee's vision (in other words, so that anybody can do business with anybody anywhere), the model must be a generally-recognized, non-proprietary Internet standard;
  • the model must be broad (covering the whole supply chain) and deep (covering all relevant business activities);
  • REA is the broadest and deepest currently available semantic model for supply chain collaboration;
  • and REA is non-proprietary, in the public domain, open for developing into an Internet standard.

Definitions

REA refers to the Resource-Event-Agent business model developed by Professor William E. McCarthy. REA was originally designed for accounting. Robert Haugen collaborated with McCarthy to extend REA for supply chain management. The key extension was the Dependent Demand relationship as defined by MRP systems.

As a semantic Web, REA can link economic events together across different companies, industries, and nations. The links are activity-to-activity or agent-to-agent or person-to-person, not just company-to-company. This means each individual in a REA supply chain can be linked directly to each other individual. We'll see below how these direct links make supply chain collaboration faster and more effective.

REA is a minimal model. Professor McCarthy and his colleagues have spent years distilling business relationships down to the smallest set of objects required to do the job. Other data may well be required in particular industries or situations, which the REA model permits, but there is no extra baggage to get in the way. For example, Purchase Orders may be used, but are not needed. Alternatively, other control mechanisms such as blanket releases or electronic Kanbans may be substituted without changing the basic REA model.

It is easier to adapt a minimal model which provides for extensions, than a complicated model with assumptions that do not fit particular situations. The difference has been experienced in costly projects to work around traditional purchasing software in fast-moving supply chains (for example retail Quick Response projects).

By "supply chain" we mean all of the activities involved in satisfying an end-user demand for a product. That includes manufacturing, distribution, transportation and retailing. Some of the significance of supply chain collaboration can be seen in the current problems with order fulfillment in consumer ecommerce. However, the full significance will be seen as manufacturing is brought into the Web in make-to-order environments. Dell and Ford are examples of individual companies that are integrating their component suppliers via the Internet. These private initiatives are important, but the full benefits will come from a public standardized semantic Web.

(Some authors use "supply chain" to mean manufacturing procurement and "demand chain" to mean distribution and retail. This paper uses "supply chain" for all of the above.

Other related phrases include "value chain" or "value system". The "value system" concept of Michael Porter is close to what we mean here by "supply chain".)

By "semantic model" we mean a computer software model of real-world supply chain activities. Another term for semantic model from the field of knowledge representation is "ontology": the set of classes, relationships, and functions in a universe of discourse.

We use the term "semantic model" to differentiate from something like XML, the eXtensible Markup Language, which is often touted as the language of the semantic Web. XML is just a format; it has no content. A semantic model describes the content of the semantic Web: that is, what classes of objects, relationships, and functions are involved in supply chain collaboration. The REA semantic model can be expressed in many formats: XML, UML (the Universal Modeling Language), a relational database, and/or an object-oriented programming language. Using XML as the lingua franca, any REA-based system should be able to interoperate with any other REA-based system, because they understand business objects and events in the same way.

We use the word "Web" to mean that each activity in an REA supply chain is linked together, similarly to the way that documents are hyperlinked together in the World Wide Web. Individual participants need to be able to track events beyond their own activities: for example, manufacturers can plan better if they are notified about retail point-of-sale events affecting their products. Like a spider web, events in one activity may have ripple effects on other linked activities.

Motivation

As a computer network that interconnects an increasing proportion of the businesses of the world, the Internet makes possible new ways of doing business. The new ways are much speedier than the old, as the concept of "Internet years" illustrates.

The existence of the internet changes everything. None of our existing enterprise software is a fit platform, for dialogue with the other enterprises in our market space, even with the additional help from hubs and portals.
--Todd Boyle, General Ledger Dialtone

The old ways, of paper documents or their electronic equivalents, are too slow to keep up with the accelerated pace of the most-wired businesses. Yet most Internet business applications are still based on the same old paper documents.

At the Graphic Communications Association's (GCA's) executive conference last year, Gerry Galewski, a philosopher on information technologies, gave a provocative explanation on why it often takes years to truly appreciate the full potential of new technology:

"Now let's look at how we do business in the 1990s. In the 30s and 40s and 50s and 60s professional managers defined the common business processes that we use to this day. Then computers and networks were developed. And we set out to take advantage of this new technology and automate our processes, and naturally we did that based on a cultural context. Therefore we called this new capability 'Electronic Document Interchange.'

"But the underlying document model driving the process stayed the same. We called it 'Paperless ordering,' or 'Paperless invoicing,' yet the fundamental process flow stayed the same. Even though it enabled entirely different business methods such as 'just in time inventory,' we still had not reached that next fundamental level of understanding. This is now changing. Eureka events have taken place.

"The existence of the Internet has created the ability to re-invent the way that we fundamentally do business to make us all more interconnected, closer in time and space, with less manual work, our processes more timely, and our operations more and more streamlined." Source

Business deals on the Internet can be "hyperlinked" (speaking metaphorically) like Web pages. These "hyperlinks" are formed by the chains of transactions that animate supply chains. They are traversed by business messages, not people.

The REA business model contains an object called a Stock Flow that is the equivalent of a hyperchannel for business messages. REA Stock Flows can connect all of the activities in a multi-company supply chain in one simple and uniform way: one end of a Stock Flow "hyperlinks" to the previous activity, the other end "hyperlinks" to the next activity.

(If the metaphorical use of "hyperlink" seems too strained for you, think "link for business messages" instead.)

See How does REA work below for more details.

Alternative models for supply chains

There are several existing software models that have been proposed for supply chain management:

  • ERP, or Enterprise Resource Planning, as exemplified by SAP, BAAN, PeopleSoft, etc.
  • EDI, or Electronic Data Interchange, a set of standards for passing electronic versions of paper documents between companies.
  • XML-EDI, or using the eXtensible Markup Language for to represent EDI transactions, as exemplified by XML-EDI
  • XML for B2B ecommerce, or various initiatives to develop XML standards for ecommerce that are not explicitly based on EDI standards, including eCo, RosettaNet, and BizTalk.
  • APS, or Advanced Planning and Scheduling systems, as exemplified by i2.
  • Trading Hubs, as exemplified by Ariba, and Commerce One's Market Site.
  • EAI, or Enterprise Application Integration software, as exemplified by CrossWorlds, Extricity, and Vitria.

REA is not exactly in competition with any of the above. An REA semantic model could be implemented using XML or an EAI scripting language. REA could use XML-EDI for transactions. An REA semantic Web could be used to interconnect ERP systems.

But the REA supply chain model lives at a higher semantic level: that of the whole supply chain, across enterprises, including all resources, events and agents and the relationships between them. That is the level required for a semantic Web for supply chain collaboration.

How is a supply chain different from an enterprise system?

An enterprise system (such as ERP) is a system for a single company, attempting to integrate most of the business activities within that company.

A supply chain almost always spans across multiple companies, but involves only a relatively few people and resources within each company.

One enterprise may be involved in many supply chains, for different product lines or different markets for the same product line.

A supply chain is much like a river system with raw materials at the headwaters and customers at the delta, with products floating down the river toward the customers.

A supply chain system is a computer network connecting all of the people along the river.

A supply chain semantic model is a model of the information flows that accompany the real-world supply chain material flows: the demand flows, the material movements, the process activities, and the cash flows.

What’s wrong with ERP+EDI as a supply chain model?

A supply chain semantic model should look like a supply chain, not a single company. ERP systems do not actually have any model of a supply chain, nor does EDI, nor do the two of them together.

To use ERP as a semantic model is to break up the supply chain into a network of individual companies, whereas the real supply chain is a network of individual people within the companies.

This is a big difference: it can take many complex steps for information to get from the gateway of a company to an individual within the company. If the individual is in customer service, and EDI is a daily batch job, it may take only one day. If the individual is in manufacturing, it can take several days. If the individual is in a different company (for example a component supplier), the time multiplies. Each company boundary is a hindrance to the supply chain information flow.

To use ERP+EDI as a semantic model for a supply chain involving manufacturing, the demand flow would go like this:

Purchase Order -> EDI -> Customer Order -> Master Production Scheduling (MPS) -> Material Requirements Planning (MRP) -> Capacity Requirements Planning (CRP) -> Work Order -> Purchase Order -> EDI -> Customer Order etc.

Or, in acronym form:

PO->EDI->CO->MPS->MRP->CRP->WO->PO->EDI->CO etc.

This is not a simple linear flow. MPS, MRP and CRP are usually batch computer jobs that run at night. Often they must be reiterated several times before a stable production schedule is achieved. Likewise EDI is often run as a daily batch process.

That means a single demand signal can take days to go from EDI input to production in a single manufacturing plant.

It means a single demand signal can take weeks to travel across a multi-plant supply chain, even if the multiple plants belong to the same company.

Moreover, order changes go through the same tedious process. And there is no way in the ERP-EDI information flow for upstream schedule problems to travel downstream. For example, a raw material supplier’s inability to meet a delivery schedule could have severe ripple effects on order fulfillment to the end customer. Those ripple effects cannot be transmitted through the ERP-EDI information flow.

The ERP-EDI information flow cannot possibly keep up with the actual events in the real-world supply chain. The information lag can be days or even weeks, not just minutes or hours.

Jac Nasser, Ford's CEO, reports in ComputerWorld that "to process orders through the network of suppliers… can take a month or more in some cases now."

Besides slowness, ERP systems are proprietary. Whereas their internal semantic models are similar, especially if they come from an MRP background, they are certainly not identical or easily inter-operable.

Where is ERP going?

To be fair, there are several indications that ERP systems are evolving past their current model:

  • Each of the leading ERP vendors has either purchased or partnered with an APS vendor, and is swiftly developing Internet versions of their supply chain offerings.
  • PeopleSoft bought Red Pepper, and indicated at one time that they would build their supply chain software on top of Red Pepper's APS system. (However, thereafter the president of Red Pepper, Monte Zweben, left PeopleSoft; PeopleSoft has purchased other APS vendors; and the rest of their system appears to be order-based.)
  • Oracle announced support for a Demand Flow model, which is compatible with REA and much better suited to Internet collaboration than the MRPII model. http://www.oracle.com/applications/manufacturing/
  • SAP broke off a relationship with i2 and then announced that they would build their own supply chain software based on components from ILOG that are compatible with REA.
  • BAAN bought Berclain, an APS vendor whose internal model is compatible with REA, and may be using the Berclain model as the basis for their Internet supply chain offerings. Incidentally, BAAN has always been a little different internally from the other leading ERP systems: while the others were built on top of an MRPII core, BAAN was developed from a project management system.

The APS and Demand Flow models are a lot like REA without the cash flow side. (See Eli Goldratt's Haystack Syndrome for published details of one very REA-like APS model that was a precursor to i2.) To the extent that the ERP vendors evolve in this direction, their systems will become more like REA (or at least they will become more capable of Internet supply chain collaboration).

However, unless they adopt a non-proprietary Internet standard semantic model, they will still not achieve Tim Berners-Lee's vision of revolutionized ecommerce. The Open Application Group is an attempt of the various ERP companies to move toward a non-proprietary standard for application integration, somewhat like a standard set of EAI interfaces. However, the OAG standards assume a generic ERP model, not a multi-company supply chain model. They may be useful to connect existing ERP systems to a cross-company semantic Web, but they are not capable of being the semantic Web themselves. (This is not to denigrate OAG: they did what they set out to do - develop open interfaces - and an REA semantic Web will certainly want to use them.)

APS is better, but not good enough

Advanced Planning and Scheduling systems were designed to compensate for the weakness in schedule speed and precision of ERP systems. They are usually add-ons to ERP systems. Although most ERP companies have now purchased APS systems, they are still add-ons.

Lately, APS systems such as i2 have graduated to the supply chain management arena, attempting to use their considerable scheduling skills across the whole supply network.

APS systems can keep up with the flow of events inside a single company. But like ERP systems, they too are essentially single-company systems. Even if all supply chain partners adopted the same APS software, they would still be running separate systems with some kind of EDI-like gateway between them.

Moreover, APS systems are proprietary. Their vendors usually provide interfaces to selected ERP systems, but seldom to another APS system.

Also, APS systems, coming from a focus on capacity scheduling, tend to be weaker on material planning than the MRP module of an ERP system. And they usually have no process execution or cash flow management capabilities. So they are usually still dependent on a legacy ERP system for critical supply chain functions.

EAI is better yet, but…

Enterprise Application Integration systems like Vitria have a cross-company messaging component that can keep up with the actual events of the real-world supply chain.

But EAI systems are still usually lacking some of the key features of an REA model:

  • Because their focus is to integrate other applications, they do not do very much themselves, delegating actions to the separate sub-applications that they connect.
  • The level of integration may be little more than passing information from one sub-application to another.
  • They may not understand the relationships between supply chain objects like material flows and cash flows.
  • Their idea of a supply chain model may still be designed for a single company, with messages going from one company gateway to another. Thus, they are still subject to getting bogged down in the ERP system. (One exception to this problem is Extricity, which has an explicit multi-company software model.)

Most EAI systems provide a scripting language and a scriptable object model, so it would be possible to create an REA supply chain model using the EAI system. However, once again, the EAI scriptable object models are proprietary.

Trading Hubs?

The problem with trading hubs was described by Walid Mougayar in a recent Business 2.0 article entitled "Open Market Misnomer":

Internet pundits long have preached a vision in which all online businesses and marketplaces enjoy interoperable connectivity and spontaneous brokering of electronic services among dozens of far-flung companies.

But this dream may remain only a dream because the top two forms of business-to-business commerce models both exhibit classic private club characteristics: By invitation only.

...Assume you are a production goods supplier to one of the top B-to-B companies - Dell Computer, Cisco Systems, or Intel. The way you electronically connect to each company is radically different. From product catalog searching to inventory status inquiries or order management, each company demands adherence to its own set of ebusiness methods and technologies. It is agony for the supplier that has to deal with three different integration processes, some requiring changes in internal practices or costly human intervention.

...Trading hubs such as Ariba's Ariba Network and Commerce One's MarketSite.net are emerging as another popular B-to-B model. They have the potential to be the cutting edge of ecommerce, but they currently are costly and require proprietary linkages, practices similar to restricted clubs with private access and participation.

The fast-growing electronic trading marketplaces are also riddled with rigid rules of participation and operation. That's what makes them efficient. On the other hand, they seem to have attracted only the elite of ecommerce participants, and that's detrimental to the evolution of healthy marketplaces. The result is a private network of companies - which sounds like old-style electronic data-interchange networks. Most walk-ins would probably fail the entrance exam.
--Walid Mougayar Source

Walid Mougayar's perceptive analysis contrasts with the cheerleading going on in most other current B2B writings, for example BusinessWeek. If Ford and GM use two different B2B systems - as BusinessWeek uncritically exclaims - what does Bosch do, who supplies both of them and Toyota, Nissan and Daimler-Chrysler as well?

How about XML-EDI, eCO, RosettaNet, etc?

Each of these groups represents an attempt to develop a non-proprietary Internet standard for business-to-business ecommerce. To that extent, they are moving in the right direction.

However, none of these initiatives has a semantic supply chain model with anywhere near the breadth and depth of REA.

All of these Internet B2B e-commerce "standards" have focused on purchasing (in other words, Exchanges in the REA model (see below)). But there is a lot more to the world than purchasing: there is also manufacturing, and transportation, and all of the links between all of the processes in the supply chain.

Purchasing is a point-to-point relationship between two companies, and it cannot give an overview of a supply chain. The action is in the whole supply chain, not just two isolated points.

Some of these initiatives (for instance eCo) have richer models that could easily accommodate an REA supply chain model. The proposal for REA standardization below recommends building an REA-XML model on top of one or more of these initiatives. Of course, it would be easier if there weren't so many of these "standards"...

REA is the best

REA is the best model for Internet supply chain collaboration because:

  • REA is a public-domain, non-proprietary model - anyone may use it without restriction;
  • REA models can cover whole supply chains across multiple companies;
  • the REA model handles all kinds of activities - manufacturing, transportation, purchasing, etc., and all of the links between activities - in a uniform way;
  • an REA semantic Web can maintain persistent links across all activities in a multi-company supply chain until the chain's work is done;
  • the REA model handles all resources – products, cash, labor, machines – in a consistent way;
  • an Internet-hosted REA supply chain model can communicate information across multiple companies in any direction in seconds, not days or weeks;
  • because events are REA’s middle name, an REA supply chain model readily accomodates an event-driven business system (see REA supply chain in action below);
  • the REA model has been validated for correctness by peer review in the leading accounting journals, and accounting is among the most meticulous of business professions;
  • the REA model accommodates continuous updates of accounting and performance reports of any kind, as in Cisco Corporation’s "virtual closing" where business managers can get instant business overviews that drill down to details;
  • an REA model can encapsulate other business models and use them as subsidiary components;
  • an REA semantic Web would not need to be developed all at once, in an impossible engineering feat – it can be developed by piecemeal growth, as long as a core standard is preserved;
  • an REA supply chain model can either work well with other systems, like EAI, or it can grow into the whole business system on its own, for a seamless combination of supply chain and enterprise systems;
  • an REA model can perform planning functions like MRP and APS itself, or it can delegate these functions to other systems.

How does REA work?

REA works by give and take. Remember the acronym: Resources, Events and Agents. In an economic Event, an economic Agent gives one economic Resource (for example, a product) and takes in return a different economic Resource (for example, cash).

In an REA economic exchange between two companies, the Supplier agent gives a product, which is taken by the Customer agent. In return, the Customer agent gives cash, which is taken by the Supplier agent.

In an REA production process, components, labor and machine time, energy, etc. are given (consumed, input) , and completed products are taken (produced, output) in return.

REA activities are either Exchanges, which trade Resources between Agents; or Processes, which consume input Resources and produce output Resources.

REA activities are connected by Stock Flows, which represent one Resource moving from one activity to the next.

In planning, one Stock Flow represents one dependent demand or one line item if you want to think in terms of orders.

By means of these simple components, REA can represent any business process. You can put orders on top of REA (Exchanges = purchase and customer order line items, Processes = work orders) but REA does not require orders. REA was designed for computer-to-computer communication – not to mimic paper systems.

There is a lot more to making a whole system out of REA components, but the basic components are very simple – a lot simpler than ERP systems. Which means that REA software can also be simpler to develop and implement.

Also, because all REA activities are uniform and connected by Stock Flows, information flows can be fast and simple.

Remember the ERP information flow?

PO->EDI->CO->MPS->MRP->CRP->WO->PO->EDI->CO etc.

The REA information flow is much simpler:

Process->Stock Flow->Exchange->Stock Flow->Process etc. across multiple companies.

Or, in acronym form:

P->F->X->F->P etc.

Each Event on an REA supply chain knows what other events it is connected to, via the Stock Flows.

Changes, such as demand or schedule changes, can ripple across the Flows to all affected Agents.

Each Stock Flow has one or more roles for Agents.

The Responsible Agent is responsible for handling Events that require human judgment. In an Internet-hosted REA network, these Events would arrive at the Agent’s ToDo List with a set of Feasible Actions that could be selected by a mouse click.

Each Agent can be accountable to superior Agents, giving an organizational structure. The superior Agents may be notified of subordinate activities that they wish to monitor. A Superior Agent can have a near-real-time overview of all business events in her span of control.

REA Processes can be nested: for example, one Process at the supply chain level can expand into all of the activities in a manufacturing plant at a lower level. This process-nesting allows each level of an REA supply network to be relatively small, but contain all the required detail at lower levels by dividing and conquering.

An REA supply chain in action

Logistical Software LLC was formed to develop Internet supply chain software based on the REA model. Here are some screen shots from Logistical’s Supply Chain Action Network.

First is the Business Model. The model depicted is for a computer supply chain.

There are two main sections to the model: Agents (called Parties in this model) and Resources. Only Product resources are shown here. The Party section of the model has more hidden detail in the form of an organization chart with positions and employees.

The Resource section also contains the business model for Processes and their input and output Stock Flows. Note that the business model contains multiple companies, and the process flows span all of the companies.

 

Interactions between the participants in the supply chain is very simple: each party works off an Internet ToDo List. Because REA is an event-driven system, users mostly just respond to business events. Rules can be set up to handle some events automatically. Other events are put on ToDo Lists for human judgment.

The different ToDo Lists are connected by REA Stock Flows on which dependent demands and other business transactions travel, for example:

Here we see the ToDo List for the OEM supply chain planner. There is one unsatisfied demand to deal with. This business event came to the OEM planner automatically, over an REA Stock Flow link from another process.

The OEM planner takes action, planning a supply process for the required PCs. No orders are needed.

When the Submit button is clicked, dependent demands will be instantly propagated to the next agents in the chain.

Here a dependent demand for motherboards to be assembled shows up on the Contract Electronics Manufacturer’s ToDo List. When the CEM takes action, more dependent demands will be sent to the next agents, etc. Rules can be set up to propagate transactions automatically where human judgment is not needed, bypassing ToDo Lists altogether.

All information flows move across companies very quickly. Changes and problem alerts move from agent to agent in the same way that demands flow. Everything is connected by REA Stock Flows in the background.

These interconnected ToDo Lists amount to a multi-company workflow system driven by business events.

But it is different from most workflow systems, which are really just document flows that route a document around until it is completed. The REA Stock Flows generate the next dependent events triggered by the current event. For example, the Motherboard demand triggers the dependent demand for the Motherboard components.

You can see more of this flow at http://www.supplychainlinks.com/

Conclusion

REA is a superior accounting model, but its popular acceptance has been held back by the conservativism of the accounting profession. (Needless to say, accountants are conservative for good reasons, among them legal constraints.)

Internet supply chain collaboration and Internet trading communities may be a more fertile field for the REA model to gain popular acceptance. The REA model is much better than any competing semantic model for multi-company supply chain collaboration. The Internet as a means of coordination is driving supply chain collaboration very quickly, but there is no accepted standardized semantic model that can actually encompass all supply chain activities. A standard, non-proprietary semantic model can make supply chain collaboration more like a public utility (the semantic Web) that businesses plug into than the current slow and expensive collaboration projects.

REA can become the semantic Web for supply chains. But it will take the concerted efforts of the REA community (and new recruits) to make it happen. This paper is intended to further that effort.

References