For those who are interested in my former company, they are still committed to natural language business rules management technology, as shown in their most recent press release. They have also picked up on the public sector activity, especially eligibility, as discussed here.
From the release, CEO, Dominic O’Hanlon, said:
- “With our natural language rule authoring capabilities and BRMS solutions, we are uniquely positioned to make our customers more competitive and agile in a fast-paced, highly-regulated world.”
- “For the government market, Haley is a worldwide leader in using natural language technology to rapidly transform regulations, policies and rules into automated decision-making systems, to determine eligibility for government services, and in the taxation and immigration arenas.”
As discussed here, this focuses comes from (more…)
Have you heard the one about how to drive BPM people crazy?
Ask them the question that drives CEP people crazy!
Last fall, at the RuleML conference in Orlando, (more…)
TIBCO is the CEP vendor most focused on the market for business rules, as reflected in Paul Vincent’s post here. Although I agree with Paul that rule vendors are not currently offering enough in terms of support for long-running processes, the conclusions that he draws in favor of considering a CEP alternative to a BRMS are not compelling yet.
Paul said that rules don’t address the following that are addressed by CEP:
- BAM (business activity monitoring) and the other BPM (business performance management)
- Complex-rule processing
- Customer-centric (portfolio-based) decisions / policies
I am sure Paul was just being flippant, but you may notice that there is a bit of a war going on between CEP, BPM and rules right now. (more…)
Complex event processing (CEP) software handles many low-level events to recognize a high-level event that triggers a business process. Since many business processes do not consider low-level data events, BPM may not seem to need event processing. On the other hand, event processing would not be relevant at all if it did not occasionally trigger a business process or decision. In other words, it appears that:
- CEP requires BPM but
- BPM does not require CEP
The first point is market limiting for CEP vendors. Fortunately for CEP vendors, however, most BPM does require event-processing, however complex. In fact, event processing is perhaps the greatest weakness of current BPM systems (BPMS) and business rules management systems (BRMS), as discussed further below. (more…)
A manager of an enterprise architecture group recently asked me how to train business analysts to elicit or harvest rules effectively. We talked for a bit about the similarities in skills between rules and requirements and agreed that analysts will fail to understand rules as they fail to understand requirements.
For example, just substitute rules in the historical distribution of requirements failures:
- 34% Incorrect requirements
- 24% Inadequate requirements
- 22% Ambiguous requirements
- 9% Inconsistent requirements
- 4% Poor scoping of requirements
- 4% Transcription errors in requirements
- 3% New or changing requirements
Some strategy folks in an enterprise architecture group recently asked for help making rules more relevant to their organization. Their concerns ranged from when to embed rules in their middle tier versus encapsulate them within services to identifying ideal use cases and reference implementations. They were specifically interested in coupling rules with BPM and BI.
Such questions occur every time a group or enterprise considers adopting rules technology for more than a specific application. They are looking for guidelines, blueprints, or patterns that will help them disseminate understanding about when and how to use rules. They have adopted a BPM vendor which will be integrated with their selected rule vendor, each as enterprise standards, so they are particularly interested in the integration requirements between the two.
Two high level understandings are critical for success in furthering adoption of rules technology.
- abstract activities for which rules technology well-suited and
- when and why rules technology is better than familiar alternatives
Some recent correspondence with clients and prospective adopters of business rules technology indicates interested mainstream has become increasing concerned and confused by consolidation in the business rules market.
On the analyst front, they read advice such as the following from Gartner:
As Gartner has stated, the BRE market is a volatile technology sector, and market trends point to increased consolidation. In recent research, we stated that some consolidation will come from rules-to-rules acquisitions. Recent examples of this include Trilogy/Versata buying Gensym and now, RuleBurst purchasing Haley Systems.
Another form this consolidation will take is application vendors or business process management suite vendors buying much-needed rule technology, as seen in SAP’s recently announced intention to purchase Yasu Technologies. In either case, rule technology will persist, but the vendors selling the technology will often be different.
I agree with Gartner, enterprise app and BPM vendors desperately need rules technology. I also agree with the following analysis from Forrester:
SAP’s decision to purchase Hyderabad, India-based Yasu Technologies greatly improves its business rules management capabilities. Other large vendors would be wise to follow SAP’s lead in the business rules market. If you look at the big vendors, they’re all going to need this technology. SAP’s competitors are going to have to step up to these requirements also.
It’s encouraging that SAP bought Business Objects and is now buying Yasu. We’re seeing requirements to link business rules and business intelligence or analytics. SAP has told us they have seen these requests, and we’re encouraged that SAP is now acting.”
Unfortunately, Gartner’s concluding advice could have been more constructive:
Prospective BRE customers: Buyer beware – the rule engine market is a volatile sector. Choose your vendors carefully and be prepared to see more BRE acquisitions.
A client recently asked me for guidance in establishing a center of excellence concerning business rules within their organization. Their objectives included:
- Accumulate requisite skills for productive success.
- Establish methodologies for productive, reliable and repeatable success.
- Accumulate and reuse content (e.g., definitions, requirements, regulations, and policies) across implementations, departments or divisions.
- Establish multiple tutorial and reusable reference implementations, including application development, tooling, and integration aspects.
- Establish centralized or transferable infrastructure, including architectural aspects, tools and repositories that reflect and support established methodologies, reusable content, and reference implementations.
- Establish criteria, best practices and rationale for various administrative matters, especially change management concerning the life cycles of content (e.g., regulations or policies) and applications (e.g., releases and patches).
I was quickly surprised to find myself struggling to write down recommendations for the skill set required to seed the core staff. My recommendations were less technical than the client may have expected. After further consideration, it became clear than any discrepancy in expectations arose from differences in our unvoiced strategic assumptions. Objectives, such as those listed above, are no substitute for a clearly articulated mission and strategy.
In comments to a recent post concerning the acquisition of Haley Systems by Ruleburst, James Taylor suggested that a “decision-centric” perspective is necessary for business rules to become mainstream. In subsequent correspondence, I questioned whether fixating on decisions would achieve his objectives for enterprise decision management. EDM hopes to integrate business intelligence (e.g., predictive analytics) with point decision making so as to improve decision making over time. This is a natural step beyond the typical point decision making application of business rules, such as in a stateless web service that returns a simple decision, such as a score, price or simple yes/no. But it is a narrow perspective on the broader confusion between business rules and business process that has been holding back the mainstream.
For years, smart people have been searching for a razor to determine what logic they should “code” in process versus as rules (e.g., using a BRMS versus their BPM platform). At first glance, the decision-centric approach seems to have the answer. Simply put a decision node in your business process diagram and let the BPM tool orchestrate the decision implemented as a stateless web service!
Unfortunately, this alluring answer is all too often inadequate or impractical. The business rule vendor has effectively transfered responsibility for managing state (i.e., information collection and provisioning) into the business process diagram and orchestration tools – or code. The result is implementation complexity, limited user communities, cost overruns and failures. That will certainly hold back mainstreaming a bit!
A better answer is coming. Complex event processing anticipates that business processes and decision making can be stateful, as Paul Vincent explains briefly but well here. When CEP is supported by knowledge capture, management and automation tools such as the better BRMSystems provide, the lines between process specification and decision specification will further blur beyond the adequacy of the decision-centric advisory. Expect this to happen in 2008.