« 39 Insurers Recognized as "Model Carriers": Congratulations to Unitrin Kemper Auto & Home | Main | Predictive Modeling »

Business rules and "Dependency Injection"

Nik Malik posted here on why he thinks a pattern known as "dependency injection" beats out rules engines. I was going to write a long post disagreeing but between Charles Young, who does a great job of responding, and Rajgo over on this blog, I am not sure I have much to add!

When it comes to rules, I believe that management and not execution is the issue for many organizations (such as Sun for instance) and that's the weakness for me in Nik's argument. While "dependency injection" may or may not beat out a rule engine, most of us who are serious about rules use business rules management systems and managing code is just way harder, and less effective, that managing rules.

Sorry for the lack of posts recently, had a deadline.

Technorati Tags: ,

First time on the EDM blog?
Subscribe to the EDM blog feed or check out some other recent posts:


TrackBack URL for this entry:

Listed below are links to weblogs that reference Business rules and "Dependency Injection":


Charles Young

Thanks James. I agree completely. In summary, rule management is *the* main value-add. In addition, many modern rules engines allow you to implement sophisticated dependency injection patterns in a manageable, business-orientated fashion without necessarily sacrificing (in fact, sometimes improving) performance. So, I consider Nick's argument to be wrong on several levels. There you go, 30 words instead of 300!!

Gary Furash

I think it's missing the value proposition of business rules to think of them a a technique you add to your application. They should be your application. The whole "what not how" - you declare stuff to be true about the entities in your domain, then let the system figure out what to do at runtime (code), and how to make screens look.

The main problem, I think, is that the people who build applications and application architectures are techies who, while they might like object orientation, don't want to take the next step into declarative programming (Naked Objects, Versata, etc.).

Charles Young

The beginnings of an interesting debate. I'm chiefly involved in designing and building automated process and workflow solutions where graphical orchestration tools provide significant value by allowing implemented code to directly map onto higher-level definitions of business processes. Often, when focusing on process definitions, thinking 'procedurally' (the 'how') makes a lot of sense to a business analyst or domain expert. When thinking about process governance, however, the emphasis is generally on the declarative 'what'. Hence, given that governance is so central to making process manageable and measurable, my experience has been that you achieve significant synergy by combining orchestrations with rules processing. In both cases, the developer can implement higher-level business concepts using a suitable DSL, and sensibly inject custom code implementations as required.

The industry is certainly making progress towards emphasising the 'what' over the 'how'. I don't think, though, that our technology has yet arrived at the position that all coding can be purely declarative. Maybe once we learn how to mine the human brain directly for knowledge, and to mimic human intelligence to a much greater degree, we will be able to dispense with costly code crafting once and for all. All too often, modern rules engines still require rule developers to think about the ‘how’ over the ‘what’. They do improve the situation, though.

Gary Furash

Hmm... There are some systems that go a long way towards being mostly declarative (though you still have to do some coding stuff). Versata's a good example (the company with the greatest difference between quality of product and ability to sell/suppport it).

I'm not sure declaritive means "business people can do it without any help," though it comes off that way. I'm more into the idea of "when state N happens, then Y must be true" - which may or may not be something a non-technical person can describe.

Tom Debevoise

If I were to put a business analyist hat on, I would feel like feel like I was reading an argument on the best way to determine how many angels can dance on the head of a pin.

The value proposition of the technology side of business rules is that business policies are positioned in a repository that is simple to change. We know that a solid BRMS can out perform developers in efficiency and agility.

Imagine this senario:

Manager to technologist:
'We need to change the rules governing vendor selection.'

Technolgist to Manager:
'I think you need an injection'

Charles Young

My point is that rules engines and frameworks generally provide the best fit to the way that business users think about process governance, but don't always fit as well with the way they think about process definition. In the project I am currently working on, the central process is naturally seen as a sequence of steps that follow 'procedurally' one to another. As a technologist, I know that each step is an an activity state, and that the process transitions between those states. I know that the process definitions represent state transition rules which I could capture declaratively in a rules engine and then let the engine figure out the flow. However, I'm fairly certain the business analysts I am working with would find declarative rule sets harder to understand, reason over or verify than the graphical process definitions (orchestrations) we are actually using. They perceive and understand their process in terms of a linear flow of activities and transitions. That flow does not adapt or change dynamically at run time. The emphasis is on repeatable, verifiable, robust, resilient, scalable automated data processing where each scanned document is handled in the same way. The use of orchestration definitions is well aligned to their understanding and requirements.

It happens that on this same project, data validation rules have already been implemented in a back-office system, and the client does not want to throw that investment away. Given a clean slate, I would probably choose to implement those rules in a rules system. They are associated with process governance which defines and enforces the notion of 'correctness' from a business perspective. The business analysts naturally capture, define and reason over these rules in a declarative fashion. A rule set would make much more sense to them than some kind of flow diagram. In this project, the rules have been implemented in SQL stored procedures, so reasoning and verification is largely a matter of someone with SQL skills inspecting the procedures to see what they are doing.

As a technical solution architect, my legitimate concern is to help the business to select and exploit the mix of technologies that best supports their requirements and needs. I am generally rather suspicious of 'one-size-fits-all' approaches. Apart from the different way users tend to think about process definition and governance, consider that the orchestration tool set we are using offers advanced support for state persistence, long-running activities and transactions, integration with external systems, business activity monitoring, message routing and correlation, message transformation, exception and compensation handling, message recovery, etc. We are exploiting almost all these facilities on the project. None of the rules engines I have used provide this same mix of features. They have a different emphasis and different strengths. On the projects I tend to work on, an eclectic and intelligently exploited mix of technologies has generally proved the best way to go.

The comments to this entry are closed.

Search Site



  • enter your email

Upcoming Events

  • FICO Tools & Analytics User Forum 2012
    BERLIN: September 11-12, 2012 LONDON: September 18-19, 2012 Gain new insights for improving business performance through advanced analytics and decision management tools.