Test Driven Decomposition of Legacy Systems into Services

Introduction

A service oriented architecture (SOA) is a collection of self-contained services that communicate with each other, passing data or coordinating some activity. Each service has a provider and one or more consumers. The primary aim of a service is to support business processes; implementing services is not an end in itself, but rather a means to deliver agile systems to support a business (Wilkes & Veryard, 2004). Nevertheless beyond this core requirement there are a number of general principles that can be applied to service oriented architectures. These principles include that a service should have explicit boundaries, be based on schemas and wire formats, not classes and APIs, and be policy-driven, autonomous, document-oriented, loosely coupled, standards-compliant, vendor independent and metadata-driven (Tilkov, 2007). Unfortunately few of these criteria can easily be applied to the interface of a legacy system. In particular, the boundaries and coupling of a legacy system may be problematic. However the value of services in the context of legacy systems is that services do not have to be brand new. They can be fragments of old applications that were adapted and wrapped, or combinations of new and legacy code (Papazoglou & van den Heuvel, 2007).

Though we can perhaps bridge legacy systems and service oriented architectures, there are other questions raised about how effectively an agile software development approach can be applied when working with these systems. Service oriented and agile approaches may conflict in areas such as architecture, team organisation and feedback (Elssamadisy, 2007). It has also been suggested that service orientation encourages upfront architecture while agile does not, though service oriented architectures can be incrementally introduced into an existing system. On the other hand it does pay to understand the strategic direction in advance, including layers and main system components such as infrastructure services. There are also potential conflicts in terms of organizing teams, where a service oriented approach encourages teams to split along functional lines while agile approaches encourage cross-functional teams. This can be a challenge in maintaining perspectives, for example ensuring that business logic is not added to the codified structure of a schema or document. In terms of feedback, a service oriented approach does not have the same focus on frequent feedback at both a technical and personal level. There may also be tensions in terms of the level of ceremony required for different types of software development. Chung et al. (2008) suggest that the mainstream agile methods focus on forward engineering new systems, and claim that a more formal approach related to the Unified Process is required to integrate legacy systems and services. Agile assumptions about delivering potentially shippable code at the end of every iteration are also challenged when dealing with live external services that may require extensive performance and stress testing (Puleio, 2006).

Despite these reservations, the experience reports in this chapter offer a different perspective to some degree. Perhaps the key aspect of the agile approach is flexibility or adaptability, so it is the flexibility aspect of services that assists agile transformation (Sucharov, 2007). Flexibility is required in order to address ever-changing market and customer expectations, and the move to an agile service oriented approach provides the capability to adapt to these ever-changing expectations.