ILOG JRules is a Business Rule Management System (BRMS) that allows both business and IT users to manage the rules that drive business.

As companies rely more and more on information technology (IT) to manage their business, IT departments need to develop more complex applications and simultaneously accommodate an increasing rate of change in the applications they support.

Often, the implementation of the company's business policy within these applications becomes too complex, voluminous, and fast changing for a traditional software architecture. When this happens, an enterprise Business Rule Management System (BRMS) provides solutions to make this management more efficient, both for developers and for the business users of the applications.

With a BRMS, developers and architects can extract the business logic from the traditional code of an application. When business policies are hard-coded into an enterprise application, the process of updating the system requires specialist programming staff, puts the stability of the system at risk, and can take a long time. By externalizing the business logic from a business application with business rules, IT users can develop and run the business logic independently of the application.

A complete implementation of a BRMS can go even further and enable business users to manage business policies directly, with limited dependence on the IT department. The degree of dependence can range from limited review by business users of policies implemented by IT, to complete control over the specification, creation, testing, and deployment of the policy by business users.

From Business Policy to Business Rules

Business rules are an expression of business policy in a form that is comprehensible to business users and executable by a rule engine. From a business perspective, a business rule is a precise statement that describes, constrains, or controls some aspect of your business. From the IT perspective, business rules are a package of executable business policy statements that can be invoked from an application.

A business policy may be expressed as several business rules. Business rules formalize a business policy into a series of "if-then" statements. Here is an example of the kind of business policy you may be familiar with, and that could be expressed as business rules:

Customers who spend a lot of money in a single transaction should be upgraded.

The process of capturing rules consists of formalizing the vocabulary required to express the policy as a conceptual object model, and representing the logic of the business policy as if-then statements.

Once this has been done, the above business policy may be implemented with the following business rule in JRules:

In this form, the business logic can be packaged as an executable ruleset and called from the application code as a single entity. Therefore changes to the business policy do not require changes to the application code.

Once an application is adapted to use business rules to implement business policy, the rules representing the policy can be written by developers using developer tools, or by more business-oriented users such as business analysts or the business users themselves (referred to as policy managers in this documentation).

Synchronized Business and IT Cycles

JRules provides an environment for designing, developing, and deploying business rule applications. A business rule application is any application that uses the facilities of a BRMS to externalize business rules out of application code. The IT cycle consists in developing and maintaining this infrastructure. Once the infrastructure is set up, distributed business teams can start collaborating through a Web-based environment to create and maintain business rules.

In a BRMS, the business rule management and application development life cycles can evolve in parallel. Business policies can evolve as required, without putting an extra load on the development of the application. Each time the application evolves, the business policy implementation synchronizes with the application.

With this separation, business policy and application architecture can be managed asynchronously. For example, application developers may work in a semi-annual cycle in which a new application version is developed every six months in response to changing application infrastructure (for example, JDK and RDBMS versions) and additional core business requirements. At the same time, policy managers can work on a weekly cycle in which a new version of the business policy is delivered in response to an evolving market, new customers, or changing regulatory environment.

In addition to working on different timelines, IT and business users expect to work with different tools, reflecting their different skill sets and views of the application.

For example, developers are accustomed to the world of Java code. They use source code management systems to work simultaneously on separate copies of a project without interfering with each other.

Business users, on the other hand, do not concern themselves with the details of application development, but are interested in defining, testing, and managing well-defined decisions that implement business policy represented as business rules within the application. They therefore require tools that simplify organizing, searching, and authoring rules within the context of the overall policy.

With developers working in their environment at their own pace and business users doing the same, the work of both can be synchronized and merged easily.

Finally, both IT and business users require access to a rule execution environment in order to deploy rules. For developers, rule deployment is part of application testing. For business users, rule deployment is part of the specification, validation, and rollout to production of new and changed policies.

Related Sections