Drools

1 Business Process Management

Business process Management (BPM) solutions are frameworks used to develop, deploy, monitor, and optimize multiple types of process automation applications involving both people and systems. Applications like transaction processing that involve multiple systems but straight through processing which does not involve human interaction. BPM can also be used as a back end application, which can be automated to achieve greater efficiency (Business Functions like human resources, order management, payables etc.,) and effectiveness, there by increasing the organizations responsiveness and profitability.

BPM Solutions share many components like Process Design Tools, Process Engines, Integration Components, and Measure and Performance Tools.

The Characteristics of Best BPM solutions are:

• 95% Process and Related Data Capture. All metrics of a given process application must be captured in audit logs that can be easily mined, a capability native to all BPM products. Advanced Options to capture data from applications that uses the process.
• 95% Process Monitoring. Once process metrics are captured, data must be displayed in real time, in a graphic format so that a supervisor or manager can identify bottlenecks and exceptions at a glance.
• 95% Process Analytics. Process data must be available for sophisticated OLAP-style analysis.
• 95% Manual and Automated Process Change. The solution should provide manual methods within the same interface, for a supervisor to take immediate action (for example, change a process or move work). In addition, the solution should offer automated actions that can be taken based on preset parameters and triggers that require no human intervention.
• 95% Process Simulation and Modeling. The solution should be able to provide simulation and modeling of potential process metrics, with the goal of allowing business users to quickly make changes in the process design to deliver additional efficiency.

1.1 Workflow Systems Overview

Workflow is often associated with BPM, which is concerned with the assessment, analysis, modeling, definition, and subsequent operational implementation of the core business processes of an organization (or other business entity).

Workflow

• Definition - The computerised facilitation or automation of a business process, in whole or part.

Workflow Management System

• Definition - A system that completely defines, manages, and executes "workflows" through the execution of software whose order of execution is driven by a computer representation of the workflow logic.

At the highest level, all WFM systems may be characterized as providing support in three functional areas:

• Build-time functions-concerned with defining and possibly modeling the workflow process and its constituent activities.
• Run-time control functions- concerned with managing the workflow processes in an operational environment and sequencing the various activities to be handled as part of each process.
• Run-time interactions with human users and IT application tools for processing the various activity steps.

Figure 1 illustrates the basic characteristics of WFM systems and the relationships between these main functions.

Figure 1 - Workflow System Characteristics

Build-Time Functions

The Build-time functions are those, which result in a computerised definition of a business process.

Run-Time Functions

At run-time the process definition is interpreted by software, which is responsible for creating and controlling operational instances of the process, scheduling the various activities steps within the process, and invoking the appropriate human and IT application resources, etc. This run-time process control function act as the linkage between the processes as modeled within the process definition and the process as seen in the real world and reflects in the runtime interactions of users and IT application tools.

Run-time Activity Interactions

Interaction with the process control software is necessary to transfer control between activities, to ascertain the operational status of processes, to invoke application tools, and pass the appropriate data, etc.

Distribution & System Interfaces

The flow of work may involve the transfer of tasks between different vendor's workflow products that enables different parts of the business process to be enacted on different platforms or sub-networks using particular products suited to that stage of the process.

Figure 2 - Distribution within the workflow enactment service

The Evolution of Workflow

The workflow as a technology can be used in a number of different product areas that includes:

• Image Processing
• Document Management
• Electronic Mail & Directories
• Groupware Applications
• Transaction-based Applications
• Project Support Software
• BPM and Structured System Design Tools
• Separation of workflow functionality

1.1.1 Generic Implementation

A general implementation model of a workflow system can be matched to most products in the marketplace thereby providing a common basis for developing interoperability scenarios.

This approach identifies the main functional components within a workflow system and the interfaces between them as an abstract model. It is recognized that many different concrete implementation variants of this abstract model will exist and therefore the interfaces specified may be realized across a number of different platform and underlying distribution technologies. Furthermore, not all vendors may choose to expose every interface between the functional components within the model; this will be dealt with by the specification of a variety of conformance levels which will identify the particular inter-working functions where open interfaces are supported for multi-vendor integration.

