You've deployed a Web Service. It's been designed, built, tested, and published to your registry for use and is now a critical component in a strategic business application. Your SOA is beginning to show signs of return but what happens when other architects discover your service and begin to design new applications with it? On one hand, you're seeing the benefits of reuse, yet how can you manage a service that's undergoing continuous testing? What happens to your initial business application when one of its key services undergoes a load test for another composite application?

In a SOA, the characteristics of traditional design time and runtime are changed. The rules about ensuring quality are changing as well. No longer is it sufficient to follow design, build, test, deploy, and manage phases. Testing is continuous and can have a drastic impact on production applications. This article will examine the impact of SOA on traditional SDLC thinking and how testing can be done in production environments. We'll also explore the role collaborative SOA quality plays in lifecycle governance.

At the center of an SOA solution is the relationship between service consumers and service providers with distinct lifecycles. Separation of application functionality across lifecycles has profound effects on the development process and serious implications on managing system quality.

A Young Person's Guide to the SDLC
Wikipedia describes various process models that define a Software Development Lifecycle (SDLC) as a series of activities related to the development of software systems. The specific tasks vary between the process models that define specific software development processes but they are more the same than different. They boil down to the same basic steps:
*  Analyze the Requirements
*  Design the Architecture and Implementation
*  Code and Build
*  Test to Verify
*  Deploy and Maintain (Figure 1)

Make no mistake this *is* your father's software development process but it's the basis for many approaches to organized software development.

Agilists (AgileManifesto) have refined this model to make it fit the dynamics of software development and the needs of the business better by adding feedback loops, iteration, deferred requirements gathering, and continuous testing. Defined processes like the Agile Unified Process (AmblerAUP), XP Lifecycle (AmblerXPLifecycle) and the Agile SDLC (AmblerAgileSDLC) are examples of agile refinements to the basic software development process itself.

Traditional or agile the SDLC process has a start, a middle, and an end.

This is not the case with an SOA designed to meet business needs over time. An SOA has no practical notion of start and end much like the Internet has no clearly delineated analysis, design, build, and test activities but is a composite of several interacting components that are constantly coming and going, changing and evolving, and to a greater or lesser extent interacting.

The Impact of SOA on the SDLC
It's important to realize that the SDLC pertains to the service construction process not to the overall SOA evolution. SOA activities focus on higher-level concerns across a service inventory like granularity, coupling, reuse, and governance. This difference is often missed by teams accustomed to building distributed systems or integrations following an SDLC process.

Building SOA like traditional distributed architecture is identified in Thomas Erl's SOA systems report as the #1 obstacle in SOA adoption. The assumption in traditional projects is that you can change the client and the server simultaneously through development. Design, coding, refactoring, and test occur across the boundary of consumer and provider as needed to make the whole system work. The fact that there are clients and servers separated by a network is more an implementation detail that traditional technologies often try to hide for the sake of the programmer.

Service-oriented solutions, as the name implies, focus on providing services to service consumers and that an exhaustive list of consumers and their requirements are not identifiable upfront. This is the essence of why SOA is interesting in business computing. It's incumbent on service providers to understand and anticipate the problem domain and build services that fit naturally in the larger service inventory to provide a valuable capability to a range of future consumers.

This service-oriented focus results in a separation of the service development and consumer development cycles. (Figure 2)

Consumer developers are separated from service developers in time and space. Since there is a clear separation of lifecycles the terms design time and runtime depend on your point of view.

Often service providers follow a design, build, test, and ultimately publish phases where service metadata is made available in registry/repository.

At some future point service consumers discover services as part of a build vs. reuse design process. Services that fit the need are selected for reuse while missing or mismatched services are built. The service consumer project can then follow the recognizable lifecycle phases of build, test, and deploy.

Consumer Design Time at Service Runtime
Several thorny issues arise, in this common case, when a consuming application's design time occurs during its dependent services runtime. The challenges depend on the capabilities provided by the service provider.

An obvious first question is "What endpoint should consumer development use?" When a consuming application depends on external service managed by other people, how should development and test interactions happen? What techniques are available from all of the dependent services? Will you use live production service instances or is there service stand-ins available? What's the expected level of similarity between stand-ins and production systems if they do exist? These determinations need to be made for each service used by the consumer application. What expectations should the consumer team have about the consistency of approach between all of the services used? Do they all have staging instances or do they use different techniques?