Business Transactions and That Modeling Business.

Paul Evitts -- evitts@inforamp.net

The object oriented approach to business transactions might be said to have begun with the bean counters of ancient Mesopotamia. Their need to record the details of trades (not to mention the tax implications) led to an iconic way of storing and manipulating information that eventually evolved into writing and money.

What they were recording were two way exchanges, initially barter exchanges and then exchanges of goods for gold, silver and coinage. Control and documentation were the motivating forces behind the formalization of these exchanges.

Transactions are about business exchanges. In a 'hard' economy of real goods and real money, transactions mediate the exchange of goods for goods, goods for services etc. Paper and quasi-paper documents act as symbolic translators of things for things, creating a metaphorical common denominator. The downside: layers of intermediaries managing the documents and brokering the translations.

My experience with business transactions is as a consultant doing feasibility studies, evaluations and implementations of packaged solutions for large corporations. I'd like to offer some comments on the opportunities and problems for commercial object-oriented business transaction systems from the perspective of my experience with large organizations and some suggestions for how to think about business transactions effectively in an object-oriented fashion.

Large organizations havemany layers of intermediaries and many boundaries, both external and internal. Up until recently, the bulk of the computing they did used transactions for large volume record keeping, not (for example) as a means of allowing the business to provide more efficient and better quality service to its customers and suppliers. And very few of these businesses built their own roll-your-own transactional systems after 1980.

Traditional (non-object) transactional systems used relatively speedy processing and the ability to crunch large volumes of records as their justification, rather than providing any real added-value in the form of simplified processing or contributions to the rationalization of work and organization structures.

In fact, those characteristics which are supposed to be typical of transactional systems (large volumes, processing speed) contributed to masking the inefficiency and ineffectiveness of business operations until their increasing size and complexity led to their downfall, and in some cases may have contributed to the downfall of the businesses they served.

I worked for a major financial services company in Canada in the mid 1980's evaluating financial reporting systems. One of their older senior managers commented to me that what the proposed system would do seemed almost irrelevant, but understandable. A key feature was the ability to generate a detailed balance statement at any time, primarily to satisfy new government auditing requirements. He said that, in the early 1950s, before computerization, they (and the government) had been satisfied with the books being balanced once a year. As the speed and volume reporting capabilities improved due to computers, reporting requirements became more detailed and more frequent, without any real contribution to the bottom line or management control. The reports were more of the same that had been produced in 1950. And, he said, the effort and expense involved in responding to these increasingly heruculean requirements diverted systems management from looking at processing and reporting opportunities that could help the business compete today.

