Unifying Analytics, Rules and Processes with Decision Services

Published
  • February 07 2008, 3:14pm EST

Technology executives find themselves under increasing pressure from their C-level peers to deliver an adaptive IT infrastructure that responds to change – including changes in corporate strategy, marketing priorities, suppliers, distribution channels and regulations. This mandate is all in the name of agility, or a state of corporate readiness where change is something anticipated, if not welcomed, but never unexpected (or never admittedly so).

 

While this charter becomes clearer every day, less so are the differences between two approaches often employed in pursuit of technical flexibility – the business rules management system (BRMS) and the business process management suite (BPMS). Providers of both cite similar approaches to achieving the common benefit of separating logic from operational systems so that it can be managed as a more readily changeable asset. Yet for many organizations, these technologies are complementary and serve different roles in the pursuit of an agile IT infrastructure.

 

Understanding the distinctions between a BRMS and a BPMS has recently gotten more difficult as a new concept has been introduced to both: analytics or adding intelligence to the way system logic is executed. Forward-thinking companies no longer wish to just manage the factors that influence agility, but also adapt or improve them, often in real time. This more ideal state is only achieved through the addition of analytics, which, when implemented in the form of a decision service, serves as a unifying construct for a BRMS and a BPMS.

 

Logic(al) Differences

 

While many industry observers today debate the roles of BRMSs and BPMSs few distill the differences to a simple level the uninitiated can understand. The issue centers on business rules, specifically, which system should be the primary arbiter.

 

Business rules can be implicit or explicit business policies. According to Gartner: “Implicit rules refer to business logic (e.g., policies, constraints, decsioning data) embedded inside another asset (e.g., application code)…Unlike explicit rules that have been exposed, clearly defined and documented, implicit rules are difficult to harvest, document, manage and evolve. Business Rules Management is the science for exposing and managing business policies and procedures in explicit form, so that they can be treated as business managers intended them to be treated...as corporate assets.”1

 

That same research from Gartner prescribes the use of a BRMS to manage rules, and thus defines such a system as a “comprehensive business rule offering that facilitates the creation, registration, classification, verification, deployment and execution of rules,” and that is distinguished from business rules engines by greatly expanding upon an execution engine and development environment – it is instead a “robust set of integrated rule management tools.”

 

A rules engine is also a feature within some BPMSs, which, according to Gartner, “enables the direct control and management of operational processes in near-real time by business managers and process owners.”2 Unlike a BRMS, however, a BPMS focuses on process orchestration, and thus the business rules managed by it tend to be limited to “process logic” - the rules governing the flow of activities within a process. This is distinct from “decision logic,” or rules defining decisions that occur within a process and that are typically managed by a dedicated BRMS.

 

So not only does a BPMS include a subset of BRMS capabilities, it focuses on a different class of rules - rules that are native to a process or group of processes. This difference is especially notable due to the emergence of analytics within both BRMSs and BPMSs.

 

Gartner also distinguishes between the analysis of a process itself (e.g., its performance, as in traditional business intelligence [BI]) and analysis that may occur during the execution of a process (e.g., checking a rule to determine if a customer is eligible for a discount).

 

“Analysis of the process enables enterprises to identify broken connections in the process or bottlenecks in process performance,” according to Gartner. “In contrast, analysis in the process is not about making the process generally work better, it is about making the process work optimally for the particular object (for example, customer, invoice, warranty claim and investment) that is being processed.”3

 

It is the latter of the two analyses where decision logic may be called upon to inform the execution of a business process – possibly using a blend of rules and analytic models. A decision service is a Web service provided by a BRMS that encapsulates decision logic for consumption by a BPMS on demand – it is effectively the glue between the two systems. The “analysis of a process” described by Gartner is more akin to historical reporting and analysis and can be useful in assessing the performance of a process and the logic that defines it.

 

Thus, an important precept in both BRMSs and BPMSs is preserved: separation of decision logic from process logic. In practice, this entails process logic managed by a BPMS making a call to a decision service to determine an appropriate action to take in the course of process execution, receiving the result, then completing the process.

 

Example: The Widget Store Goes Online

 

