≡ Menu

Decision Services, Decision Agents and Event Processing


I have been doing some presenting on decision services recently – to SAI in Belgium and at the SOA Symposium – and my old friend Paul Vincent posted about a discussion he and I have been having about the relevance of decision services in an event-driven architecture or Complex Event Processing scenario. Paul makes the point that reusing decision services, required for processes or some other element of your architecture, makes perfect sense. However he also notes that

it may not make sense to rely on external (and sometimes relatively high-latency) distributed decision services – especially when the decisions are closely related to the event processing.

I don’t particularly disagree with this. I think that rules and decision-making that are “closely related” to the event processing probably should be part of a “decision agent” that, as Paul goes on to say:

can share many components and ideas – business rules management and business user interface (for business control of the decisions), production rules engine (for efficient execution of declarative rule statements), etc etc.

My rule of thumb for decision services and event processing is similar to the one I have for processes and decisions. If the decision or the rules relates to the process/events and is tightly coupled to them (it will change if they do and vice versa) then it is part of the process/event processing environment. If, on the other hand, the decision would remain the same if the process or events involved were completely altered, then it is a decision that should be managed explicitly. For instance:

  • Routing decisions in a call center process are tightly coupled to the process
  • The rules for the set of events whose receipt shows that a customer is in trouble are tightly coupled to the events
  • The decision that Customer X is an “Important” customer is relevant to both (it may be used in routing and for deciding on the action to take when they get in trouble) but completely independent of both.

Don’t embed business decisions in anything too tightly coupled to events or processes if you can avoid it – manage them as the corporate assets they are.

BTW I have blogged a little about this on my ebizQ blog – here for instance – and I suspect this debate will run and run.


Comments on this entry are closed.

  • Paul Vincent October 14, 2008, 6:47 am

    Good post.
    “Don’t embed business decisions in anything too tightly coupled to events or processes if you can avoid it – manage them as the corporate assets they are.”
    Note that these are not necessarily connected notions. Some BRMSs for example let you generate COBOL, .NET and Java for the same managed rules. The same applies in Event Processing: I might want to manage rules / decisions, but deploy them as required in multiple services. Its the design-time separation (of rules and code) that is more important…