Conversely, when companies do attempt to develop systems to manage and automate compliance, there are usually two groups of people involved—business people and programmers. These two groups approach the projects with entirely different perspectives. Many of us have seen this so often that we consider it routine and we take the problem for granted. Yet, this difference of perspective often results in serious problems when developing complex systems. Is it inevitable that a "systems-approach" won't be able to manage compliance and these processes will remain manual? Not with the right approach.

First you must understand why business users and IT clash. The underlying issue when developing compliance-oriented systems is one of the different perspectives and skills business and IT bring to the table. Business users are at the mercy of the regulations, court rulings, and policies that must be enforced. This often means they can't stabilize their requirements or easily explain them to developers—legal jargon doesn't always map well to Java code. Meanwhile, the developers typically don't understand the regulations well enough and are limited in developing necessary applications, systems, and updates fast enough.

The problem …
As an illustration let's take the example of a healthcare benefits system that is designed to specify which individuals are eligible for what levels of benefits.

... from a business perspective

The system needs to implement Federal and State regulations. Most states have their own regulations and these are applied sometimes to employees based on the state in which they live, sometimes to the state in which the employer is based, and sometimes both. Benefits plans impose additional rules and policies, with every plan being different; and, often plans have different rules by state. Of course many of these rules have been the subject of court interpretations and any of them could be rescinded or altered at any moment by a legislature or court.

In addition, we want to offer maximum contract flexibility for employers: We want to be able to let them make benefits contingent on almost anything that's legal and let them change these rules whenever they want, though usually in time for the main benefits election period. After that, it gets complicated because we need to certify that the software is enforcing all these rules … and no one on the team reads Java or understands XML, etc.

... from an IT perspective

It seems like new Federal and State regulations come down the pike on a daily basis. How are we supposed to keep up with them or understand the legal jargon? If we don't, then we rely on the business users to keep us informed. But the business users can't explain the regulations accurately enough for us to write code against them and none of them can read the code we write anyway, making it impossible to verify the code.

We've tried developing test cases, but there's an exponential growth in these as we add states and plans. Plus, usually, no one knows how a case will turn out until they apply all the rules, making it hard to develop test cases. If this isn't enough, the plans' descriptions are full of healthcare terms and legal-speak.

And, this idea of allowing unlimited flexibility for the plans? That's crazy. They have to limit the number of things that can be used to make decisions and the types of decisions that can be made, so we can build some kind of configuration tool. Even then it's going to take a while to add a new plan to the system and we had better get some serious notice for any changes to the regulations.

Not a new perspective, a new approach

This problem is all too familiar, and by no means is it limited to compliance systems. A number of leading organizations have begun separating the business logic from the application code with a business rules approach to successfully develop compliance systems.

A business rules management system (BRMS), also known as a Business Rules Engine (BRE), centralizes the definition, storage, and application of the many rules used in business operations to provide organizations with greater automation, more responsiveness to change, and less expensive distribution and maintenance of their business guidelines.

Business rules governing operational processes may be complex, with many interrelating considerations. They may also be simple but extremely numerous, covering a wide variety of different situations. And, most difficult of all for organizations to manage, they may change frequently based on internal policy decisions and external competitive or regulatory factors.

The key concepts supporting separation of business rules from the remainder of application functionality are threefold:

• Write the rules in a way that isn't specific to the mechanisms used to obtain and update data, or on the mechanisms used to carry out recommended actions. This gives you the flexibility to upgrade as technology evolves.
• Create a way to choose and execute the right rules at the right time in the right order without involving control by the application code.
• Allow organizational control and management of the rules in a way that doesn't depend on or affect the rest of the application code.