≡ Menu

SOA is necessary for agility but not sufficient


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

  1. how many services must change to accommodate the new business requirements
  2. 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:

  1. that only the Decision Service needs to change
  2. 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.


Comments on this entry are closed.

  • Fred Cummins December 10, 2008, 7:19 am

    I agree that simply applying software measurement techniques is not an adequate measure of agility.  From my perspective, SOA is a business architecture that represents not only the application of technology, but a fundamental change in the design of the business.  This is a paradigm shift for business people.

    My proposal is that the impact of a change, hypothetical or otherwise, be assessed in terms of the impact on service units (or in the absence of SOA, the business operations), the business activities that are responsible for managing the business capabilities to provide services.  These changes would include process, policy, responsbility, personnel, and decision making as well as applications of technology. 

    So the measures are essentially measures of the cost (and time) to implement change.  It’s not an absolute measure, but it provides executive management with a basis for considering risk in their ability (or inability) to change in response to changing business circumstances.