Figure 3 illustrates the main functional components of a generic workflow system.

Figure 3 - Generic Workflow Product Structure

The generic model has three types of component:

• software components which provide support for various functions within the workflow system (shown in dark fill)
• Various types of system definition and control data (shown unfilled) that are used by one or more software components
• Applications and application databases (shown in light fill) that are not part of the workflow product, but this may be invoked by it as part of the total workflow system.

The roles of the major functional components within this system are:

• Process Definition Tool
• Process Definition
• Workflow Enactment Service
• Workflow Relevant Data and Application Data
• Worklists
• Worklist Handler & User Interface
• Supervisory Operations
• Exposed and Embedded Interfaces.

h4 1.1.2 Alternative Implementation Scenario

The structural model of a generic workflow product identifies a series of software components and interfaces.

In a concrete product implementation this structure may be realized in a variety of different ways; this is an important area of product differentiation. Major distinguishing factors between products include choice of platform and network infrastructure, as well as the inherent functionality of the workflow software itself.

The generic model copes with variety of implementation approach, whilst retaining visible interfaces to facilitate multi-vendor product inter-working.

Workflow Enactment Software - Alternative Approaches

The workflow enactment software consists of one or more workflow engines, which are responsible for managing all, or part, of the execution of individual process instances. This may be set up as a centralized system with a single workflow engine responsible for managing all process execution or as a distributed system in which several engines cooperate, each managing part of the overall execution.

Figure 4 - Standard workflow enactment service boundary

In the above scenario the two workflow services exhibit common properties at the boundary but follow different internal implementation architectures, whose characteristics may be product dependent.

Workflow Client Applications - Alternative Approaches

Figure 5 - Alternative client worklist handler implementations

In the workflow model, interaction occurs between the worklist handler and a particular workflow engine through a well defined interface embracing the concept of a worklist - the queue of work items assigned to a particular user (or, possibly, group of common users) by the workflow enactment service.

Figure 5 illustrates the four possible approaches, one supporting centralized worklist handling and three supporting a distributed worklist handler function.

The four example scenarios are as follows:

• Host based Model - the client worklist handler application is host based and communicates with the worklist via a local interface at the workflow engine. In this case the user interface function may be driven by a terminal or a remote workstation MMI.
• Shared filestore model - the worklist handler application is implemented as a client function and communicates via a shared filestore, which lies on the boundary between host and client platform environments and is accessible to both.
• Electronic mail model - communication is via electronic mail, which supports the distribution of work items to individual participants for local processing. In this scenario the worklist would normally lie at the client.
• Procedure Call or Message Passing model - communication is via procedure call, or other message passing mechanism. In this scenario the worklist may be physically located on the workflow engine or at the worklist handler according to the particular implementation characteristics.

2 Rules Management System

In recent years, data-driven organizations have increasingly recognized the limitations of traditional software development systems. Far too often, they find their key competencies and regulatory compliance information locked inside multiple software systems, expressed in highly technical languages, and generally inaccessible to the managers and subject experts responsible for implementing decisions.

BRMS typically need to have:

• Enabling knowledgeable business experts to write business rules or policies directly using a familiar and comfortable language and statement structure.
• Supporting high variability in business rules across time, products, jurisdictions, customers, and other domains.

This is done most efficiently by decoupling the business rule life cycle from the software development life cycle.

Doing so enables rule authors (i.e. policy managers) to operate independently of the software development cycle, leading to parallel software development and rule life cycles. This is illustrated in Figure 1. In the top half of the figure – the software development cycle – application releases are driven by major requirement changes and external product release schedules. These releases are produced by architects, business analysts and developers in following the traditional software development cycle of requirement specification, analysis, design, development, testing, and deployment.

