Service Refactoring

How can a service be evolved without impacting existing consumers?

Problem The logic or implementation technology of a service may become outdated or inadequate over time, but the service has become too entrenched to be replaced.
Solution The service contract is preserved to maintain existing consumer dependencies, but the underlying service logic and implementation are refactored.
Application Service logic and technology are upgraded or replaced, as necessary, and must undergo rigorous testing.	Impacts Service refactoring introduces governance effort as well as risk associated with potentially negative side-effects introduced by new logic or technology.
Principles Standardized Service Contract, Service Loose Coupling, Service Abstraction	Architecture Service

Table 8.13 – Profile summary for the Service Refactoring pattern.

Problem

Even when delivering services as part of a top-down approach where service inventory modeling considerations can be factored into the initial service design, over time unforeseen performance and business requirements may demand more from a service than it is capable of providing.

The traditional approach of replacing outdating implementations with newer applications is undesirable due to the consumer dependencies that are formed on (mostly agnostic) services.

Figure 8.48 – Consumers of an existing service demand new requirements for which the service was not originally designed.

Solution

Software refactoring is an accepted software engineering practice whereby existing software programs can be improved without affecting the manner in which they behave. When applied to service design, this approach provides more opportunity for services to evolve within an organization without disrupting their existing consumers. As shown in Figure 8.x, with the application of this patter the underlying logic and implementation of a service can be regularly optimized, improved, or even upgraded while preserving the service contract.

Figure 8.48 – The red areas indicate parts of the service that can be refactored without compromising existing consumer relationships.

Application

The refactoring of existing service logic or technology introduces the need for the service to undergo redesign, redevelopment, and retesting cycles so as to ensure that the existing guarantees expressed in the service contract can continue to be fulfilled as expected (or better).

This pattern can be more successfully applied when the service has already been subjected to the application of the Decoupled Contract pattern and the Service Loose Coupling design principle. The separation of service logic from a fully decoupled contract provides increased freedom as to how refactoring can be carried out, while minimizing potential disruption to existing service consumers.

Impacts

Because existing, proven logic and technology is modified or replaced as a result of applying this pattern, there is always a risk associated with the reliable delivery of capabilities to existing service consumers. The degree to which this risk is alleviated is proportional to the maturity and suitability of the newly added logic and technology and the extent to which quality assurance is applied to the refactored service.

Relationships

The extent to which Service Refactoring can be applied depends on how the service itself was first designed. This is why there is a direct relationship between this pattern and the Service Normalization, Contract Centralization, and Decoupled Contract patterns. The abstraction and independence gained by the successful application of those patterns allows services to be individual governed and evolved with minimal impact to consumer programs.

Depending on the nature of the refactoring requirements, Service Decomposition, Concurrent Contracts, or Service FaŤade may need to be applied to accommodate how the service is being evolved. Capability Recomposition is furthermore supported by the improvements made as a result of successful refactoring efforts.

Figure 8.50 – The Service Refactoring pattern relies on several key contract-related patterns to ensure that refactoring-related changes do not disrupt existing service consumers.

Case Study Example

Case study content is not available on this Web site.