James Taylor's Decision Management

James Taylor

Agile services, business rules and interface versioning

user-pic
Vote 0 Votes

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: , , , , ,

No TrackBacks

TrackBack URL: http://www.ebizq.net/MT4/mt-tb.cgi/12958

Leave a comment

A blog about the use of decision management technologies like predictive analytics and business rules to deliver agility, improve business processes and bring intelligent automation to SOA.

James Taylor

James Taylor blogs on decision management for ebizQ, and is an independent consultant on decision management, predictive analytics, business rules, and related topics.

Sponsored Links

Fico

Subscribe

 Subscribe to this blog by RSS
Subscribe by email:

Recently Commented On

Recent Webinars

    Tag Cloud

    action, adaptive control, agile, agility, alignment, analytics, application development, BDM, bi, BI, bpm, BPM, bpms, BRE, bre, BRMS, brms, busines rules, business agility, business alignment, business analyst, business analytics, business intelligence, business process, business process management, business rules, business rules engine, business rules forum, business rules management, business rules management system, business user, case management, CEP, change, collaboration, competency center, complex event processing, compliance, consumer, context, customer experience, customer-centric, data, data mining, decision, decision agent, decision automation, decision engine, decision making, Decision Management, decision management, decision model, decision service, decision support, decision table, decision tree, decision-centric, decisioning, declarative, development, domain specific language, drools, dsl, eda, EDM, enterprise applications, event processing, extreme personalization, financial services, gartner, hard coding, IASA, In Database Analytics, inferencing, insurance, intelligence, intelligent agent, interaction, jboss, kpi, legacy, legacy modernization, location, mainframe, marketing, MDE, metrics, micro decision, mobile, model-driven, modl, multi-channel, operational BI, operational decision, optimization, pattern, performance management, personalization, Pervasive BI, predictive analytics, predictive enterprise, predictive model, process, programmer, programming, real-time, recommendation engine, report, requirements, retail, rete, rule set, rule sheet, SAP, scenario, semantics, Sensor, service, simulation, smart (enough) systems, smartenoughsystems, smarter systems, SME, soa, software development, statistics, strategic decision, tactical decision, Teradata, traceability, transparency, use case, visualization,

    Monthly Archives

    Blogs

    ADVERTISEMENT