IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects andDevelopersNovember 2009IBMIBM WebSphere ILOG Business RuleManagement Systems: The Case forArchitects and DevelopersBrett StinemanProduct Marketing, Business Rules Management (WebSphere),Application and Integration Middleware Software,IBM Software Group

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 2IntroductionContentsIntroduction2What is a Business Rule ManagementSystem?3Roles Involved in Business RuleManagement4Separation of Application and RuleManagement Life Cycles4Introducing the WebSphere ILOG BRMS 7BRMS Development Environments8BRMS Rule Management Environments 11Decision Validation Services:Integrated Rule Testing and Simulationfor Developers and Business PolicyManagers14Rule Execution Server: Managed,Monitored, High-Performance RuleExecution for the Enterprise18Conclusion20In a world where business agility—the ability to quickly and efficientlyadapt to changing markets, competitive actions, regulatory and legislativemandates, or other challenges—is a hallmark of successful organizations,information technology plays a critical role. In fact, the role of IT systemshas become intertwined with how organizations operate, enabling significantproductivity and efficiency improvements.But at the same time, these improvements have come at a cost. For manyorganizations, their operational systems are a black box to the people whodirect business strategies and policies. They entrust the implementation ofpolicies within IT systems to their technical development staff, and theyfrequently expect the implementation to be handled more rapidly than canbe feasibly accomplished. This frequently results in frustration for boththe line-of-business (LOB) groups and IT: LOB wants better visibility ofthe logic that drives their systems, along with the ability to make changesas needed; IT wants to maintain control over systems, while being able tohand off certain maintenance aspects of these systems tied to the businessdomain and knowledge, so they can focus their resources on adding newfunctionality and building improved systems.The focus of this paper is to explain how a business rule management system(BRMS) can help organizations become more agile, while meeting the needsof both LOB and IT. For enterprise architects and application developers,this paper will provide an overview of how the IBM WebSphere ILOGBRMS offerings can help them build highly flexible solutions that providetheir LOB constituents with improved access, insight and direction over thedecision logic which drives the behavior of critical business systems.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 3What is a Business Rule Management System?A Business Rule Management System (BRMS) is an integrated application development, maintenance and executionplatform. It enables organizations to define, deploy, monitor and maintain highly variable and complex decision logicused by operational systems. This decision logic is also referred to as “business rules”―you can think of conditionalstatements used in activities such as pricing, underwriting, eligibility approvals, product recommendations, anddeterminations of straight-through processing vs. manual intervention (for example, insurance claims). Business rulesare typically found inside application code in the form of if-then-else statements, or they might be defined in processmodels. They can also be stored in documentation (for example, procedural manuals)—they may even be undocumented,in the minds of the subject matter experts who have to be involved in specific operational situations.A BRMS allows decision logic to be centralized and managed as an enterprise asset, so it can be easily understood,maintained and reused across the organization. By externalizing rules from application code―and other places whererules exist―business experts can be more closely involved in the definition, maintenance and management of decisionlogic, reducing the amount of time and effort required to update production systems, and increasing the organization’sability to respond to changes in the business environment.A BRMS includes three primary components: Rule Repository: allows rules to be managed separately from the systems that utilize them, making it easier to understand and update decision logic,along with consolidating rules from disparate applications and information silos so that they can shared and reused across the organization. User Tools: provides both IT and LOB with functionality for defining and managing decision logic, while also supporting collaboration between themfor application development and maintenance. BRMS tools should offer specific environments and capabilities to meet the needs of various technical andnon-technical roles involved in the rule management life cycle. Runtime engine: enables production systems to access and execute decision logic managed within the BRMS; the “rule engine” allows complex andinter-related rules to be executed based on specific process or transaction context, using a combination of data inputs, sets of applicable rules and execution algorithms in order to provide outputs back to the invocation from the requesting system.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 4By implementing a BRMS, an organization is able to effectively deal with the problems associated with traditionalembedded decision logic. The organization gains visibility and access to business rules, along with the ability to moreeasily define and automate decisions in operational systems. In addition, a BRMS allows systems to behave with moreintelligence, precision and consistency, determining highly customized decisions if the situation allows, while alsoenforcing standardization if required (for example, regulatory compliance requirements).Roles Involved in Business Rule ManagementApplications constructed around a BRMS place the ability to author, test and manage the rules that implement businesspolicies directly into the hands of LOB personnel. Policy changes can be driven exclusively by business imperatives, andthus evolve independently of the application development cycle that too frequently constrains change in informationintensive businesses. This also frees application architects and developers to focus on areas where they can providevalue through their expertise, such as implementing updated architectures for their enterprise applications, improvingdata management and enterprise application integration, and creating improved IT systems, rather than spendingsignificant time and resources on repetitive activities to implement changes to business policies.In order to provide these benefits, a BRMS must satisfy the divergent requirements of the different stakeholdersinvolved in creating and maintaining rule-based systems: Architect: responsible for assuring that the application design meets long-term business needs for functionality, efficiency and performance. Developer: creates and tests the application, as well as iteratively adding functionality to the application as required. (Developers also build test scenarios, some of which can be used by LOB in testing or simulating rule changes and some of which are used to run comprehensive regression tests prior todeploying each version of a rule application into production.) Business Analyst: responsible for modeling the business domain and business rule vocabulary. (Business analysts generally act as the bridgebetween the business and IT departments, translating business policies into a formal specification acceptable to developers, and validating the formalspecification with policy managers.) Policy Manager: LOB subject matter expert responsible for translating business policies into detailed business rules, and managing those rules onan ongoing basis. (Policy managers, either on their own or in conjunction with business analysts, also test rules for correctness and their overall businessimpact.) System Administrator: manages and monitors applications in production to ensure applications achieve performance and availability goals.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 5Separation of Application and Rule Management Life CyclesWho is responsible for managing changes to rules, and how frequently can changes occur? The answer depends onwhere you work within the organization. Business policy and decision automation within the enterprise is generallydriven by two competing sets of imperatives, which can be broadly characterized as the business rule life cycle and theapplication development cycle. This is illustrated in Figure 1 below. In the top half of the diagram, application releasesare driven by major requirements and functionality changes. These releases are driven by architects, developers andbusiness analysts following a traditional application development cycle of requirement specification, analysis, design,development, testing and deployment.Figure 1: Application Development and Business Rule Life Cycles

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 6However, in most situations, business rules change according to different imperatives. They are driven by businesspolicy changes that represent variants or extensions of the established functional base of an application’s currentrelease. For example, an application may require new or updated rules to establish specialized discounting for a newcustomer or territory, ensure adherence to a contractual obligation, or launch a new promotional program. Thesetypes of changes are shown in the lower half of the diagram, and their implementation assumes a stable application onwhich the policy is elaborated, requiring a shorter, more focused cycle of authoring and testing by the policy managerand more rapid deployment to production. Depending on the needs of the organization and the testing procedures forchanges, the business rule life cycle can take as long as a few months (when rule changes are aggregated and deployedat set intervals) or as little as a couple of hours (for a single, high-priority rule change) to complete. In both cases, rulechanges can occur asynchronously to the application development cycle.In some cases, the authoring and maintenance of business rules require an extension of the rule vocabulary and theunderlying object model upon which the rules are structured. Depending on the extent and scope of this type of change,additions may fall into either the application development or rule management category.The result of all this is that business rules “live” simultaneously in both the application development world and thebusiness rule life cycle, and that policy managers and application architects, analysts and developers need specializedtools that recognize and accommodate this reality.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 7Introducing the WebSphere ILOG BRMSNow that the basic concepts behind a BRMS have been established, the remainder of this paper will explain how IBMenables organizations to build agile, flexible rule-based applications through its WebSphere ILOG BRMS productfamily, which is comprised of two principal BRMS offerings: IBM WebSphere ILOG JRules BRMS and IBM WebSphereILOG Rules for .NET BRMS. As can be seen in the following diagram, each BRMS has platform-specific products aswell as a shared set of products and capabilities that can be leveraged by both BRMS offerings.Figure 2: IBM WebSphere ILOG BRMS Offerings

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 8The combination of functionality in each BRMS provides rich rule application development and maintenancecapabilities integrated into standard software development tools for technical users, and specialized rule authoringand management tools for business policy managers working in the rule management life cycle. In addition, systemadministrators have tooling designed for their specific needs in managing and monitoring deployed production ruleapplications.BRMS Development EnvironmentsBoth JRules and Rules for .NET provide a rule application development environment called Rule Studio. The JRulestechnical environment is an Eclipse-based integrated development environment (IDE), while Rules for .NET’sdevelopment environment is integrated into Microsoft Visual Studio. Both IDEs permit IT professionals to applyfamiliar skills and corporate best practices to construct state-of-the-art business rule applications. Each version of RuleStudio provides a “One-Stop” rule development environment: all the artifacts and operations needed to create andmaintain a rule application are included. From within Rule Studio, a developer can: Create a logical business object model (BOM) for the application, and map it to a customized, domain-specific rule vocabulary Associate the BOM to an execution model of Java or C#/VB.NET classes and XML schemas Create a metadata model for rules (application-specific data fields beyond standard metadata; for example, custom rule status properties) Create business rules in a natural language syntax, which can be expressed in one or a more localized versions (for example, English or Spanish) Create rules in the form of decision tables and decision trees Create technical rules in a platform-specific syntax Specify packaging of rules into executable rule sets (corresponding broadly to a single policy-driven decision within the application.) Separate rules in a rule set into tasks, and specify a rule flow to orchestrate the execution of these tasks Create default applications that invoke the rule sets for test purposes

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 9 Deploy rule sets to their respective execution server environments for test or productionFigure 3: Rule Studio (JRules, Eclipse-based)Figure 4: Rule Studio (Rules for .NET, Visual Studio-based)

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 10Within both BRMS offerings, rules are written in reference to a Business Object Model (BOM). This is an abstract,object-oriented representation of the information model for the application or enterprise, along with natural languagelike verbalizations of the classes and members. For projects that need to integrate rules into an existing application withJava/.NET classes or XML schemas that already define its data structures, Rule Studio can import execution models,along with their classes and schemas, and create a corresponding BOM and verbalizations in a few simple steps.Rule Studio does not insist that the execution model and BOM be identical images of each other. The “BOM toexecution” modeling layer (B2X) permits divergence between the abstract business object model and the concreteexecution model. Business rules can be written in the natural language syntax verbalization of a BOM that representsthe closest policy analogy to the way business users think about their problem space and still be executable on anexecution model that meets the needs of the application architecture, even when the BOM and execution model evolvesomewhat differently.As testing is a key part of application development, Rule Studio provides the ability to integrate with standard, platformspecific testing tools such as JUnit and NUnit. When a test fails and the developer needs to “dig into the application”to find out what went wrong, Rule Studio for Java provides integrated co-debugging of rules and Java code that letsthe developer launch the application or a remotely running instance of the application in debug mode, and use thestandard Eclipse debugging facilities to set breakpoints in Java code. The developer can examine Java’s memory whilesimultaneously setting breakpoints in rules, and examine the rule execution agenda and working memory (both Javadebugging information and JRules rule debugging information are displayed in the same Eclipse debug perspective).For Rule Studio for .NET, a trace utility is available as an add-in function for debugging.Both versions of Rule Studio provide integration with source code control systems that support their respective IDEplatforms, allowing rule-based applications to be securely stored, shared, branched and versioned.Finally, both versions of Rule Studio can publish rule projects to IBM WebSphere ILOG Rule Team Server (the Webbased, business-user rule management environment) or update local copies of a rule project from Rule Team Server.Developers can also access prior versions of rule projects stored as baselines within Rule Team Server.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 11Rule-based application development is the foundation for providing organizations with new levels of flexibility inmanaging rules independently from the business systems that they support. Rule Studio delivers comprehensive ruleapplication development through a full-featured set of tools integrated within developers’ preferred IDEs.BRMS Rule Management EnvironmentsThe rule authoring and management environment for business analysts and policy managers is called IBM WebSphereILOG Rule Team Server (RTS), a thin-client Web-based environment with a scalable, high-performance enterpriserule repository. RTS enables business policy managers to take charge of authoring, managing and validating dynamicbusiness policies.The repository provides the BRMS with a central “source of truth”, addressing the specific needs of rule-based businesspolicy management: It is designed to store multiple independent or dependent rule projects and their histories, scaling to large numbers of concurrent users working on thesame or different projects and managing hundreds of thousands of individual rule artifacts. Every project is a complete, self-contained entity containing the project BOM, vocabulary and all the rule artifacts. As artifacts evolve with an application,the repository maintains all prior versions of each artifact in an accessible and browsable format, providing a complete audit trail of policy implementations.The repository also maintains “baselines” of rule project states, allowing any previous project state for which a baseline has been created to be recalled forexamination. The current project state can be “rolled back” to any previous baseline. The repository supports automatic rule-level locking, as well as user-managed persistent locks. The repository is fully relational and supports all major database vendors. It is accessed under transactional protection, giving the repository the full benefitof the protection offered by enterprise relational databases. Both Java and .NET rule projects can be stored and managed in the repository.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 12Policy managers author, modify, manage and deploy rules from the repository through the RTS environment. ThisWeb-based application gives policy managers a comprehensive rule editing, management and deployment facility. Keytechnical features of the environment include: The RTS application is a clusterable J2EE application ready for deployment in a self-contained enterprise application archive. Prebuilt deployments formajor application server vendors and versions are provided. As a J2EE application, RTS participates in role-based J2EE authentication and authorization. Integrating permissions from an enterprise directory serviceis handled by standard application server-level integration. Each RTS user can be provided different levels of access and control of the projects and ruleswithin the repository. RTS defines and enforces fine-grained permissions on rule artifacts using either a permissive or restrictive default model. From within RTS, policy managers can author, modify and organize rules, rule templates, decision tables and decision trees. In addition, they can createand browse baselines, and query for, report on and deploy rules. The full history of each rule is accessible to policy managers, and facilities are providedfor visually comparing two versions of a rule or decision table. User-definable views allow policy managers to see rules in the organization that best suit thetask immediately at hand, while preserving full navigability of the overall project repository. RTS has a rich application programming interface (API) for the rule repository, and also provides predefined extension points for customization of RTSfunctionality. Rebranding of RTS with customer logos is supported.Figure 5: Rule Team Server

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 13The synchronization capability between both the JRules and Rules for .NET versions of Rule Studio and RTS allowsdevelopers and policy managers to maintain separate views of business rules in accordance with the needs of theirrespective responsibilities, while ensuring that both sides have access to the latest version of a rule project. For example,once the initial version of a rule application goes into production, policy managers can change and add to the policiesrepresented as rules in the application as new policy initiatives dictate, while developers work independently on anew version of the entire application that may expand its overall scope or update its core functionality. Developerscan synchronize with the repository as needed until the new version is ready for rollout, at which time the developerspublish an entirely new application and set of rules that incorporates all ongoing changes from the production rule set.IBM WebSphere ILOG Rule Solutions for Office is an alternate rule authoring and editing option for non-technicalparticipants in the rule management life cycle. Rule Solutions for Office allows rules to be maintained in the familiarMicrosoft Office Word and Excel desktop applications, while at the same time enforcing the underlying applicationrequirements of the systems that will use these rules in the production environment.By loading a lightweight plug-in for Microsoft Office (2007), business users can work with file-based “ruledocs” in aguided manner, leveraging rule editors with auto-completion assistance from the IBM ILOG Intellirule technology.Since the ruledoc contains the business object model for the associated project of the rules, users have access tocustomized business vocabulary, and rules are automatically validated for correct logic and syntax.Figure 6: Rule Solutions for Office (Microsoft Word-based Ruledoc)

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 14Rule Solutions for Office extends and facilitates rule management throughout the enterprise by providing the followingbenefits: Specialized toolbars are incorporated within Microsoft Office Word and Excel, adding viewing panes and lists that facilitate rule authoring and validation. Structured rules and unstructured associated information can be combined together for documentation purposes. Ruledocs can be downloaded from the BRMS and edited offline (ruledocs are created using RTS or Rule Studio for .NET, which allows specific rules orentire rulesets in a project to be extracted from the repository in a ruledoc format). Ruledocs contain full rule project metadata, allowing them to be synchronized with the BRMS repository—completed rule changes can be easily uploadedto the repository through RTS for testing, simulation, versioning and deployment.From the perspective of the architect or developer of a rule application, providing support for rule authoring andmanagement to non-developers is a key function of a BRMS, enabling technical and non-technical personnel tocollaborate and close the loop between the application development cycle and the business rule life cycle.Decision Validation Services: Integrated Rule Testing and Simulation for Developers and Business Policy ManagersOf course, there is more to both application development and rule management than just authoring andsynchronization. Rules must be tested, both within the context of application development and as business policyimplementations. IBM WebSphere ILOG Decision Validation Services (DVS) is an optional product offering for theJRules BRMS, providing integrated test, simulation and audit capabilities that apply realistic scenarios to determine theeffects of business rule changes on production systems: Unit and regression testing to ensure rules execute as expected Functional testing to execute rule sets with data and capture the results Simulation to measure or verify the business results of rule sets against either historical or test data Rule execution auditing to review decision outputsBecause business rules are operational artifacts, testing and validation of rules are important for both the applicationdevelopment cycle and the business rule life cycle. DVS provides rule testing functionality for both developers workingin the application development context, and policy managers authoring and validating rules as part of the business rulelife cycle.

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 15In addition, DVS provides facilities for simulations in which the results from a modified “candidate” rule set executedagainst a suite of test cases is compared to a baseline rule set running against the same data; simulations enable LOBpolicy managers to understand how rule changes affect business systems in terms of the business objectives of theorganization by allowing for specification of key performance indicators (KPIs). As an example, a DVS simulation coulduse the previous 12 months of data to determine if a rule change increases or decreases the number of automatedapprovals for a government social service, along with a comparison of the results to the target accept/reject ratio.DVS is a modular, extensible framework for all aspects of creating rule test and simulation scenarios: It provides a set of configuration and test execution components integrated within the Rule Studio for Java IDE. Developers create scenarios to be applied tovalidate the execution of rule sets, assembling these into suites of scenarios, as well as configuring the Scenario Service Provider (SSP), a server component responsible for executing test suites. Developers can also use DVS to invoke tests from within Rule Studio using the JUnit testing framework. The data that defines a scenario can be provided to test suites in the form of a Microsoft Excel spreadsheet, allowing developers to create test suite templates that business users can populate with input and output data specific to their rules and business functions. In addition, extension points are providedto allow developers to map scenarios to existing relational database structures if needed. Other DVS extensions include creation of KPIs, and specification of custom reports for filtering or detailing the results of a test or simulation.Figure 7: Decision Validation Services (Rule Studio Test Scenario Configuration)

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 16For business users, DVS test and simulation scenarios can be run from within Rule Team Server, with result outputsprovided through the RTS interface and the option of sending the results to Micosoft Excel. IT has the ability toincorporate more extensive tests as part of the rule life cycle, but the first level of testing and validation can becomethe responsibility of the LOB functions, empowering them to be more involved in their business systems and helping todecrease the overall workload on IT.Figure 8: Decision Validation Services (Rule Team Server Simulation Results)

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 17Another capability of DVS is the Decision Warehouse, a rule execution audit and reporting feature that is availablethrough the JRules Rule Execution Server administration console. The Decision Warehouse allows rule execution datato be queried against a number of different parameters, and for the results to be drilled down to the individual rulesfired. The results also provide Rule Team Server links to repository, detailing the exact version of each rule fired at thetime of execution. By providing this information, it is possible to gain valuable insight into how operational decisionsoccur in the production environment and to selectively perform audits as required by internal or external compliancemandates.Figure 9: Decision Validation Services (Decision Warehouse)

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and DevelopersPage 18By providing a way for both policy managers and developers to test and validate the execution of business rules,DVS enhances productivity in the creation, management and governance of business rules. DVS enables IT to defineappropriate tests and simulations, and then provide the functionality to non-technical users so that they can verify thecorrectness of any rule changes, as well as understand the overall business impact.Rule Execution Server: Managed, Monitored, High-Performance Rule Execution for the EnterpriseArchitects and developers of business rule applications must out of necessity be concerned about the execution ofbusiness rules. Business policies are automated by integrating all the execution elements into a rule application―in orderto actually implement policy automation, rules must be executed as part of the application’s transactiona

IBM WebSphere ILOG Business Rule Management Systems: The Case for Architects and Developers. . data management and enterprise application integration, and creating improved IT systems, rather than spending . manages and monitors applications in production to ensure applications ach