This article is an excerpt from a recently published book, The Business Rule Revolution. Co-edited by Barbara von Halle and Larry
Goldberg, the book is an anthology of real-world experiences in business rules, business process management, and organizational business rule governance. Contributing authors represent major
corporations, government agencies and leading consultants.
Oregon Public Employee Retirement System
The Oregon Public Employee Retirement System (OPERS) provides state, local, and higher education agencies with multiple pension, deferred compensation, and retiree health insurance programs. The
original plan is a defined benefit plan; the new plan includes both a defined benefit plan and a defined contribution plan. Additionally, we administer a deferred compensation plan, retiree health
insurance, and long-term care insurance.
Business Drivers for OPERS’s Business Rules
There are many business drivers for OPERS to justify using the Business Rules Approach. These drivers include regulatory requirements, litigation concerns, audit concerns, and the need for agility.
The primary regulatory business driver is the statutory requirement that the OPERS retirement plans continue to meet IRS requirements to be qualified plans. The litigation driver consists of court
rulings creating changes to business rules and processes – sometimes retroactively.
Audits, as a driver, may change business practices, business requirements, business rules and impact current and planned IT projects.
Agility is key to responding to ever-changing business demands, necessitating business-driven projects with centralized management of business and system requirements. Therefore, taking control of
requirements, including business rules, stakeholder needs, use cases, requirement specifications, and operational processes and procedures was our first priority. However, due to budgetary
constraints, a commercial business rules engine was not an option. Instead, OPERS extended existing use of the IBM Rational RequisitePro® requirements and use case management tool to develop
separate databases within a single repository. As a result, traceability between multiple requirement types allows OPERS to manage business change with greater agility and quality.
Establishing a Business Rules Group and Related Tools
The OPERS Quality Assurance Manager is organizationally aligned under the Information Systems Division and has the role of technology development and quality assurance (QA). The responsibility for
developing business rules was realigned to a business unit in 2005. The Business Process Management (BPM) methodology is currently championed by QA, but will also evolve to a business unit
responsible for processes.
The Rational Unified Process (RUP) methodology has been the basis for our IT projects since 1998. The RUP methodology has four phases: Inception, Elaboration, Construction, and Transition. Using
RUP, OPERS applies incremental development between the phases. The IBM Rational StudioAnalyst® suite, which includes IBM Rational RequisitePro®, is the IT tool set the agency has available
for development projects. We selected it as the database and repository for business rule requirements.
We also researched the Business Process Management (BPM) approach and determined how OPERS could implement this change in development methods and business organizational approach.
Legislative approval of a major systems conversion project for OPERS in 2004 provided a vehicle that let us begin the change process from IT-driven to business-driven projects and contracts. The
system architecture for the new program uses a new server-based tool set.
IT-Driven Approach versus Business and BPM-Driven Approach
The contract requirements identified the use of a Business Process Management (BPM) methodology. Moving business rule development and maintenance to the first RUP phase of Inception allowed
increased quality, mitigation of risks, and accurate results when the system developers started doing their development work during the RUP Elaboration and Construction phases. Another benefit
would be the likelihood that the project schedule could be maintained, due to a reduced quantity of rework resulting from inaccurate or unidentified requirements.
Our business and BPM-driven approach leverages industry best-practice standards. This method strongly supports structured approaches in business rules, requirements, design, implementation, and
testing.
Figure 1 illustrates our comparison of the development approaches from a business user and developer viewpoint.
Lean and agile BPM is having positive effects on the latest OPERS system conversion project. Business users are directly involved in the business requirements identification and verification much
earlier in the development process. Figure 2 compares the differences in gathering requirements between a typical IT-driven approach project and a business and BPM-driven project.
When we analyzed and compared the two approaches, it became evident that there are several distinct key differences, illustrated in Figure 3.
The IT-driven fact-finding methodology is based on a less structured, less formal development approach. Generally, there are few standards used in discovering business expectations. Experiences
revealed that it can be hard to tell when IT-driven projects are really complete. The processes of and artifacts resulting from development activity are difficult for business users or QA to review
or verify, because there tend to be no clearly defined requirements or measurement points. Business rules and requirements are typically developed later in the IT-driven approach.
The business and BPM-driven methodology emerged as the model to use. It is based on a more structured/formal approach that leverages industry best-practice standards, to enable better review
processes and tools for business users and QA. The software tools available for BPM aid verification and completeness. Our BPM approach strongly supports structured approaches in business rules,
requirements, design, implementation, and testing. The tools also provide traceability, linkage of models, use cases, business rules, requirements, and test cases. Our BPM methodology also provides
long-term usefulness in training, process improvement, and risk management.
The Business-Driven Project
Our Business Rules Project began in 1999. The business-driven project began in early 2005. We were constrained to use our existing software tools. Our objectives in using Rational RequisitePro®
were to develop process, business rule, and requirement database repositories, and to associate those databases (traceability) to maintain versioned business rule and process information. Business
rules are captured in RequisitePro, while the Microsoft Word documents are maintained and versioned in a Rational ClearCase® repository. RequisitePro is also used to capture elements,
stakeholder needs, use cases, and requirements.
The manual maintenance of the business rule portion of the databases and repositories was very labor-intensive. OPERS had to find a more viable maintenance process. To achieve the process
improvement goal, we developed a front-end program and process that automated the manual updates to multiple business rules database repositories, named Business Rules Transaction Application
(BRTA). The BRTA tool incorporates a business rule process workflow from identification through approval and QA reviews to automated updates to the appropriate repositories. The final piece of the
workflow makes the current approved version of business rules available for use by business users.
The implementation of this tool allowed us to consolidate business rule responsibilities from IT (QA) systems staff to the primary business users after appropriate training. The primary user is our
Business Rules Writing Team. QA is a secondary user. The BRTA tool allows independent QA reviews of business rules. This process and tool ensures multiple databases and repositories agree at any
point in time.
Summary
Development of business rules and the repository affected how OPERS develops and maintains software. Application of BPM has allowed us to implement a business-driven project process. OPERS projects
are now centered on early development of: business process models; inputs/outputs, steps, and workflows; stakeholder needs; requirements; and identifying roles and responsibilities. Developing
business rules that support business process models has been shifted to the earliest stage/phase of a project. We can now create a business and system requirements traceability matrix. This allows
OPERS to drive requirements through implementation and change management. The QA and User Acceptance test plans and testing results are more accurate and responsive to any late changes due to an
early identification of requirements and business rules.
What did we learn?
- A dedicated team of business users with experience and industry knowledge is essential.
- Unwavering executive support is absolutely necessary.
- A Business Rules Engine (BRE) would have made much of the effort more efficient.
- A BRE would allow simulation of proposed changes to better identify issues and risks.
- Business users and IT staff need a business rules repository.
- Business cases must be planned and developed for the toolsets required.
- Contractors should be required to use BRE for all systems development.
- BPM and associated toolsets is a very good methodology to use in today’s marketplace.
- While a toolset may eventually be made to work, it may be inefficient.
What does the future potentially hold for us as we continue our journey with BPM and business rules? Find out in Chapter 6 of The Business Rule Revolution.
Suggested References for the Reader to Explore Further:
BPM white papers and round tables at http://www.BPMInstitute.org
Smith, Howard, and Peter Fingar. Business Process Management (BPM): The Third Wave. (Tampa: Meghan-Kiffer Press), 2003.
Spanyi, Andrew. Business Process Management is a Team Sport: Play it to Win! (Tampa: Anclote Press), 2003.