Decision Services and designing for change

Todd Biske wrote an interesting piece titled Thoughts on designing for change that made me think about one of the real basics of decision management and reminded me of some comments Phil Wainewright made years ago about what happens to deployed services:

Services have to operate in the real world, where nothing can be taken for granted and nothing is set in stone

So what do you do if you have a service that you know is going to change a lot? One class of changeable services is that of Decision Services. You need these kinds of services to manage change well and protect your from change. One effective approach is to design Decision Services with a business rules management system and then empower the business users to take control of the rules in these services.

After all, as Phil goes on to say:

Conventional software tools do a poor job of catering for the change-time phase of the development lifecycle. This is a problem, considering that change-time represents the entirely of the lifecycle except for that thin sliver of design time before a service is initially deployed.

The highest change components of an architecture are those that make decisions – policies change all …

Todd Biske wrote an interesting piece titled Thoughts on designing for change that made me think about one of the real basics of decision management and reminded me of some comments Phil Wainewright made years ago about what happens to deployed services:

Services have to operate in the real world, where nothing can be taken for granted and nothing is set in stone

So what do you do if you have a service that you know is going to change a lot? One class of changeable services is that of Decision Services. You need these kinds of services to manage change well and protect your from change. One effective approach is to design Decision Services with a business rules management system and then empower the business users to take control of the rules in these services.

After all, as Phil goes on to say:

Conventional software tools do a poor job of catering for the change-time phase of the development lifecycle. This is a problem, considering that change-time represents the entirely of the lifecycle except for that thin sliver of design time before a service is initially deployed.

The highest change components of an architecture are those that make decisions – policies change all the time, regulations change all the time, competitive pressure changes all the time etc. Business rules management software lets IT focus on what kinds of rules are needed and on setting up an architecture to manage those rules while letting business users worry about the specific instances of those rules in place at any moment. This works LONG after the service is deployed. Designing for change indeed.

Link to original post