This position paper has been submitted to both business rule workshops:
Best-practices in Business Rule Design and Implementation
Business Object Component Design and Implementation VI:
EAI
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.