When developing systems, one often gets quite different perspectives from the business people involved and from the programmers. Many of us have seen this so often that we take it for granted. Yet this difference of perspective often results in serious problems when developing complex systems. Is it inevitable? Not with the right approach.
So why do they fight? The basic issue when developing systems results from the different perspectives and skills brought to bear by business and IT folks. Business users are at the mercy of regulations, court rulings and business policies that must be enforced. They must also respond to an ever-changing business and competitive environment. This often means they can’t stabilize their requirements or explain them easily to developers – legal or business jargon does not always map well to Java code! Meanwhile the developers typically don’t understand the regulations or business environment well enough and so can’t develop necessary applications, systems and updates fast enough.
As an Illustration let’s take the example of a healthcare benefits system designed to who is eligible for what.
First, the business Perspective
The system needs to implement Federal and State regulations – most states have their own and these are applied sometimes to employees based on the state in which they live and sometimes to the state in which the employer is based and sometimes both. Additional rules and policies are imposed by plans, 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 is legal and to change these rules whenever they want, though mostly in time for the main benefits election period. After that it gets complicated as we need to certify that we are enforcing all these rules and no-one on the team reads Java or understands XML etc…
IT Perspective
Well all these Federal and State regulations – sure, but how are we meant to keep up with them or read the legal jargon? If we don’t then we rely on the business to keep us informed. But they can’t explain them accurately enough for us to write code against them and none of them can read the code we right anyway making it impossible to verify it. We’ve tried developing test cases but there is an exponential growth in these as we add states and plans and anyway, often no-one knows how a case will turn out until they apply all the rules making it hard to develop test cases. If this wasn’t enough, the plans’ descriptions are full of healthcare terms and legal-speak that is outside our domain. As for 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 is 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…
So if this problem sounds familiar what solution exists? Well you could try what more and more companies are trying and use a business rules approach to find a way around this problem.
A business rules management system or BRMS (also known as a Business Rules Engine or 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:
- Specify the rules in a way that does not depend on the mechanisms used to obtain and update data or on the mechanisms used to carry out recommended actions.
- 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 does not depend on or affect the rest of the application code.
Any complete business rules management technology should incorporate all three elements through language and interface constructs, a processing “engine,” and independent rule management facilities. This means:
- It does not require business users to manage objects, interface to existing systems, package up and deploy working code – IT still owns this process
- It allows IT to write technically complex rules in a syntax that business users can validate
- It allows knowledgeable users to write regulations as rules using a simple, English-like syntax
- It enables IT to develop templates to constrain rules that business users want to change for each customer – template prevents problems and guides rule creation but allows for high degree of flexibility
- It allows the development of layers of rules – Federal, State, Plan and Employer for example – and manages the selection of the right rules for a transaction and the efficient execution of these rules as a set
- It allows IT to do architectural design, integration etc. ensuring that the resulting application can be supported and integrated easily
- It frees up future development time that would be tied up with system updates.
So if the battle between IT and the business is common when you are developing systems, try the business rules approach. It doesn’t have to be that way.
