Occasionally I get asked about rule standards. Recently a prospective partner, who acknowledged that there were not rule standards today, but thought rule standards were inevitable and imminent:
“…proprietary knowledge (rule) representation formats will be converging toward a common standard, and this will allow for easy portability of a knowledge (rule) base from one platform to another. A wide adoption of SQL by database engine vendors, or growing popularity of PMML [Predictive Model Markup Language] for representation of predictive models, make good cases for a similar type of standard (for instance derived from the current OWL/SWRL) to be adopted sooner or later by rule engine vendors.”
The idea of rule portability and a standard language is indeed an appealing one. There are a few standards currently in development; the front-running standards for business rules metadata are RuleML and the Semantics of Business Vocabulary and Rule (SBVR). However, the way in which these standards are being developed indicates that their being the standards vendors will adopt is highly unlikely.
Compare the birth, evolution, and adoption of RuleML and SBVR with that of SQL and PMML.
SQL was developed by IBM, a leading information management vendor. Another vendor, Relational Software (now Oracle) saw the potential of relational database management systems and SQL and released its own SQL-based database. IBM and Oracle invented and developed a market for products based on SQL. They, along with Microsoft, remain market leaders.
PMML is developed by The Data Mining Group (DMG), an independent, vendor-led consortium. Full members of the group include IBM, MicroStrategy, SAS, and SPSS (soon to be part of IBM); Microsoft, Oracle, and SAP also participate in the group.
By contrast, RuleML is an academic body. Most of the participants are from prestigious universities, not vendors. IBM, always a leader in technology standards, does send a member, but he is from the TJ Watson Research Center, not Websphere-ILOG. None of the major business rule technology vendors—Corticon, FICO, IBM-ILOG, InRule, Oracle—participate in RuleML. SBVR is being developed by the Business Rules Group within OMG. The Business Rule Group members are primarily consultants who work with business rules, but, again, none of the members is from the leading business rule technology vendors. Likewise SWRL (which I’d never heard of and doesn’t seem to have had any activity in 5 years) has no vendor participants.
Technology standards must be developed and driven by the leading vendors in the space or they will not be adopted. Not because we vendors are smarter, but because vendors will develop and adopt standards that will benefit our customers and help grow our businesses. Vendors don’t drive and adopt standards just because we’re good guys, but because it helps growth our business: it’s strategic.
Business rule technology vendors are constantly introducing new capabilities to benefit our customers and grow our businesses. And while rule standards are “interesting,” they just haven’t bubbled up to the top of most customers’ requirements list. When the market is ready, business rule standards will emerge, but they will most definitely be driven from the vendor community.
As business users define processes, they may find that defining all the permutations around decision points can create a workflow that is unwieldy, both in terms of understanding and ability to maintain, execute, and optimize. The process can get—well—ugly. Suddenly, Mr. Fitness is extremely inflexible from too time in the weight room (and orange from too much time in the spray tan booth, but that’s a whole ‘nother topic, as they say).
For example, a workflow may be defined to execute the very complex logic that determines eligibility and pricing for insurance. With the permission of my good friends at ShareVis—whose software helps you create, deploy and maintain very beautiful processes (www.sharevis.com)-- Figure 1 shows how such decision logic, when embedded within a workflow, can make a process very complex.
For example, a single, high-level decision point called “Determine Eligibility” will encompass many underlying decisions and calculations. Figure 2 shows how this high level decision point within the workflow reduces the complexity of the workflow shown in the previous graphic. In this case, the ShareVis process calls InRule to manage and execute the decision logic.
/ShareVis-Streamlined-Decision.aspx)
By embedding every decision point within a workflow, organizations are not only making ugly processes, they’re unintentionally embedding decision logic—thus moving away from the vision of SOA. To help streamline business processes, organizations must identify decision logic and manage it differently from flow logic. By externalizing the decision logic from the workflow, a business rule engine can simplify a workflow and make the logic easier to update. Using business rule technology with your BPM tool can help renew the youthful beauty of your most complex business processes.
The underlying rules, logic, and calculations that drive that decision point can be maintained separately from the workflow, by the subject matter experts. Business rule technology, like yoga, brings flexibility and deep thought to complement the power of BPM.
Flexible, beautiful business processes brought to you by the Yogi of IT: Business Rule Technology.
Namaste.