Case Study: Automating Business Rules at a Public Sector Financial Institution

Author Information:
            Dean Mackie
            Manager, Software Development
            Ontario Teachers' Pension Plan
            5650 Yonge St, 3rd Floor
            Toronto, ON
            Canada   M2M 4H5
            V:(416) 730 3790
            F:(416) 730 5349
           mailto:dmackie@alumni.cse.ucsc.edu
           http://alumni.cse.ucsc.edu/~dmackie/DEAN_Professional.html
 

Introduction
At the Ontario Teachers' Pension Plan Board (OTPP), a system has been developed to automate and integrate business rules, processes, and technology, to manage a US$50Billion pension fund on behalf of over 300,000 working, retired, and inactive school teachers.  The issues experienced in its implementation and ongoing evolution highlight the complexity of public sector companies dealing with government legislation as a basis for business rules, as well as issues shared by information technologists in private sector and financial industries in modelling processes and integrating systems.  The three keys to the success of the project are discussed in this position paper.  First, the flexible abstraction of ambiguous and exception-riddled business rules which change regularly.  Second, the enforcement of isolation and encapsulation of the layered architecture.  Third, the testing strategy used to support the solution.

Background
Many industries have to deal with government legislation: for financial institutions the emphasis is on tax laws and securities regulations.  Public sector institutions have the additional task of modelling basic operating rules from government legislation as well.  The OTPP manages a defined-benefit pension that has been in existence for over 80 years on behalf of employees who generally work for 35 years before retiring.  Members may not switch pensions or opt-out of the pension unless they leave teaching for another industry, but they do have political and public influence in participating with the government to modify the benefit rules.  Thus, major changes to the rules can occur yearly, and minor changes as well as exceptions and new interpretations can occur weekly.  Changes to benefit rules and exceptions are generally argued in the legal and political systems, so they are invariably vague, ambiguous, or subject to interpretation.  They also usually get announced as being effective immediately.

For these reasons, rule modelling and automation are taken seriously at OTPP.  Even though OTPP is currently a monopoly, we are committed to being the best-run pension fund in the industry and to providing outstanding service to our members.  Technology plays an important role in enabling the timely and accurate processing of member requests.

Historically, work was not automated and extensively-trained personnel interpreted rules for members.  In the early 1990s a proprietary rule-based inferencing system was introduced to begin automating business rules and processes.  In the late 1990s, this system began to be replaced with an object-oriented system that was open, standardized, and faster.  That system continues to evolve and has automated major areas of business rules and processes, as well as providing integration with telephony, office software, workflow, document generation/routing/imaging, databases, legacy systems, and the internet.  Many lessons were learned along the way on automating business rules.

Business Rules at OTPP
The experience of beginning with a pure rule-based system at OTPP, besides the difficulties associated with using a proprietary environment and performance issues, was critical to the formation of our ongoing strategy.  The formal system did not allow for sufficient levels of ambiguity in definition or flexibility in migrating from one abstraction to another.  Because our business rules are sometimes ill-defined and change frequently, the strength of a formal rule-based system is how it forces you to discover suitable abstractions.  But the drawback is that abstractions were difficult to alter on a large scale once defined: the rule-based system was not as effective at forcing a separation of concerns or encapsulation as a pure object-oriented language.  We also rejected the notion of having the rules reside in a repository separate from the execution engine as inflexible on a larger scale.  Furthermore, since we were developing internal-use applications, deploying new executables to the entire organization was fairly easy so there was no smaller scale advantage to that separation.  So the strategy that evolved was to develop business rules as an isolated layer within the application.

Flexible Abstraction
The objects within the system were developed by modelling information from three sources: the legislative rules, corporate policies, and business processes.  Legislative rules are defined external to the organization and are subject to interpretation and legal debate.  They are subject to change and have effective dates, so that, for example, corporate policies must be developed to manage work that applies before, after, or spanning effective dates in a manner consistent with all known legislation.  Corporate policies also evolve around work for which no specific legislative rule applies (yet) or where legislative rules are ambiguous.  Business policies help determine corporate workflow resulting in timely and accurate responses to member requests while managing risk effectively. Policies and processes also change regularly and can also result in effective dates for rules.

Attempting to model or even document all the rules governing the company would neither be practical nor cost-effective given the amount of effort required to collate and maintain currency of the information.  At OTPP the strategy used was to automate the activities of one department at a time, within the multiple departments involved throughout the company.  As behaviour for new departments was brought on board, objects were refactored to evolve the main abstractions. Flexibility was therefore extremely important in the abstractions used.  Also, a clear vision of the fundamental model used was communicated regularly to the development team, even as short-term tradeoffs and tactical practicalities were acknowledged and implemented.

