Jeff Oakes -- joakes@thehartford.com
I am an object architect at The Hartford. For the past four years, I have been designing and building frameworks for constructing insurance policy administration systems. The frameworks are used to represent insurance policies, the rules for processing the policies, and workflow. Before that, I spent 25 years in the insurance industry as a data analyst and then as an architect. I've been doing object-oriented programming and design for fourteen years.
Our insurance policy administration systems downplay the role of a business transaction as an exchange of money, because accounting is handled by a legacy system. Instead, transactions are used to identify states of the system (i.e. the state of a policy at the time of the transaction) and to describe and bound a meaningful unit of work. A policy is a contract between policy holder and insurance company, and this policy changes over time. When we access the state of a policy, we always do so relative to a particular transaction. So, transactions define the valid historical views of the policy. A business transaction object bounds any technical transactions, such as inquiries or data base changes.
For example, a transaction might be an inquiry, a quote, an endorsement, or a renewal. An endorsement and a renewal change some of the attributes of the policy. Each attribute keeps track of the history of its values. Since an attribute only changes because of a transaction, histories are indexed by transaction. Each policy keeps track of all the transactions that have affected it. A quote not only changes attributes, but may be selectively used to build a policy, so it is important to keep a history of the quotes that have been given. Inquiries are also recorded, as business events, even though they do not result in changes.
In addition to identifying state, transactions reflect business activity, including changes. For some of these activities, different rules apply about what other business activities are relevant, or even valid.
For example, if you have cancelled an endorsement, the related state (the endorsements changes) are null and void for any 'in-force' inquiry. But for cost of insurance calculations, there was a period during which the endorsement was in effect, and therefore a cost contribution is relevant. So, for a cost of insurance transaction the endorsement is a valid part of the policy view; i.e., it is not filtered. Thus different transactions (by type) carry different filter rules. These rules are used to construct valid views of a policy.
When a transaction is thought of as describing a set of tasks and the sequencing rules among them, it is acting like a work flow. In our system, business transactions are implemented as type-instance composites. The type object defines the attributes, legal subcomponents, filter rules, and valid task types (sequenced as required - task types have predecessors). The instance object holds attribute values, chosen subcomponents (in accordant numbers), filtered transactions, and a game plan (which is made up of tasks (both completed and proposed). A transaction drives workflow, and provides a key for any state changes incurred within the workflow.
In conclusion, there are two views of transactions. Inside a policy, a transaction is just an identifier used to specify the state of the policy, and a source for filter logic. Policies do not care about the structure of a transaction. However, outside a policy, transactions drive the behavior of the system. They specify the workflow and give a context for all operations on the policy.
We do not deny that transactions often represent exchanges. If our systems had to perform accounting then our business transactions would also serve that purpose. But business transactions are useful even when the purpose of the business objects is maintaining contractual relationships, not financial state.