"The only constant is change" and the world of Service Oriented Architecture (SOA) is no different. No matter how much upfront business process modeling is done, or how perfect your service granularity is, or how wonderfully compliant you are with WS-*, the reality is that your services will have to change to keep pace with change - business agility implies change. And if your SOA has been working, there should be a whole host of consumers of those services who will not be happy at all with having to change. Change involves project cost, cost requires budgetary approval, and approval requires a Business appetite for the change. But since the change won't always appear to benefit the Business, it will very often not be approved, and your SOA will go the way of most system landscapes: to legacy, riddled with complexity, redundancy and consequent fragility.
So how do we get the Business to accept Change as a necessary evil to allow them the agility they dream of?
There are several approaches, including:
1. Governance - the "stick" approach - regulate/force change through rigourous software and portfolio managment processes - this requires an organisational culture of sufficient maturiry and Business buy-in to the concept of Enterprise Architecture to work
2. Charging - the "carrot" approach - charge for the use of services and make it cheaper to reuse than to build, and to be on the latest version than a "legacy" version.