JT on EDM

I got an interesting question last week:
In you experience do you believe that the rules editors will become self documenting tools and, if so, is there any danger to this?
With regard to products I have used in the past I am not convinced they have evolved sufficiently to do this and I always see users [...]

The folks at BR Solutions launched a new website that makes some of the RuleSpeak guideliness for writing good rules available for download at www.RuleSpeak.com. It offers basic RuleSpeak 2.0 guidelines in English, Spanish, German and (soon) Dutch. Ron Ross wrote an article about this in the April issue of the Business Rules Journal eUpdate.
I [...]

Syndicated from ebizQ
Adrian Marchis had a nice article on Use Case Recycling by Extracting Business Rules. Now making sure decisions are identified explicitly in use cases avoids one of the seven deadly sins of decision management and is something I think is critical. Indeed I wrote an article on the topic on the same network [...]

RuleXpress is a tool from RuleArts designed to allow business analysts to capture their vocabulary or terms and source business rules relevant to their business and their business problems. RuleXpress is not a business rules management system nor is it a modeling tool in the sense of a UML modeling tool. It is a tool [...]

Continuing this weeks posts on using decision management to improve development,  I thought I would post on how decision management should be part of model-driven development (model-driven engineering, a model-driven architecture or whatever).
The recent, and premature, discussion of the death of SOA led Johan den Haan to post SOA is dead; long live Model-Driven SOA [...]

I just wrote an article for Modern Analyst – Using Decision Management to improve Requirements. The whole area of requirements and business rules/decision management is one I think is deserving of more attention. Just as Agile developers need to think about using rules/decision management so do those specifying requirements. We know the old approaches (rules [...]

On now to the roadmap, at least at a high level.
Right now there is the normal post-acquisition “blue wash” going on and by Q2 will deliver IBM versions of all ILOG’s products and, obviously IBM’s global sales force and Global Services are being spun up. The core of the roadmap is to move the BRMS [...]

In a blog post about Hardcoding Considered Harmful – or is it? Jeff Palermo said
Oren Eini boldly makes the assertion that a system is simpler to maintain when configuration is hard-coded in one place within the system. Coupled with an automated testing and deployment process, changing configuration can be just as simple and predictable [...]

Dan Rosanova wrote a piece on The SOA Knowledge Gap that made me think (again) about the value of business rules as a way to manage requirements. Dan points out that

“A unique SOA challenge is its need to bring together SMEs from across the enterprise.”

Now this is true but I don’t believe that better management of requirements is the answer. In fact what is needed is a way to turn what the SMEs know into something that can be managed in a repository and used to power systems directly. Working with SMEs to create sets of business rules to represent their know-how not only allows this knowledge to be stored in an executable format – reducing the likelihood of implementation error and speeding deployment and maintenance – it also allows each SME or SME group to manage their own rules. A modern Business Rules Management System (BRMS) will allow different users to have different access to rule sets, allowing each set of rules to be managed by those who know them best or those who “own” them. The BRMS can then be used to package up the relevant rules – typically many sets from many SMEs – into a decision service that can be deployed into a service-oriented architecture.
Because the SME’s can edit the rules directly, business agility is increased because the time from the SME realizing that a change is needed to the time when that change is deployed can be cut dramatically using the rule management features of a typical BRMS.
Dan’s comments about how to gather the know-how from SMEs are all good, but gathering their know how as requirements and not rules is going to limit the good it can do. I have blogged a lot on this topic but check out these two posts on the difference between requirements and Requirements and on how to fit business rules into a software development lifecycle.

Dick Lee had an interesting post titled We Know Where We’re Going, But IT Can’t Get Us There. He made a number of points of which three stood out: Business often fails to communicate effectively to IT Poor process definition…