Business
Object Workshop IIBusiness
Object Workshop IIComments:
For business objects to be reusable, they must be at the right level of abstraction. Classes like Customer and Invoice will not be very reusable because they are too specific, and each company will have its own version of them. On the other hand, classes like Business Object and Business Transaction are too general. We don't need another general-purpose object model.
Reusable business objects will have to thread the gap between solutions that are too specific and too general. There will not be a single model of business objects. Instead, there will be a set of specialized models that work together. The important research problems are to figure out the models that are needed, to define each one, and to learn how they can be used together.
This paper describes Accounts, a framework for business transaction processing, which is an example of the kind of business object model that is needed. It also describes the general problem of integrating different models of business objects, and uses Accounts to explore this problem.
An invoice is a common business object. But there are several different views of an invoice. An invoice is a workflow document, because the organization that receives it usually has to check it against the received goods and against the purchase order. It is a document in a document-retrieval system that stores images of all documents, allowing paper to be destroyed. It is a business transaction in an accounting system. These views are not incompatible, but they will not automatically be synchronized.
Each of these views is a model of a business object. In the long run, each of them will have software that supports it. There are currently work-flow and document retrieval systems that support those particular models of business objects. We've been working on a framework for business transaction processing that supports the third model. A complete view of an invoice is a combination of all these models, and it requires the models to work together.
None of these models capture everything about the business object, but each captures something the others don't. The workflow system keeps track of the state of objects and enforces the rules about when an object moves from one state to another. The document retrieval system stores images and can search for them. The business transaction processing system specifies the relationship between the values of accounts and the transactions posted to them. Workflow systems usually don't know anything about money. The business transaction processing system we are building doesn't know anything about state transitions, but just keeps track of numerical functions of time like the value of an account. A complete system requires each model, and so each software package, to work with the others.
Accounts (http://st-www.cs.uiuc.edu/users/johnson/Accounts.html) is a framework for business transaction processing that we are developing. The two main kinds of objects in Accounts are transactions, which are objects like invoices, checks, or timecards, and accounts, which keep track of the status of some business object like an inventory item, a vender, or an employee. Transactions model the pieces of paper that flow between businesses, usually describing either the flow of money and goods or commitments of money and goods. Accounts model the "books", the documents that describe the state of the business. Thus, they describe how much inventory you have, how much you owe your venders, and your net worth. Transactions are fairly simple, basically a record with a date. Accounts are much more complex, since their attributes change over time. You don't ask for the amount you owe a vendor, you must ask for the amount that you owe a vendor at a particular point in time, because the amount you owe changes from day to day.
Accounts transactions are related to database transactions, but are not the same, because a single Accounts transaction might turn into several database transactions. In the same way, an account in Accounts can model an account in an accounting system, but is not the same. In Accounts, an account can have many values. For example, an inventory account might keep track of the on-hand inventory, the amount on order, the cost-of-goods sold for the each month and year, and the sales for any time period. Also, an accounting system should enforce double-entry transactions, but an inventory system does not need to. Accounts uses more direct means of enforcing consistency, though it can support true double-entry bookkeeping.
One of the most important features of Accounts is the way it enforces relationships between transactions and accounts. Transactions are posted to accounts, and the value of an attribute of an account is a function of the transactions that have been posted to that account. Most business transaction processing systems enforce these relationships with an update program (usually written in COBOL) that reads transactions and updates the master file of accounts. The business rules are hard-coded in the update program, and changing one of them requires a new version of the program. It can be hard to undo a transaction or to execute them out of order because you have to make sure that you are using the right version of the update program.
In contrast, Accounts enforces relationships between transactions and accounts by defining each attribute of an account as a function of the transactions posted to that account. For example, the "total sales" attribute of an inventory account is the total of the sales field of all transactions posted to that account, the "total purchases" attribute is the total of the purchases field, and the "on hand" attribute is defined to be "total purchases - total sales - total shrinkage".
This model has many advantages. It is easier to specify how to process a transaction. Business rules are time-stamped, so it is easy to process transactions out of order and to use the correct set of business rules. It is also easy to undo them. It is easy to decide that a business rule will change as of a certain date. This makes month-end closing much simpler.
The major disadvantage is that the model implies that all processing takes place when an account's attribute is read, and this is too inefficient. Thus, the actual implementation must process transactions differently than implied by the model.
Accounts has a graphical user interface for specifying business transaction processing system. A typical application can be built entirely with this interface, without programming. The interface essentially provides a "visual programming" system that is more like programming a spreadsheet than programming in a conventional language. Like all such systems, it has limitations, but it is possible to extend Accounts (by programming) to overcome them. We have not tried it out on a real business yet, but we hope that the combination of visual language for most applications, and extensibility for the rest, will make it both easy to use and powerful.
Any model is an approximation of reality. A complete picture of an application requires many interacting models. One of the problems with describing complex systems is making sure that the various models used to describe it are consistent. This is even harder with model-based software, because the part of the system based on one model will have to interact with the part based on another. Thus, a GUI produced by a GUI builder will have to interact with a business model, which will have to interact with a database. This will be true of the models used to make business objects, too.
Even though business transaction processing is a large part of many business applications, it isn't enough for Accounts to handle it well. Accounts must also interact with parts of the application that have nothing to do with business transaction processing. For example, an invoice is both an Accounts transaction and a work item in a workflow system. When it is received, it has to be matched against a purchase order to make sure that all the goods were ordered, and it must be checked to make sure that the goods were actually received. Then the invoice has to be paid on time. Accounts can calculate the total amount of goods ordered minus the ones invoiced and make sure that the number is positive. It can calculate the total amount of invoiced received minus the amount paid to the vender and make sure that a new check pays the full amount. But it doesn't keep track of exactly which purchase orders have had invoices received, and which invoices have been paid. This would have to be done by a different part of the system.
This is similar to the problem of how to connect a GUI to an application. A common way to solve this problem is with a dependency mechanism, which lets the two parts of the system interact without introducing too much coupling. Perhaps a similar solution will be found for connecting Accounts to a workflow system. But a complete set of tools for business objects will involve several different systems like Accounts. There will be systems for scheduling, systems for document storage and retrieval, as well as the usual systems for graphical user interfaces and databases. How to make different models interact will be one of the more interesting and important research problems in this field, because I am convinced that there will be many specialized models for business objects, and they will have to interact.
Business
Object Workshop II