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
Be the first to comment on this post using the section below.