architecture – Commercial Intelligence

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

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

Continue reading “Elicitation and Management of Rules, Requirements and Decisions”

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

Continue reading “Business Rules Process Management”