In today’s competitive markets, the environment can rapidly change. You may need to quickly respond to a competitor’s new product offerings or change the way you do business to reduce your exposure to risk or respond to new business regulations. Traditionally, to make the required changes, people from the business area of the organization will identify what rules need to be changed. For example, should you bring in a new offer for your services or stop offering services to customers who are too high risk? Once these changes are identified, a set of requirements is given to the IT department to implement. This is where problems can occur:
- Have the requirements been properly drafted?
- Did IT properly understand the requirements?
- Even if IT understood these requirements, does the change that’s being implemented match the requirement?
- What priority should IT assign to the application change?
Let’s consider these problems. There are two main ways in which the business can fail to properly draft IT requirements. The first may be a result of badly worded or unclear documentation being produced. If the documentation is unclear, it’s left to the IT department to interpret the requirement; this can lead to an unintended application change being made. The second way results when the requirements don’t actually solve the problem the business was trying to fix. Perhaps the business hasn’t tested its requirements to discover the effect they will have on the overall business.
Even when requirements have been well-drafted, there’s still the possibility the IT department can misinterpret what they’ve been asked to do. At every stage where a task is handed over to different parts of a business with their different priorities and community-specific terminology, misunderstandings can occur. Rigorous, time-consuming processes must be in place to mitigate these problems. The same applies when testing to ensure the application change actually matches the requirement. It’s possible for IT to understand the requirement but during the course of application development have the implementation diverge from the initial requirement. This also requires rigorous, time-consuming testing and processes to mitigate this risk.
The business and IT sides of an organization also will have conflicting priorities. A business may see a particular application change as urgent to respond to a change in the market. However, IT may have a conflicting set of priorities. The IT department may be trying to resolve a critical outage or be performing a business-critical migration. In this situation, both sets of priorities are important to their particular communities, but because the business users must rely on IT to implement a change, their changes will sometimes be prioritized below those of the IT department.
By using a Business Rule Management System (BRMS), you can address these four issues in a more efficient, robust manner. A BRMS allows business rules currently locked inside application code to be exposed in a natural language style that business users can understand, modify, and deploy.
This allows the business side of the organization to take over responsibility for changing and testing the business rules. It reduces the likelihood of conflicting priorities between business and IT and the chances IT will misunderstand the business requirements. IT no longer has to prioritize modifications to the business behavior of their applications against handling tasks such as hardware and software migrations, or resolving system outages.
With a BRMS, it’s also possible to let the business side directly deploy the changes into a production environment. Many system administrators may be nervous about allowing someone outside IT to make changes to a production environment, but it’s important to realize that a BRMS doesn’t require this. It would be valid to have a change control process where the business side is responsible for making rule changes, but IT team members are responsible for reviewing and deploying those changes into production.
Your business rules are currently locked away in your application code. When a change is required, it may not be easy to identify what part(s) of the code need to be changed to meet the requirement that drove the change. Once the rules are extracted from your applications and held in a BRMS, it becomes easy to identify what rules there are and how they work. Because a BRMS stores rules in an easily understood format, it’s easy to train employees how to modify your applications to respond to a requirement. This means that bottlenecks caused by relying on a small number of individuals with highly specialized skills become less likely.
A BRMS will consist of several parts, including a development environment that will help a rules developer (usually someone in the IT side of the business) create new rules and rule applications. Once the rules developer has created and tested the rules, he will deploy them to an execution environment and a repository. The repository allows the rules developer to share rules with the rest of the organization, and it’s from here that business users would modify rules to be deployed into the execution environment. Finally, a good BRMS also will let users and developers test and simulate the effects of their rule changes. This allows them to check that a rule change doesn’t impact the business in unexpected ways (such as a rule change doesn’t accept people who are too high-risk for a loan or reject those who would be good customers).
By using a BRMS, you can reduce the:
- Potential for priority conflicts between the business and IT
- Likelihood that a change to the IT systems will fail to match the requirement that drove that change
- IT department’s workload by enabling business users to perform routine application updates.
A BRMS can bring real agility and flexibility to your mainframe applications and help you respond more rapidly and effectively to a constantly shifting market.