To illustrate the concepts of process and decision logic, consider the case of The Widget Store, which several years ago developed a complementary online presence to its storefront locations and call center. As part of this project, the online store’s buying process was defined in a graphical user interface within a specialized e-commerce platform, and it considered the paths and actions expected of the buyer - steps such as adding or removing items from a virtual shopping cart, entering a checkout process, selecting from various shipping and payment options, then executing the payment transaction.

 

In tandem with defining this process, special offers or treatments could be defined based on factors such as market basket value. To take advantage of this capability, free shipping was implemented on orders more than $50. Similar and often more complex promotions were typical of sales stemming from its stores and call center.

 

Since establishing its online presence, The Widget Store has experienced consistent growth, but recently its sales declined as customers defected to competitors that provided a consistent service level to customers regardless of channel: Web, phone or point of sale. To combat this problem, a new customer-centric initiative was established, resulting in the coordination of offers across channels.

 

Unfortunately, The Widget Store developed each of its customer channels independent of one another, with redundant logic embedded in each to direct the manner by which offers were presented. Thus, the level of agility expected of the new initiative was not possible. That is, until the CIO decided to implement a BRMS that became the centralized repository and arbiter of decisions executed across all customer touch points. This had the added benefit of enabling even more sophisticated customer treatment strategies to be implemented using predictive models, the results from which were delivered by decision services.

 

Now when a customer logs in to complete a purchase, his or her profile is checked against a segment of high-value customers eligible to receive free shipping on orders more than $50 as well as suggestions for products most likely to be purchased next. This “call” is made outside the process itself to a decision service served by the BRMS, which returns instructions to the checkout process describing the type of offer to present. These same rules apply to stores and the call center, which, although managed by different systems in these channels, share access to the same decision logic via decision services. This logic can be easily changed by the marketing staff and very often does due to the seasonal nature of the business.

 

Architectural Considerations

 

It should be clear that a BRMS subscribing to the approaches outlined here can manage decision logic comprising rules and analytics, while exposing relevant decision services on demand to a BPMS, which instead focuses on managing the execution of business processes and the process logic directing them. But how are BRMSs and BPMSs best viewed within enterprise architecture? What exactly about a BRMS makes it more ideally suited to manage decision logic in a manner that supports rapid change?

 

To address the first question, it helps to view a BRMS as part of the services-oriented architecture (SOA) of the enterprise. Like other enterprise technology services, a BRMS features a repository, oversight and governance capabilities, and is also designed to work with any application or system where scale and performance are important considerations. A BPMS simply accesses rules and analytics via decision services to receive a result which then directs the next action within a process.

 

SOA also facilitates rapid change of business rules because they are managed in one place, yet can be accessed by multiple systems. Thus, a rule can be changed and take effect in any process or application that uses its decision logic. It’s also worth noting that a BRMS allows the creation of rules-maintenance applications, which are designed to allow business domain experts to change rules as conditions merit. Bringing this capability to the fingertips of business users enables an agility more often associated with BRMSs than BPMSs.

 

Change is a core competency within BRMSs simply due to the fact that decision logic frequently changes relative to business processes. Consider the Widget Store, for example, where the buying process remains relatively static as opposed to the decision logic, which changes quite often. Business user empowerment is a trait BRMSs have in common with BI tools, an observation leading many to predict an interesting future for enterprise applications.

 

Looking Ahead

  

Decision services promises to play a central role in many next-generation enterprise application projects. A new category of applications which blend business rules, business process management and BI are today being cobbled together by many organization - all in pursuit of meeting ever-changing IT requirements wrought by business, technical and marketplace demands. To speed their development, such applications will almost always be composite, meaning any of the core technologies - for rules, processes or BI - that conform to SOA principles today will almost certainly play roles.

 

Those best positioned to take advantage of emerging “built for change” applications will embrace appropriate technologies today that feature a services orientation and distinguish between decision and process logic. As the vehicle for serving complex decision logic to business processes and other enterprise applications, decision services created and managed by BRMSs offer a strong foundation for an agile IT infrastructure.

 

References:

  1. Eric Deitert and David McCoy. “The Anatomy of a BRMS.” Gartner Research, September 28, 2007.
  2. Janelle Hill and Jim Sinur. “Magic Quadrant for Business Process Management Suites, 2006.” Gartner Research, June 2006.  
  3. Gareth Herschel. “The Role of Analytics in Adding Value to Business Processes.” Gartner Research, September 21, 2007.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access