Struggling with Changing Business Applications? There's Hope

Change is part of life. Your business is not static, but ever-changing in response to market and competitive demands. Ideally, your business applications can be just as dynamic as your business itself, as you offer new and improved capabilities to your users, respond to regulatory requirements, refine for operational efficiencies, implement in code your business processes, etc. The challenge is keeping up in a world where change is not just inevitable but is coming at you quickly and at an ever-increasing pace. It can be a daunting challenge to update your applications in the timeframes needed to best support your business, and the demands of the business require a reaction in hours or days, not weeks or months.

All business applications are built on processing rules, typically implemented in code using conditional structures such as If-Then-Else. If the price of a new car exceeds the credit limit of the customer, then send the loan application to the appropriate sales manager for further review and approval. If the connection time between airline flights is less than 60 minutes, then warn the user and ask for confirmation to proceed. If the health insurance customer is under the age of 25 and is a non-smoker, assign a risk assessment of ‘low’.

A goal is to implement and maintain your business logic in a way that lends itself to easy and fast change over time, much faster than the traditional application development lifecycle permits. One way that development organizations are coping with the pace of change is through the use of Business Rules Management Systems (BRMS). A BRMS provides the ability for you to define business rules, as simple or as complex as needed, in a form that is intuitive, fast, and easy, and that does not require programming. Essentially, BRMS does for business rules what spreadsheets did for calculations.

OpenEdge developers have access to a BRMS from Progress through a product called Corticon. Business rules can be defined using whatever vocabulary is appropriate for your situation, and at run-time, inputs are passed to a "decision service" that evaluates the input against the rule set, and a result is returned. The benefits are many: you can be much more agile and productive in implementing and maintaining the rules that drive your business over time (and often this can be accomplished by a Business Analyst rather than a Software Engineer), it is easy to test to see if you have accounted for all possible outcomes when the rules are applied to various input scenarios, and you do not have to hard code your business rules and carry out the typical Quality Assurance testing that is required for software coding changes.

Best of all, the use of a BRMS does not require dramatic architectural changes to your existing OpenEdge business applications. To get started, pick the highest priority logic flow in your application - one that is often updated as business requirements change. Next, add the corresponding rules definition into the BRMS. Finally, modify your application to call the decision service based on your rules set, passing in the appropriate data inputs and receiving back the result. With minimal effort, you have modernized that section of your application to be responsive to future change!

Are rules a better way for you to deal with change?