Reuse and agility with rules - James Taylor's Decision Management

« Business process, business rules and legacy modernization | Main | Standard Operatiing Procedures implemented as business rules »

October 03, 2006
Reuse and agility with rules

I was reading David Chappell's blog last week he referenced one of his Opiniari on the difficulties of reuse, especially re-use of business logic, even when using a service-oriented approach. I have posted some recently about decision services and that made me think about re-use in the context of decision services. As David notes, the only surefire way to get reuse is to develop one service to replace all or part of several systems. Building a service, and hoping for reuse is often optimistic. So how does this change if I use a business rules management system to develop some or all of my services? How does that affect reuse?

So firstly there is the question of reuse when building decision services. While I don't think decision services are inherently more reusable than other services in general, I can think of some that will often be reused because they are additive and not core to a process - like a service that generates recommended cross-sells. This will get reused precisely because it is not a core service. A small point relative to David's larger one, however.
The second barrier he identifies is one of myriad minor variations of a service preventing reuse. This problem is not really any different with decision services. However, if I am using a common rule repository I may get reuse below the level of a service. Essentially a service designer might reuse many of the rules in a new service and the business rules management system will then manage changes to the services implied by changes to the rules. While this suffers from some of the same issues as reuse of services there are a couple of advantages. Firstly the reuse might be more granular - reassembling shared rules into a new service might work better for some developers than reusing the service. Secondly the business rules might be both more obviously shared, like rules defining customer segments, or might even be mandated by regulations and a need to comply with same. Lastly many business rules management systems allow for layers of rules and that might allow reuse of core rules with a layer of customized rules on top, supporting the minor variations needed.
The last barrier is one of incentives - why should the first developer of a service even want others to reuse it? One of the great things about decision services build with business rules is that the owner of the service is, hopefully, the owner of the business rules. By and large these folks are highly motivated to share their services across the enterprise. Indeed it may even be policy. Think about a bank with a credit pricing service - a decision service that decides on the rate and terms for a credit product for a customer. The risk management group might own these rules and they want, and may be able to insist, on all processes that need credit product pricing use the service. This kind of service will get reused.

One final point. David implies that agility in SOA is just another word for reuse. I disagree. There is also the agility that comes from building a service so that the logic encapsulated in it can be changed readily. This intra-service agility can be as important, or more important, than the kind of inter-service agility that comes with reuse. Using business rules to develop this kind of service definitely adds agility. Reuse or no reuse.

Technorati Tags: agility, BRE, BRMS, Business Rules, decision service, SOA