The key was the identification of the main units of corporate currency, given the legislative rules, corporate policies, and business processes.  These are the objects that move into, around, and out of the company with the information and activities associated to them.  For this reason the simple notion of a rule is not a first class object, but rather rules get embedded into the primary abstractions as appropriate. Encapsulation and layering were important to help ensure the flexibility of the design, so that it might easily react not only to rule changes, but to expansion or shifting of scope as more departments begin using the system.

Layers
The system saw fairly standard layering.  The graphical user interface (GUI) was isolated from the business rules by an ever-maturing application layer, as were back-end repositories and integrated systems.  When we web-enabled the application, we saw a temptation to violate the encapsulation of the business domain objects.  We perceived that web application server vendors were encouraging users to remodel their business logic within Enterprise JavaBeans (EJBs), colocated with the application server itself.  Instead, we chose to enforce the isolation of the domain objects and use a Simple Object Access Protocol (SOAP) framework to send business information as an extensible modelling language (XML) payload with Common Object Request Broker Architecture (CORBA) as the middleware.  This allowed us to focus on web integration logic and business rules separately.

Exception handling was also critical to the success of the layering.  Generally, the system handled the most common types of requests, plus more exceptional requests to a reasonable granularity.  Exceptionally unusual cases were escalated to the point of requiring intervention from managers or other departments, or rejected and done completely manually.  This meant that exceptions could result in a code branch, or in a cross-layer notification to different modules, or in a multi-layer traversal that could have been initiated by either a singular GUI or a distributed, headless, batch application.

Testing
Rather than have software developers test the application, business analysts were used to ensure that rules were correctly implemented.  They were specialists at identifying the most common or the most exceptional cases, and incomputing results by hand for comparison to the system.  We built a regression testing system that allowed them to directly access and test the business domain objects with varying inputs and expected results.  During the design phases, testers would agree with developers on the most appropriate business functions to be exposed within the domain objects so that they could be tested independently of front-end and back-end integration frameworks.  Regression testing became the key to smooth implementation of changes to business rules.
 

Observations
After beginning with a pure rule-based system, and experimenting with rules isolated from the application engine, we found success in embedding business rules within business domain objects that were designed for flexibility around a vision of the basic units of currency for the company.  This allowed us to expand the scope and functionality of our application and to respond quickly to changes.  It was an effective approach within the corporate environment of a public sector financial company.

The most troublesome issue in the lifetime of the application was maintaining effective separation of the layers (roughly approximated by the notion of user/workspace/enterprise/resource).  At times the GUI would assume application and business rule behaviour, and at times the business domain model was identical to whatever the legacy relational database structure was.  Object-relational interaction has come a long way, yet the difficulty is when legacy relational structures have become ingrained within corporate culture and hence business policies and processes.  For this reason object-oriented thinkers make effective leaders of cultural change within organizations.

On the GUI/domain separation issue, beyond practical expediency, these layers tend to overlap due to the fact that the separation of the workspace and enterprise layers is not always obvious, particularly in an environment of constant change.  Sometimes it is much easier to implement a business rule change as a branch within the workspace layer, rather than refactoring objects deeper in the enterprise layer.  It has lead us to search for higher-level abstractions that are coded within the workspace layer, but are in fact enterprise objects.  We expect continued integration with the internet to force this to occur, particularly with the more advanced workflow that must be managed.
 

Future Directions
Business transactions can be directly tied to database transactions in a client-server architecture.  Within a distributed architecture, a business transaction can still be managed centrally across multiple distributed database transactions.  With complex business transactions through the internet, you have the additional concerns of longer transactions, no guarantee of information delivery, plus security issues etc.  At that point business transactions are more workflow in nature than simple extensions of database transactions.  Yet, to be successful, companies must undertake delivering atomic, consistent, isolated, and durable (ACID) business transactions across the internet.  For our members, the prospect of retiring is somewhat more daunting than the notion of ordering a book on the internet.  It will be a challenge to evolve our abstractions as we expand our services on the internet in a manner that continues to delight our members.
 

Dean Mackie is the manager of software development at the Ontario Teachers Pension Plan Board.  He has an undergraduate degree from the University of Toronto and a master's degree from the University of California.  Before joining OTPP 4.5 years ago he worked with IBM, Celestica, Discis Knowledge Research, and ParcPlace Systems.