systems that know and understand and think and learn
Externalizing enterprise decision management using service-oriented architecture orchestrated by business process management makes increases agility and allows continuous performance improvement, but…
How do you implement the rules of EDM in an SOA decision service? Continue reading “Agile decision services without XML details”
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:
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. Continue reading “Behind the CEP curtain – it’s about time, not the cache”
James Taylor’s notes on his lunch with Sandy Carter of IBM and the CEO of Ilog prompted me to write this. Part of the conversation concerned the appeal of SOA and rules to business users. Speaking as a former vendor, we all want business people to appreciate our technology. We earn more if they do. They say to IT “we want SOA” or “we want rules” and our sale not only becomes easier, it becomes more valuable. So we try to convince the business that they are service-oriented, so they should use SOA. Or we tell the business that they have (and make) rules, so they should use (and manage their own) rules. And rules advocates embrace and enhance the SOA value proposition saying that combined, you get the best of both worlds. This is almost precisely the decision management appeal. Externalize your decisions as services and externalize rules from those services for increased agility in decision making. This is an accurate and appropriate perspective for point decision making. But it doesn’t cover the bigger picture that strategic business people consider, which includes governance and compliance.
Nonetheless,
Effective SOA and business rules have one requirement (or benefit) in common: externalization.
The externalization of services from applications Continue reading “Externalization of rules and SOA is important – for now”
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:
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. Continue reading “CEP crossing the chasm into BPM by way of BRMS”
James Taylor’s blog today on rules being core to BPM and SOA in which he discussed reuse had a particularly strong impact on me following a trip yesterday. During a meeting with the insurance and retail banking practice leaders at a large consulting firm, we looked for synnergies between applications related to investment and applications related to risk. Of course, during that conversation, we discussed whether operational rules could be usefully shared across these currently siloed areas, but we landed up discussing what they had in common in terms of business concepts, definitions, and fundamental truths or enterprise wide governance. It was clear to us that this was the most fruitful area to develop core, reusable knowledge assets.
In his post, James agrees with the Butler Group’s statement:
Possibly the most important aspect of a rules repository, certainly in respect of the stated promise of BPM, Service Oriented Architecture (SOA), and BRMS, is the ability for the developer to re-use rules within multiple process deployments.
I have several problems with this statement: Continue reading “Rules are not enough. Knowledge is core to reuse.”
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.
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.