and QA process, promoting faster development time and ultimately faster time to market. SOA, at its most basic level, is about hiding the complexity of underlying systems through an agreed upon set of contracts and interfaces. It is also entails thinking very differently about what developers are being tasked to deliver. The application is no longer the unit of deliverable work. Developers are being asked to now to deliver services that execute specific functionality and can then be assembled into a nearly infinite combination of "enterprise applications," with the contracts and interfaces defining how the services will interact with the larger system. Project specifications can be broken apart into logical, easily digestible pieces defining the services, contracts and interfaces for each development team.
But how does all of this allow for the improvement of the QA and testing process of companies undertaking a migration to SOA? One of the key tenets of SOA is the agreement on interface service contracts generally defined in Web Services Definition Language (WSDL), independent of the actual technology used to implement the service. One of the key tenets of an agile development methodology is "test first." The possibility for an improved QA practice lies in combining these two approaches: taking advantage of the rigorously defined interface definitions to enable early interoperability testing for consumers of services.
The first step is to establish a process for formalizing interface agreements for the various services comprising an application using WSDL. This can be augmented with text design documents, but having these interfaces specified in a formal language is critical. These contracts (both WSDL and text documents) need to be managed in a repository that is accessible by the various development teams, regardless of their location.
The next step is to generate, for each service contract, a simulator that can be used by consumers of the service to verify that their use and assumptions conforms to the published contract. Generating these simulators (complete with dummy data sets) is made possible by defining the interfaces using WSDL since the combination of WSDL and XML Schema actually provide enough information to drive either code generation or interpretive simulation. These simulator "kits" should then be available for download from a common repository, or the organization can choose to set up one or more test servers on which these simulators are deployed.
Agile SOA Development
Clearly, any process must allow for iterative development - the reality is that interfaces will change during a development cycle. However, by establishing a process and culture whereby development teams are thinking in terms of services and service contracts and taking advantage of repositories, RSS and other collaborative development technologies, it is possible to set up an agile SOA development process.
The idea is simple and it can be no more than test first methodology being applied to SOA. The challenges, as always, are more organizational and social than technical. Without a mandate for each team to deliver well-documented interface agreements and simulators or alternatively, funding a centralized group to ensure that the agreements and simulators are in place, this approach will clearly not work. Our experience with leading IT organizations has shown, however, that this approach results in faster time to market with lower defects, so there is a tremendous ROI benefit to adopting it.
The ongoing adoption of SOA and distributed development models promises greater productivity and greater capability to respond to changing business dynamics. However, these changes can also introduce new bottlenecks that can easily wipe out the benefits of agility and time to market. By thinking in services at all phases of the development