Responsibility 6: Implement formalized change management. And implement interface versioning to limit the number of clients impacted by changes (decoupling).
Background
Service Oriented Architecture (SOA) typically targets reducing duplication and increasing reuse as a means to promote a more cost effective and agile operating model.
As part of growing a SOA, we hope applications use existing services to solve business problems. Over time this translates to a service having interface dependencies with many client applications. Conversely, if a service only interacts with a single client this is not optimal as point-to-point solutions are not the primary focus of SOA.
As the number of interface dependencies grows for a service, there can be challenges. Examples:
Considerations
It is the responsibility of the service provider to follow a standard, generally accepted versioning strategy. This consistency is in keeping with Responsibility 4. A complete strategy supports major versions (breaking changes) and minor versions (compatible changes within a given major) of the interface definition or contract. The service provider must assess whether a change to the interface contract is a major or minor change.
A minor change is a compatible change. For example, adding an optional element to the service's request or response for a customer's "maiden name" would be considered a minor change. Only clients needing visibility to "maiden name" would need to upgrade to adopt the new interface version. All other clients will continue to work without any changes.
It is important to identify opportunities leverage minor versioning. These changes can be implemented much easier than major changes but always in keeping with Responsibility 5. No hacks please :-).
The service provider must maintain effective communication with all application owners that invoke a given service. It is the responsibility of the service provider to ensure awareness and coordinate all upcoming changes.
Leveraging security is an effective method to identify client applications that invoke a given service. Air-tight impact analysis can be achieved by all services implementing a common enterprise-wide security mechanism. This can be justified through the benefits of enabling effective impact analysis and through Responsibility 4. The basic mechanics include:
As part of growing a SOA, we hope applications use existing services to solve business problems. Over time this translates to a service having interface dependencies with many client applications. Conversely, if a service only interacts with a single client this is not optimal as point-to-point solutions are not the primary focus of SOA.
As the number of interface dependencies grows for a service, there can be challenges. Examples:
- Implementing changes to the interface definition can be a lengthy "ocean boiling" experience when many client applications are impacted.
- A change is needed to a service to meet a new set of requirements. How do you pinpoint all applications that are impacted? And can we spend less time and energy assessing impact?
- Unexpected outages can occur if impact analysis is inaccurate.
Considerations
It is the responsibility of the service provider to follow a standard, generally accepted versioning strategy. This consistency is in keeping with Responsibility 4. A complete strategy supports major versions (breaking changes) and minor versions (compatible changes within a given major) of the interface definition or contract. The service provider must assess whether a change to the interface contract is a major or minor change.
A minor change is a compatible change. For example, adding an optional element to the service's request or response for a customer's "maiden name" would be considered a minor change. Only clients needing visibility to "maiden name" would need to upgrade to adopt the new interface version. All other clients will continue to work without any changes.
It is important to identify opportunities leverage minor versioning. These changes can be implemented much easier than major changes but always in keeping with Responsibility 5. No hacks please :-).
The service provider must maintain effective communication with all application owners that invoke a given service. It is the responsibility of the service provider to ensure awareness and coordinate all upcoming changes.
Leveraging security is an effective method to identify client applications that invoke a given service. Air-tight impact analysis can be achieved by all services implementing a common enterprise-wide security mechanism. This can be justified through the benefits of enabling effective impact analysis and through Responsibility 4. The basic mechanics include:
- Each client application should be issued a unique identifier or token to use as a credential. This is passed by the client to all services it invokes.
- The service authorizes client-specific access using the unique identifier or token. An authorization rule must exist for a client to invoke a service successfully--anonymous access should not be allowed.
- Consider measures to prevent the client's unique identifier or token from being spoofed or shared among multiple applications. Addressing this is part technology (think public key encryption) and part governance (or "g8e" for those that cringe at the term governance :-).
- Authorization rules (and secondarily usage metrics) are used to perform air-tight impact analysis.
View security as your friend in managing interface dependencies between all clients and services.
In a later series, I plan to blog about the details of an effective major/minor interface versioning strategy. An effective versioning and decoupling strategy is a key component to realize the benefits of agility and reduced complexity.
