We don’t yet have any kind of definition for a "Business Transaction Processing System" so here is my short-lived balloon.
A Business Transaction Processing System is a system that monitors economic events for an organization and either reacts to these events by adjusting the financial position of the company, or supports the financial analysis of these events.
By economic event, I mean something that would affect a company’s finances, such as a sale, order, or a requirement to pay an employee. By financial position I mean the state of a company’s finances such as is usually reflected in a company’s accounts. By financial analysis I mean surveying a company’s financial position in ways that may be more wide-ranging that just looking at the accounts.
I realize that this is a narrow definition, but I would like us to try to come up with a few fairly narrow definitions for this type of system. If we try to cover any kind of business information system, I fear that the subject area is too wide for us to find meaningful patterns in the systems. I would like us to explore a definition of this area and to try to come up with a definition that will help people to find appropriate patterns.
A Business Transaction Processing System must record economic events faithfully with as much information as is needed by the rules. It may have to handle large volumes of transactions, and these may arrive in a very uneven manner.
The events are processed by various business rules. These rules can come from several sources: some are regulatory, some are policies that are chosen by the company. The rules that process the events must be easy to change, and a full history of which rules applied at what points in time need to be kept.
Rules may be changed retroactively. When a retroactive rule change occurs, it will find some things that it can undo and others that are now immutable and cannot be changed (payments made, tax declarations made, etc). Those that it cannot undo must be adjusted by separate changes.
Rules may need to be run in a what-if manner to see the effects of changing rules.
The timing of running the rules may vary. Some rules may need to be run as soon as possible. Some may be tied to business cycles (such as paying salaried staff monthly). Some rules may only be needed for analysis and need only be run when analysts are actually carrying out their analysis. However the volume of events affects the timing. What seems like a simple analytic request may require several hours of computer time to process. Similarly the speed of processing cyclic processing (such as monthly payroll) may have a painful impact upon the business process.
I am particularly interested in finding patterns for business information systems. One of things I would like to do in this workshop is find useful patterns for Business Transaction Processing Systems. I have collected and published several Analysis Patterns in my book (Analysis Patterns: Reusable Object Models, Addison-Wesley). Here are some that are useful to Business Transaction Processing Systems.
An account is an object that holds a collection of entries. Each entry knows when it occurred, when it was entered into the account, and a monetary value. The account can give various bits of information about the entries, such as a balance, balance over time period, deposits in a time period, etc.
A transaction is group of at least two entries, arranged so that the sum of the monetary values of the entries is zero. The point of a transaction is that it helps to ensure that money does not get lost in the accounting system.
A posting rule is a rule that looks at one or more accounts and reacts by making entries in other accounts. A simple posting rule might look at each entry in an income account, and make corresponding entries in a tax liability account. The monetary amount of the tax entries would be determined by applying some formula to the entries in the income account. Posting rules can be activated and de-activated so that you can keep a history of which posting rules were active at certain times.
A common approach to analysis is to classify economic events by various factors and roll up the values along these dimensions. This approach is the one used by OLAP and multi-dimensional databases. This is a good technique for getting high level information, but still with the ability to drill down to get at further details.
Using accounts and posting rules certainly helps you to put together a more configurable system. A change in rules can often be handled by replacing just one or two posting rule objects with a replacement. Posting rules also help you with keeping a history of the rules, and it is also not too complicated to handle retroactive rule changes.
However in doing this we are creating a new programming language, and this raises the ugly question of what about testing, what about debugging, what about any of the things that you have to deal with when programming. It’s tempting to say we give the users the ability to change the rules themselves. But are we not just trying to duck our responsibility to ensure that rule changes are done in a controlled manner, and how can we avoid putting too much responsibility on our users. Certainly there are some applications when this architecture is useful, but there also those when this is too much flexibility to be useful. My problem is that I need to be more aware of the alternatives, and more aware of the factors which should make me choose one or the other.
Martin Fowler is an independent consultant who has worked with objects in business information systems for over a decade. His projects have included derivatives trading for Citibank, payroll for Chrysler, and healthcare for the British National Health Service. He is author of Analysis Patterns: Reusable Object Models.
martin_fowler@compuserve.com
http://ourwor
ld.compuserve.com/homepages/Martin_Fowler