An Introduction to Business Rules Programming
How to Start Building Work Process and Practices into Software
Jul 9, 2009
Business rules are a very important consideration in a modern organisation. Used correctly they can encapsulate the processes and practices of the organisation, and there are a number of advantages in using them:
- the organisation's processes can be described in language that managers and staff (and programmers) can all understand
- training costs and time can be reduced
- process dead ends and duplications can easily be identified and rectified
Of course, it must be remembered that enough time must be set aside to produce the business rules, and that's because:
- the first time that many organisations consider their processes is when the business rules are to be put in place
- no two departments will ever use the same processes (even if they think they do)
However, once all of those issues have been resolved then the programmer can start incorporating the business rules into applications.
Identifying the Business Rules
Before going near any software, the programmer must understand the business rules to be used. The key to this is to have access to people that:
- have a broad knowledge of the business process, or enough people with in depth knowledge of any distinct areas within the process
- have the power to resolve any issues raised by the business rule analysis
- have the respect of other potential users of the proposed application
At the end of the process the programmer will (hopefully) have a mapping of the organisation's process (or at least the process containing the business rules) and they can then consider including these in an application.
To Hard Code or Not to Card Code Business Rule
At its simplest level a business rule is just a set of if..then..else statements, for example:
The programmer can easily build this into any programming language. However, there is a potential problem. Business rules tend to be fluid, for example:
- regulations affecting the organisation may change
- the structure of the organisation may change
- the business rules themselves may be updated or optimised
With this in mind it is a bad idea to hard code the business rules into an application. The users really won't appreciate yet another update because their manager has realised that they've missed out a key step (or needs a new one adding in). Instead it is better have design the application so that it can access business rules that reside outside of the application itself. If this is done then it is possible to update the business rules without having to change the application.
Possible Solutions for Business Rules
The business rule programmer has many ways in which they can create a two-tier application. For example, they may:
- use AJAX to access business rules on a server (see A Simple Introduction to Ajax)
- use stored functions and stored procedures on a database (see MySQL Stored Procedures and Functions)
Or they may choose to use applications that specialised in making business rules easy to write (see How to Create a REBOL Dialect). But, whichever method they decide upon they must:
- understand the process
- have the authority (or has someone on board who does have the authority) to resolve any issued
- use a two-tier system for the application and business rules. The business rules should not be hard coded into the application
And by doing this the programmer will create a business rule application that is powerful, adaptable and will aid the day to day lives of their users.
 |