In most situations, business rules change along a finer timeline and are driven by business policy changes that represent variants or extensions on the established functional base for the project's current release. This is shown as the "Rule Management Cycle" in the lower half of Figure 6.

Figure 6 - Rules and Software Management Cycle

Changes implemented here require a smaller, more focused cycle of authoring and testing by the policy manager, and timely deployment to production.

Depending on the needs of the application, this business rule cycle can take as long as a few months or as little as a couple of hours to complete.

BRMS will facilitate all the aspects of business rule management in the enterprise for following reasons:

Efficient and Scalable

Rule engines are a great way to collect complex decision-making logic and work with data sets too large for humans to effectively use. A rule engine can make decisions based on hundreds of thousands of facts, quickly, reliably, and repeatedly. It works by decomposing large sets of rules into a very efficient network of nodes, which can process and react to facts far more efficiently than it can be programmed manually. A Rule engine scales extremely well, almost linearly, with increases in rules and facts.

Improve Productivity and Maintainability

In business, the extremely complex interplay of hundreds or even hundreds of thousands of rules operating on tens of thousands of concurrent facts can influence the outcome of important decisions. Those decisions can be difficult or impossible to program using procedural or imperative programming techniques. Rule based approaches lend themselves for data/logic separation; where business rules looks on what it does, not how it does it, thus making it easier to manage extremely complex decision making processes.

Centralized Knowledge Repositories

Rule engines facilitate knowledge-transfer to centralized repositories and helps combat issues due to the loss of key decision makers, managers, executives, specialists, and highly creative employees from 'normal' turnover rates and aging populations. This loss of knowledge can cripple small businesses, and seriously hamper the efforts of medium sized companies or divisions of large companies.

Customized Products and Services

Rule engines can dramatically improve your ability to put knowledge resources to use in subtle ways. Rules can help you customize your product and service offerings for customers and partners on an individual basis, and they can be used to centralize the behavioral or execution logic of your commercial applications, allowing you to quickly tailor them to the demands of ever-changing markets.

2.1 Design & Architecture

The key stakeholders in a business rule management systems are:

• Architect: The architect is responsible for the overall design of an application, and assuring that the design meets long-term business needs for function, efficiency, and performance.
• Business Analyst:* The business analyst is responsible for understanding business requirements and translating them into data and process descriptions.
• Developer:* The developer creates and tests the application.
• Policy Manager:* The policy manager is a subject expert responsible for translating business policy into detailed business rules.
• System Administrator:* The system administrator manages applications in production to achieve required up-time and performance goals.

The requirement of a good BRMS product would be:

Comprehensive feature set

The comprehensive feature set typically includes:

• Tools and rule languages that help policy managers, business analysts, and developers to author, deploy, and manage business rules.
• Repository to store and protect business rules.
• Rule engine to execute rules.
• Extensive Java library to define, extend rule execution, and manage environments.

Reliability

The combination of high performance and robustness make the product's rule engine, the one to depend on with mission-critical business applications, regardless of the throughput requirements. It needs to be designed to fit into a modern computing environment seamlessly and efficiently, so there is no need for a custom or proprietary interface or adapter.

Customizable and Extensible

Practically every feature provided "out of the box" should be customizable and extensible to an unprecedented degree. The tools, repository, and engine need to be supported with rich APIs, and frameworks that enable their extension programmatically.

The primary objective is to create an effective and efficient overall structure for an application and its associated data flows.

Figure 7 - Rules Management Architecture

3 Conclusion

The workflow system, which assess, analyzes, models, and defines flow of business process. It basically handles the transitions of events and messaging when some actions are performed.

The needs of traditional methods of managing business are too complex and call for a need for solution to support policy changes effectively and fast. This calls for workflow system to adapt itself to be capable to handle the rapid changes in policies and rules of the core business processes.

The rapid changes and complexity of business rules calls for a solution capable of handling the business flow with complex rules. A workflow system with rules management system should be capable of handling the business processes.

References:

WfMC - The Workflow Management Coalition Specification - For WorkFlow Definition and Diagrams.