Posted on

Ontology of time in progress – amounts needed

Recent posts on money and time have produced some excellent comments and correspondence.  There is even recent OMG effort that is right on the money, at least concerning time.  For details, see the Date-Time Foundational Vocabulary RFP.  I am particularly impressed with SBVR “Foundation” Vocabularies, which I understand Mark Linehan of IBM presented last week at an OMG meeting in DC[1].

Mark’s suggestions include establishing standard upper ontologies for:

  1. Time & dates
  2. Monetary amount
  3. Location
  4. Unit of measure
  5. Quantities, cardinalities, and ratios
  6. Arithmetic operations

I will skip operations for now since they are not taxonomic concepts but functional relationships involving such concepts.  I believe the post on CEP and BPM covered time in adequate detail and the post on Siebel’s handling of foreign exchange covered the currency exchange aspects of money.  It only touched on the more general concept of amounts that I will focus on here.

The remaining concepts are common to almost every application conceivable.  They are some of the most primitive, domain-independent concepts of a critical and practical upper ontology.  They include: Continue reading “Ontology of time in progress – amounts needed”

Posted on

In the names of CEP and BPM

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, was the first time I heard a consensus that a standard ontology of events and processes was sorely needed.  I’ve had a number of discussions with others on this over the interim until today’s posts by Paul Vincent, summing up an OMG meeting in Washington, DC, and Sandy Kelmsley’s comments on a survey of 590 business process modeling notation users.   Continue reading “In the names of CEP and BPM”

Posted on

Rules are not enough. Knowledge is core to reuse.

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.”

Posted on

The $50 Business Rule

Work on acquiring knowledge about science has estimated the cost of encoding knowledge in question answering or problem solving systems at $10,000 per page of relevant textbooks. Regrettably, such estimates are also consistent with the commercial experience of many business rules adopters. The cost of capturing and automating hundreds or thousands of business rules is typically several hundred dollars per rule. The labor costs alone for a implementing several hundred rules too often exceed $100,000.

The fact that most rule adopters face costs exceeding $200 per rule is even more discouraging when this cost does not include the cost of eliciting or harvesting functional requirements or policies but is just the cost of translating such content into the more technical expressions understood by business rules management systems (BRMS) or business rule engines (BRE).

I recommend against adopting any business rule approach that cannot limit the cost of automating elicited or harvested content to less than $100 per rule given a few hundred rules. In fact, Automata provides fixed price services consistent with the following graph using an approach similar to the one I developed at Haley Systems.

Cost per Harvested or Elicited Rule

Continue reading “The $50 Business Rule”

Posted on

Missing Goals and Requirements in Business Rules

Both of the following statements are true, but the first is more informative:

  1. Business Rules Management Systems (BRMS) typically produce forward chaining production rules that are interpreted by[1] a business rules engine (BRE) based on the Rete Algorithm.
  2. BRMS typically generate rules that are interpreted by a BRE.

First, dropping the word “production” before “rules” loses information. BRMS do not typically generate rules that are not production rules. Consider, for example, the BRMS vendors involved in the OMG effort produced the Production Rule Representation (PRR) standard. The obvious question is:

  • What is different about production rules?

Second, dropping the words “based on the Rete Algorithm” loses information. The dominant rules vendors and open-source engines are all based on the Rete Algorithm.

  • Why does the Rete Algorithm matter?

Third, dropping the word “chaining” before “rules” loses information. Chaining refers to the sequential application of rules, as in a chain where each link is the application of one rule and links are tied together by their interaction. But:

  • Why does chaining matter?

Fourth, dropping the word “forward” before “chaining” loses information. Forward chaining reacts to information without requiring goals. This begs the question:

  • Don’t goals matter?

Continue reading “Missing Goals and Requirements in Business Rules”

Posted on

Business Rules Market Maturity

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:[1]

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:[2]

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.

Continue reading “Business Rules Market Maturity”

Posted on

Managing Semantics, Vocabulary and Business Rules as Knowledge

A client recently asked me for guidance in establishing a center of excellence concerning business rules within their organization. Their objectives included:

  1. Accumulate requisite skills for productive success.
  2. Establish methodologies for productive, reliable and repeatable success.
  3. Accumulate and reuse content (e.g., definitions, requirements, regulations, and policies) across implementations, departments or divisions.
  4. Establish multiple tutorial and reusable reference implementations, including application development, tooling, and integration aspects.
  5. Establish centralized or transferable infrastructure, including architectural aspects, tools and repositories that reflect and support established methodologies, reusable content, and reference implementations.
  6. 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.  

Continue reading “Managing Semantics, Vocabulary and Business Rules as Knowledge”