Fred Cummins had a post on the topic of measuring agility in which he gives two ways to assess how well SOA supports agility.
When a business change is considered
- how many services must change to accommodate the new business requirements
- for services that change, how significant are the changes
It is this second point that interests me. When …
Copyright © 2008 James Taylor. Visit the original article at SOA is necessary for agility but not sufficient.
More Read
Fred Cummins had a post on the topic of measuring agility in which he gives two ways to assess how well SOA supports agility.
When a business change is considered
- how many services must change to accommodate the new business requirements
- for services that change, how significant are the changes
It is this second point that interests me. When you make a business change that does require a change to a service, how significant are those changes? Well, if you have written your service in code then they could be pretty darned significant. Not only that but your business users are unlikely to be able to change them without IT support (even though the business users will be the ones who spot/ask for the business change).
If on the other hand you have implemented Decision Services using a declarative, rules-based approach then it will often be true:
- that only the Decision Service needs to change
- that the change is both easy to make and easy to change, often by the business directly
Remember, a Decision Service is a self-contained, callable service with a view of all the conditions and actions that need to be considered to make an operational business decision. Or, more simply, a service that answers a business question for other services.
A decision service must conform to the standard characteristics for a well defined service plus, in addition:
- Behavior understandable to the business
After all we are talking about a “business decision” here so the business had better be able to verify exactly what is going on inside - Supports rapid iteration without disruption
Business decisions change all the time so a decision service has to be both flexible and designed for this change - Integrates historical data
Business decisions are increasingly made “by the numbers” with much reference to historical data. Decision Services need a similar ability to use historical data, and trends/insight extrapolated from it. - Expects multi-channel use
While this is largely covered by the standard items it is worth noting as it means that VERY different kinds of applications will use the service – everything from ATMs and SmartPhones to Call Center applications and Bill Printing. - Manages exceptions well
Not only should it respond sensibly when it cannot decide, it should ensure that enough context is returned as to why it could not decide to assist a manual process - Must explain its execution
Many decisions must demonstrate compliance or conformance with policy. Any decision service must be able to log exactly how it decided and that information must be accessible to non-technical users
A service-oriented approach is not sufficient for agility, merely necessary.
Link to original post