Five years later the business (one of Canada's largest of its type) essentially went bankrupt. Among the reasons cited at the time was a significant gap between its real worth and its reported worth.

The integrated transaction systems that predate client/server computing developed as a collection of monolithic stovepipe applications, interconnected by batch interfaces, inter-system feeds and reporting engines. They mirrored and ultimately contributed to the silo organizations that they served.

Up until the late 1980's, the two dominant package vendors were McCormack and Dodge and MSA. I worked on evaluations and implementations of 'solutions' from both vendors. At one point they did perhaps a half-billion dollars a year in revenue each, and seemed impregnable. By two years ago, they'd virtually disappeared, having been replaced by SAP, a client/server package vendor that has recently been reported as itself struggling to adjust to the emerging distributed business environment of 'Nets and objects.

I was and am attracted to the object metaphor, because of the way objects help solve two of the problems most apparent to me in this work, and because of the opportunity to use pattern thinking to extend the power of objects even further. This despite the fact (or maybe because of it) that I've been using an object approach to modeling businesses and processes, but almost always with a resulting implementation that did not use OO technology.

The first problem is analytical. In the structured world, the separation of processes from data and the lack of a clear analogue to 'behavior' reinforced a spaghetti approach to modeling that elevated obscurity and complexity at the expense of user understanding and analytical responsiveness.

The second problem is a design problem.

Traditional transactional systems have to translate "business" transactions into "system" transactions. The boundaries are not necessarily the same, and traditional systems add layers of complexity (in the processing and interfaces) and impose substantial simplifications (in the data structures) to resolve this disparity.

From the backrooms of my memory, I recall CICS applications that break business transactions that might span multiple dialog windows into a number of system transactions. Added to the design difficulties in maintaining transactional integrity were the conceptual difficulties in managing and mapping system transactions to business functions, not to mention such problems as identifying and managing reuse opportunities.

The first problem is the classic Analysis 101 justification for objects, so rarely observed in the trenches. Objects (especially business objects) should map to the real world and support user understanding of the requirements and the solution in a business context.

The second problem continues to be a fact of life that real world OO business transactions systems will have to be able to deal with. Legacy systems, silo systems and batch feeds remain as substantial elements of the business landscape.

An example I've encountered recently provides an example of what I'd like to see an object-oriented business transaction system support.

A manager at a client for whom I've been packaging a corporate systems development lifecycle proposed what on the surface appeared to be a simple opportunity for piloting OO business modeling. A decision had been made to buy a package to support purchasing, asset management and leasing. The package didn't provide facilities for IntraNet-based requisitions or integrate with the existing Human Resources package that maintained budgetary and capital expensive authorization levels.

The goal was to allow anyone on the corporate IntraNet to select work-related items from an Intranet-available catalog, and submit a requisition for approval which would be automatically routed (using information from Human Resources) via email to the appropriate authorizing agent (typically their immediate manager). The authorization request would have to indicate the budget exposure of the authorizing agent at time of request, but also to provide the authorizing agent with budget figures current at time of authorization.

Encumbrance processing was the key element in all of this. An encumbrance is a charge against a budget line item that is virtual until the corresponding actual invoice or bill is received. When the invoice/bill is received, the encumbered amount becomes an actual against the budget: the encumbrances for the budget line item are reduced by the invoice/bill amount and the budget line item spent total is increased by the same amount. The amount available to spend at any time (in an encumbrance based system) is the budgeted amount less (actuals plus encumbrances).

The original limited analysis of the business requirements had not used any OO techniques for modeling or analysis.

From it, we had a number of system dependency diagrams that showed information flows and the physical context diagram, and an informal list of requirements that (as usual) combined constraints, assumptions, context, and some real requirements in a glorified wish list. Encumbrance accounting and capital budget management were 'technical' requirements rather than anything clearly defined.

After developing a simple business use case, we used CRC cards to explore the business object responsibilities with the users. We discovered that there was no way to support the transactions being proposed: we had no easy way to get the budget system to tell us about goods received or invoices received. While we could feed encumbrance information to the budget system, it was only updated at regular intervals and so our budget ceilings (and authorization controls) would only be approximate at best.

Two results came out of this: a simplified (and less rigid) approach to authorizations and budget controls that fits the business better, and a better understanding of future requirements for budgeting, purchasing and asset management. But, the question remains: in a less than ideal world, how would an OO business transaction system model asynchronous, independent 'legacy' systems (such as the encumbrance processing described above) in a way that combines real user understanding of the business issues and requirements involved, while providing usable hooks for leveraging those pre-existing systems.

The example also suggests some of the larger issues involved from an analysis (rather than design) perspective that an object oriented approach should support.

In looking at business transactions, I'm concerned about notions of business transactions that narrowly reflect ways of doing business shaped by the requirements of a pre-electronic business culture. I'm also concerned about the implicit equation of transactions with documents, to be captured as objects with the same boundaries and granularity as documents.

In fact, good business transaction models based on paper-based business practices may have a negative impact. By describing transactions well and by leading to successful object implementations, they might actually impede a transition to business practices that are more appropriate for an electronically-mediated business environment.

A (non-object) example of this is illustrated by some business reengineering on procurement done at the Ford Motor Company, as described in Reengineering The Corporation by Hammer and Champy.

The traditional pattern for the procurement process is 'Matching': - the problem is making sure you're being billed for what you ordered. - the context is purchasing from a Supplier sight unseen for future delivery. The forces are: - it's necessary to ensure that the ordered goods are received given that the supplier may send the wrong goods, and - it's necessary to ensure that the Supplier's bill fits the goods ordered and received.

The traditional solution is to start by issuing a Purchase Order to a Supplier. Then, when the goods are received, they are checked against a copy of the Purchase Order line by line. When the Supplier's invoice is received, it is matched against the validated Purchase Order, in a process called three-way matching. Any discrepancies, either on the receiving dock or on the invoice, are identified and reconciled before payment is made.

Any serious financial software package automates this process to a significant degree, making possible the high-speed, high-volume processing of purchase order and invoice transactions.

According to Hammer and Champy, Ford reengineered procurement to eliminate invoices first, and are now moving to eliminate the receiving and purchase order transactions as well. The matching process, the core of the standard solution, was the cause of a significant problem: mismatched transactions, although only a small fraction of the total number of transactions, took an enormous amount of time and resources to resolve manually. The process "fostered Byzantine complexities: searches, suspense files, ticklers - enough to keep 500 or more clerks busy" (page 42). Ford decided to resolve this problem (and cut their Accounts Payable staff by as much as 95%) by paying on receipt, eliminating the final matching required with an invoice.

Now Ford is going even further at one of its truck plants, paying when it uses the goods, in this case brakes.

One brake supplier was selected to partner with Ford. The supplier shares Ford's manufacturing plans, and plans its production and delivery of brakes using the shared information. No 'exchange' of information takes place via transactions, or informally through the supplier's sales staff as before.

Transactions that automate paper documents still occur, of course - checks are cut to pay for the brakes as they are installed on Ford's trucks. But the transactions that mediated the information and documentation components of the old paper-based process have been replaced.

Hammer and Champy's description of what happened at Ford is suggestive of the kind of analysis needed in thinking about business transactions and perhaps suggestive of the potential value of applying pattern thinking.

They say that the reengineered process "breaks hard and fast rules that .... Every business has.... deeply ingrained, whether they are explicitly spelled out.." (page 42). The old rule, part of the business environment and culture, was "we pay when we receive the invoice".

As expressed in the pattern above, this rule is the core of a solution whose assumptions and reasoning were (and still are) generally invisible to business management. By providing a context and a discussion of the forces to be resolved in the processing, "Matching" enables a constructive understanding of when and why to apply the solution.

Even more interesting, though, is where the new rule comes from - a new business pattern. This new business pattern is "Partnering with Suppliers". I won't spell it out here, but it is an emerging pattern that is reshaping ways of doing business that is made possible by the new networked, disintermediated electronic business environment.

Wal-Mart has helped foment a retail revolution by openly sharing information with its suppliers, using a system called RetailLink. Wal-Mart's suppliers have access to the same information as the company's own internal buyers and financial analysts. They get direct access to its corporate data warehouse. According to Datamation (November 1996), this warehouse "contains a whopping 7.5TB of information, including a rolling 56-week history of transactions by store, product, supplier, day, etc. ...... The new approach is co-management: each supplier helps manage its product category as a whole-understanding how the category is doing, adjusting for seasonality, store demographics, and so on-but leaves Wal-Mart's own replenishment systems to handle the day-to-day details".

My fondness for the Ford and Wal-Mart examples stems from a number of frustrating experiences with my own clients where the intricacies of a financial package and the lack of a clear business understanding of why things were done as they were resulted in implementing a solution that did not enhance the business, but rather added levels of bureaucracy. The usual end result was the infamous 'work-around'.

Patterns (as business patterns or whatever) are an effective way to identify what processes are buried in the procedures and then to help figure out whether those processes should be changed. Once we know the real transactions ("core transactions") required for a business, then we can apply the most efficient technology to support those patterns.

Finally, while specific alternatives to traditional business practices may be useful as examples and starting points, it would also be useful to have help in identifying the real underlying patterns that are generic to business transactions regardless of how they are mediated.

I'd suggest using EDI for this purpose.

EDI (Electronic Data Interchange) helps identify the generic business processing involved in a transaction and helps ask the questions that need to be asked about whether the packaging is appropriate and whether an activity is value added. EDI is a framework for standardized business transactions whose success indicates the extent to which it IS generic.

Ironically, despite the emphasis on 'electronic', it is very much rooted in the world of paper documents and paper-mediated business. In fact, when I was first exposed to it, EDI was commonly translated as "Electronic Document Interchange".

Aside from providing a consistent starting point for identifying traditional business practices, the EDI framework can help demonstrate cross-transaction sequencing and dependencies and elucidate 'cross-transaction' functions such as authorization, verification, trust-establishment, identification and transaction packaging.

Any approach to modeling business transactions must be able to accommodate traditional transactions as demonstrated by EDI and provide tools for facilitating the transition to newer, more efficient and appropriate scenarios like Ford's and Wal-Mart's. In fact, this is where the potential benefits can come from pattern thinking: not in helping to devise new, object-oriented versions of old solutions, but rather in supporting real problem solving for businesses which can reinforce business re-engineering and continuous process improvement AND make a contribution to the bottom-line.