Position Paper by: Shalom Reich mailto:sreich@acm.org

Characterization of a Business Transaction Processing System

Based on the papers that have already been posted, it appears that there are some differences in how to define a business transaction. I will add some more fuel to the fire. A business offers a "value proposition" to its customers (and potential customers). In this context, I believe, a business transaction is some good or service (or combination) provided by the business to its customer(s) as part of this value proposition. Therefore, a Business Transaction Processing System is a system that supports a business in the delivery of its business transactions.

A business transaction may be as short as a phone call to the bank for an account balance or as long as a mortgage (from the initial mortgage application to final satisfaction being sent after the last payment) and perhaps even as long as the lifelong relationship with a bank (covering multiple accounts used for different purposes). Business transactions may have hierarchical relationships (such as the relationships between the business transaction represented by a check to the business transaction represented by a bank account).

Each type of business transaction may have multiple states before it is completed. At each stage in its lifecycle it may generate various measurements (financial or otherwise) that may be used by management/stockholders/regulators to monitor and/or control the business.

General Requirements

Long Running Transactions

The business transactions that I described above are not the traditional transactions that are handled by TP monitors such as CICS. They have a long lifetime (may even be days or years) and multiple interactions with users over their lifetime. The traditional transactions only cover a small part of the life of these transactions and multiple traditional transactions are often required in order to complete a single business transaction. Often, the traditional transactions execute in different environments and it becomes difficult to connect all of the pieces back to the original customer need that started the whole process.

I believe that a traditional transaction has approximately the same relationship to a business transaction that a method has to an object. Just as a method may transition an object from one valid state to another, a traditional transaction may transition a business transaction from one valid state to another.

Work Flow

A BTPS should have the ability to process work flows. Each state of the business transaction can be represented by a step in the work flow. Each step in the work flow may be composed of the following phases:

  1. Work Planning - The periodic process of planning for future work. This often involves review of historical work levels and/or the results of Work Plans from "upstream" processing areas that generate work for this processing area.
  2. Work Receiving and Arrival Reporting - The process of receiving and getting control over newly arrived work. This often includes notifications to processors of work awaiting processing.
  3. Work Monitoring - Review all available work, prioritization and scheduling the work to be done.
  4. Work Processing and Recording - Doing the work and recording the results of the work.
  5. Work Routing - Based on the change in state to the work, pass the work along to the next stage in the processing.
  6. Work Evaluation - On a periodic basis, analyze the work. The information from this step is often the input to the Work Planning phase (step 1 above).

The work flow component of the system should allow the rules that define sequence of steps (dependencies) and the rules that define the processing to be performed at each step to be easily modified by the users. (This process should also be a work flow.)


Accounting information is only one type of information to be collected by the work flow processing. Since internal and external financial reporting is often used to monitor and control a business, collecting this information is important. However, there are many business transactions that are not directly recorded in the financial reporting systems (i.e. the number of calls to the "banking by phone" unit that did not get through to a bank employee) that may generate useful information for internal reporting purposes.


Just as accounting records what happened after the transaction is processed, a large part of business transactions involves authorizing each transaction before the real processing is done. In my experience, these rules are changed on a fairly frequent basis as the business changes it policies. However, once the authorization step(s) is (are) completed the underlying work often does not change.

Queue Management

In order to decouple the work flow steps from one another it is usually necessary to add queues between steps. A good work flow engine should allow the users (and managers) to monitor queues in order to shift processing resources as necessary. (Mostly in Work Receiving and Arrival Reporting or Work Monitoring phases defined above.)

Difficult Problems

The work flow engine should be responsible for doing all of steps defined above except for Work Processing and Recording (phase 4 above) which is unique to each step in each business transaction. It is even possible to reuse Work Processing programs associated with authorization in multiple business transactions. However, there are three functions that look like responsibilities of the work flow engine that often require detailed knowledge of the business transactions. This breaks the encapsulation of the business transactions.

Authorization Rule Dependence on Business Transaction Data

The authorization rules often vary based on the current state (the values of some fields) of the business transaction. It is difficult to write a generic authorization processor without detailed knowledge of each business transaction.


It is often possible to route a business transaction to one of many steps depending on the results of the Work Processing in this step. The routing rules often vary based on the current state of the business transaction. It is difficult to write a generic routing engine without detailed knowledge of each business transaction.

Work Monitoring

When human beings are the business transaction processors at some point in the Work Processing they often need the ability to select work based on varying criteria (i.e. I normally want to process work in the order it was received except when I am near the end of day - when I want the "big" transactions first).


I have a BS in Computer Science (Brooklyn College) and an MBA (Stern School of Business - NYU). I have been working for 20 years in data processing, primarily with on-line systems (mostly MVS/CICS/VSAM) at financial institutions. While working at a bank several years ago, I was part of a team that designed and built a work flow system for processing various types of business transactions (primarily funds transfers and foreign exchange transactions). The work flow system had the responsibility for wrapping existing legacy systems that did the actual Work Processing. I am currently working in C++ at another financial institution.

I am interested in understanding how OO can help solve the difficult problems (breaking encapsulation) I ran across during my previous implementation.