Abstract
Business Rule Management System (BRMS) is a software system that can be specified as a bridge between business and IT, which must have business
rules and decision making parts. However, the need for separating Business Rule Management (BRM) from the rest of information system development process is not trivial. There exist some attempts to separate the decision making from classical software development, but most often, BRMS should be used at the backend and as a standalone system. This prevents typical BRMS to be used in multiple tiers such as presentation tier and content management tier. Another difficulty lies in the integration of legacy decision making sources such as existing business logic, Web Services, and database management systems.
In this paper, old and current approaches to business rule implementation are discussed. And a special focus is given to "using domain specific modelling for business rule management systems" as a future work.
1 Introduction
Faster reactive and proactive time to market (we can call it “Business Agility”), is the most common request from all of the clients for any kind of business, since information systems (IS) are in the core of them. Business rule management systems responded this request by providing the “experts define, developers use” approach. This approach also reduced faster solutions to the specified problems and increased control over implemented decision logics.
Although, developing applications without any programming effort foresighted [10, 11], there has not been any solution for this yet. We all know that even when minor application changes are required, we still have to get a developer to do the job. On the other hand, communication obstacles between the developers and business professionals are often found responsible for many IS project failures [8, 9, 12].
Since it is argued that business rules have a direct relation between project scalability by defining the business environment [1, 3, 4, 6, 9], business rules are found very easy to manage and maintain the projects, if represented properly.
2 What is a Business Rule?
Before going into deep discussion on business rules let make it clear what they are. According to [1], these terms could be defined as:
Business Policy: A general statement of direction of an enterprise.
Example:
Only students that fulfil all the conditions required are allowed to register to an exam [2].
Business Rule Statement: A declarative statement of structure or constraint, which the business places upon itself or has placed upon it.
Example:
If a student has failed the examination more than three times, the board of examiners must be convened. In addition, the student must pay for the examination [2].
Business Rule: A statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behaviour of the business. It is atomic in that it cannot be broken down or decomposed further into more detailed business rules. If reduced any further there would be loss of important information about the business.
Example:
If a student has failed the examination more than three times, the board of examiners must be convened [2].
As shown in Figure 1[2], business rules are based on business rule statements, which are further based on business policy. Business rules are expressed formally in formal rule statements that follow some formal expression type.
Figure 1: The origin of business rules
3 Business Rules: Old and New
In order to point the difference between old and current, we must handle the implementation of business rules over two distinct perspectives: approaches to implement business rules and methods for applying business rules.
3.1 Approaches
The old and new approaches can be compared as follow [5]:
The Old Way 1: Rules are buried deep in the system code of a single application.
The New Way 1: Rules are written in a simple rule language and managed separately from system code.
The Old Way 2: Rules can be executed only by the application they were originally written for, in the manner they were originally coded.
The New Way 2: Rules can be used in many flexible ways to reach decisions that can be carried out by virtually any application or business process.
The Old Way 3: Rule changes, which require reprogramming and can even involve reverse engineering, mean queuing up for IT help.
The New Way 3: Rule changes can be made quickly and inexpensively by business users without requiring help from IT.
The Old Way 4: New application development takes a long time because programmers must try to anticipate and code for every possible combination and interrelation of variables and conditions. Given today's complex business environment, that's just not possible any more, so long development cycles are soon followed by extended enhancement cycles.
The New Way 4: Rules management solutions enable new applications to be developed quickly, without the need to anticipate every possible decisioning scenario. As new situations and information emerge, enhancements are made by business users. New rules can be added at any time, without interrupting operations and with the rules engine sorting out how and when to execute them.
The Old Way 5: Adding rules to legacy systems can be risky, given the fragility of some of these systems and the complexity of trying to make them perform functions they were never designed to support.
The New Way 5: Rules management services can be called by existing applications. This enables legacy applications to be reinvigorated with new capabilities without actually having to mess with them.
The Old Way 6: Extending decisioning across new channels usually requires building a duplicate application, from the ground up, to run in the new environment.
The New Way 6: Decisioning applications can be written once and deployed without modification across most any operating environment. IT can deploy and maintain a single application across multiple channels.
The Old Way 7: Development and deployment are often delayed because of difficulties translating complex business processes and requirements into code. There's too much opportunity for something to get lost between what the business people say they need and how the programmer interprets that in rules. It usually takes numerous revision cycles to get it right.
The New Way 7: Decisioning applications and services are developed usually by IT or a technically inclined business analyst--using a rules language that closely approximates the way business people talk about policies. Little interpretation is needed, so development goes smoothly. Developers can also let nontechnical business users write many of the rules themselves using graphical trees, tables or Web forms.
3.2 Methods
3.2.1 Old Methods [2]:
The old methods can be summarized into two categories [2]:
Parameterisation:
Parameterise the application and its components. These parameters may be then set in a configuration file or in a database, and can be managed through a configuration utility. Doing so, the application can be adapted to different environments and situations just by parameter settings, without any programming effort [7].
Database Triggers and Database Procedures:
Relational Database Management Systems (RDBMS) provide so called “triggers” that have ability to execute actions, immediately before/after particular events occur. These events occur when a record is inserted into a database, when a record is modified, or when a record is deleted from the database. Actions executed by triggers are written in Structured Query Language (SQL) and are stored either as the trigger body, or as database procedures.
The characteristics above make triggers convenient for implementation of business rules. For example, by using "before-insert" trigger the record can be checked (and refused if violates any business rule) before it is actually inserted. Since the implementation of the business rules (formal rule statements - see fig. 1) resides in the database itself, modifications are application independent and can be performed without accessing the application logic.
3.2.2 New Methods:
The new methods can be summarized into three categories [3]:
Database-independent tools: business rules are implemented within a database, using triggers and stored procedures. However, they are generated automatically and managed by the development and not database tool. Figure 2 shows a sample demonstration of it [2].
Figure 2: From Rules to Application
Server-based tools: business rules that are created by a development tool become middle-tier application services and reside on an application server. Figure 3 shows a sample demonstration of it [2].
Figure 3: Rules Processor: Middle-Tier Service
Rule-based systems: instead of specifying constraints on specific data elements or tables, a logic-oriented approach captures the higher-level business logic and rules associated with different situations. At run-time special engines are used to process the rules and to generate appropriate responses. Figure 4 shows a sample demonstration of it [2].
Figure 4: Rule-based System
In here, using a rule based system is stand out with some benefits according to other methods. Especially chance for an incremental development and rapid prototyping and understandable units of business process can be some examples of these benefits. Unlike in traditional programming, changes to the rules do not require any recompilation, re-linking and re-deploying.
4 Future Work : Domain Specific Languages and Business Rules
The idea “The more business specific logic you can abstract out of an application, the less programmer involvement you will need to alter the business logic.”[14], points a solution for a better business rule management system: More abstraction in BRMS.
Separating business rule management from the rest of information system model is not so easy however, it becomes a need for developing more effective business rule management systems with less cost.
In here Domain Specific Modelling and Domain Specific Languages come with lots of similarity and ease. First of all let’s explain what they are.
DSM is a kind of software engineering methodology for designing and developing systems, most often IT systems such as computer software. The main core of this modelling is raising the levels of abstraction and improvement of productivity. This is basically done by hiding today's programming languages more and more, getting rid of its complexities at the first glance of production. On the other hand, DSL is a programming language or executable specification language that offers, through appropriate notations and abstractions, expressive power focused on, and usually restricted to, a particular problem domain [13].
Now, when we compare domain specific languages with business rules then we can easily see not only that the domain specific approaches can be very efficient with business rules but also the abstraction can be easily made as James Taylor also think in [15].
The comparison table is as seen in Table 1:
| Needs For DSL: | How BRMS handles: |
| DSLs must be directly executable on a specific platform. | Business rules management system handles this. |
DSLs must be extensible by existing GPLs [General Purpose Languages] | Most BRMS products do this inherently |
DSLs must be understandable by both developers and domain experts. | This, of course, is a key value of using a business rules approach and a BRMS |
DSLs need models | BRMSs have business rules can be specified as domain models |
Table 1: DSL in BRMS
5 Conclusion
In this paper, the old and new ways of implementing BRMS are briefly discussed and because of the similarities and ease of usage, using DSM with BRMS is suggested to build a better BRM based system at the end.
The aim of the paper was searching the state-of-the-art of BRMS and looking for new opportunities for BRMS. And in Table 1, we saw that it is possible to put DSL into BRMS. On the other hand, we decided BRMS and DSL, two of them together, is a good way of abstracting the rules of BRMS.
Of course there are some disadvantages of using DSL with BRMS. First of all, it cannot be useful for all types of BRMSs. For example, if the system is not big enough, using DSL can be irrelevant and development part can take time more than usual. However, there can be other problems in development part, such as the need of DSL knowledge. Although it can take more time than usual development because of learning DSL, the development of the system can be easier and faster than expected.
With the rapid globalization of companies, the globalization of software development has become a reality. Many software projects are now distributed in diverse sites across the globe. The distance between these sites creates several problems that did not exist for the co-located teams. Problems in the coordination of the activities, as well as in the communication between team members emerge [16]. It seems that BRMS is a promising way of implementing global software development. The opportunities that BRMS and DSL provide, can be the solution for the problems that GSD has.
6 References
[1] GUIDE International Corporation, Guide Business Rules Project, Final Report, revision 1.2, October 1997,
http://www.businessrulesgroup.org
[2] Bajec, M., Krisper, M., Rupnik, R. (2000), "Using business rules technologies to bridge the gap between business and business applications"
[3] Michael Barnes, David Kelly, Play by the Rules, Byte (Special Report), June 1997.
[4] John R. Rymer, Business Rules: A Promising Technique, But Not a New Paradigm, Giga Information Group, 1997,
http://www.ilog.com/products/rules/analyst.cfm
[5] Business Rules Management - How it works
Fico Inc,
http://www.fico.com/en/Products/DMTools/Pages/Business-Rules-Management.aspx
[6] Judith Hurwitz, When Rules Meet Development, DBMS, January 1997.
[7] Neuron Data, Inc., Architecting For Change: The Rule-Engine Proposition,
http://www.neurondata.com
[8] Lawrence, B., Designers Must Do the Modelling! IEEE Software, March/April 1998, pg. 30-33.
[9] The Standish, Few IS Projects Come In On Time, On Budget, Computer World, 12 Dec. 1994, pg. 20. Original source: The Standish Group International, The High Cost of Chaos, http://www.standishgroup.com
[10] Paul Dorsey, Business Rules – The Quest for the Holy Grail, Dulcian Inc., www.dulcian.com/magazines
[11] Martin James, Application Development Without Programmers, Savant Research Studies, 1981.
[12] Jeffrey A. Hoffer, Joey F. George, Joseph S. Valacich, Modern Systems Analysis and Design, (second edition), Addison-Wesley, 1999.
[13] A. v. Deursen, P. Klint, and J. Visser, "Domain-specific languages: An annotated bibliography." ACM SIGPLAN Notices, vol. 35, no. 6, pp. 26-36, Jun. 2000.
[14] Jay Fields, Business Natural Language
http://blog.jayfields.com/2006/10/bnl-introduction-update.html
[15] James Taylor, Business Rules, Domain-Specific Languages and Models
Everything Decision Management
http://jtonedm.com/2008/08/12/business-rules-domain-specific-languages-and-models/
[16] Cleidson R. B. De Souza,Global Software Development: Challenges and Perspectives
