Agile services, business rules and interface versioning - James Taylor's Decision Management

« Is a BPM Suite enough to deliver business agility? | Main | Business process, business rules and legacy modernization »

October 02, 2006
Agile services, business rules and interface versioning

I was pointed to this SOA message board thread where folks responded to the following question:

If the logic in a service is changed and f(x) begins producing a new result, do you version the service?
(Note: in this scenario, the interface didn't change just the internal logic.)

This came up in the context of a discussion I was having with Jeff Schneider over rules-based decision services. Opinion on the board seemed to be split. On one side there were folks who said variants on the theme that the behavior of the service behind its interface is equally important to the service consumer and so it should be versioned. Some folks were a little more precise and said that they would version the service if the difference in the result is semantically distinct. There was also a discussion around expectations - essentially that the interface should be versioned if the change to the logic would be incompatible or would change the expectations another service might have. As someone said "If the logic is relevant to the contract, yes, otherwise, no"

The question is what to do if the rules within a service change but the interface does not. Should you version the interface?

To me this comes down to an issue of context. If the business decision has not changed then the service has not changed and so the interface would not need to change. Thus if the changes to the rules change only the mechanics of making the decision (to comply with a new regulation or to take advantage of new understanding of customer segments for instance), then the interface should not be versioned because the service is doing the same job it was before. So I could change the rules in a service that answered questions like “Should I approve this person for this loan” or “is this claim fraudulent” or “what offers should I make” and not change the interface unless I changed the business intent. The fact that the rules have changed does not impact any other service until and unless I make a change to the business intent of the service.

When a business owner changes the rules within a service without changing the intent of the service I don’t consider that the service has changed. If I build a service that returns the most appropriate 3 cross-sell offers in descending order then as long as it continues to do that, why does a consuming service care how I figured out that the most appropriate three were? If I build a service that quotes for an insurance policy, why does a service that takes this quote and continues on with processing it care how the quote was calculated? Surely the purpose of encapsulation in a service is to mean I can rely on the service without having to understand its internals?

This kind of change is what makes rules-based decision services so powerful.

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