Competitive Product Analysis

Mark Norton  26 June 2015 01:47:28 PM

If you are evaluating rules products, here are some suggested areas where you could ask questions and confirm capabilities for comparative purposes.

Complexity of rules

What are the fundamental limitations of the underlying rules design patterns and does this limit the complexity of the decision-making that can be automated?

For instance decision tables and/or rete are unable to define a complete rules requirements specification unless the scope and type of rules is constrained. Focusing on constrained decision-making use cases will give a false picture of capability.

Intermediate data – the ‘idiom effect’

In our experience, generating intermediate data on a large scale (often thousands of new data nodes per rules invocation) usually forms the majority of both analysis and computational effort in rules based adjudication of externally supplied data.

This data transformation is required to derive the idiom (viz. ‘a specialized vocabulary used by a group of people’) of the business policy, which is also, by definition, the language of the primary decisions that implement it. The idiom includes the nouns and noun clauses of the proprietary language that we assert is always present when describing business policies and the rules which implement them. See our earlier Modern Analyst paper for more on this subject..  

What is the ability of the product to dynamically define and populate data on this scale within each rules invocation?

Continuous, perpetual, versioning

The primary purpose of a rules engine is to embed decision-making as agile ‘content’ within an application. As such it will be managed using a discrete 'rules development life cycle' that must version independently of the host application.

Does the product allow continuous and perpetual versioning and effective dating of every aspect of the rules definition, so that rules development is future proofed independently of the application – forever?

Ease of integration

Proprietary, independently licensed servers can increase infrastructure complexity and operational overheads. By way of contrast, source code generation (C# and/or Java) allows for all native integration options using a single interface that is easily wrapped and deployed.

Do you adapt to the rules engine, or does the rules engine adapt to you?

What integration overhead is required to implement and use the product?

Enterprise class toolset, Enterprise platform support

Development and deployment of complex enterprise scale rules requires a rules development process that is a first-class participant in the over-arching enterprise development environment.

And deploying into enterprise scale proprietary environments like Oracle, WebSphere and SAP can extend this challenge.

Again, does the product fit into your development and operational processes, or do these processes need to be restructured around the product’s own requirements?

Cost, support, and vendor agility

Compare cost, vendor support, and the ability and willingness of the product vendor to adapt to local needs.

For an overview of the IDIOM product capabilities please see our product overview.

• Comments [0]