Architecture & Interface Consistency
For example, the architecture and interface must adhere to certain policies and standards to remain consistent across the organization. To achieve this consistency, an organization must drive the standardization and enforcement of such policies and standards during design and development. Once a definable policy has been enforced, consistency and ultimately trust in a SOA asset can be achieved.

The process of promoting trust for a service asset must begin as soon as the asset is created. Early and continuous visibility into the quality of the asset promotes trust and subsequently reuse. To promote trust early, the business must define and enforce policies that govern the different aspects of the services lifecycle. For example, policies that govern the development of services include standards compliance such as schema validity (W3C), semantic, WS-I compliance, and a definition of adopted WS-* standards. Such policies are critical to achieving consistency and ensuring reuse and interoperability.

Policies can also include best practices, both generally accepted best practices and best practices related to the organization's goals for the underlying service artifact. Examples of these domain-general policies include security, maintainability, reliability and performance, and any other policies that are tailored to the domain requirements.

Once the policies are defined, it's critical that they are applied, verified, tested, and measured. We must automate the SDLC infrastructure and process so these policies and standards can be uniformly applied on SOA artifacts by development, test, and QA groups.

Continuous Regression Tests
To implement the policies, contracts, and scenario descriptions for a service asset correctly and robustly, they must be validated via a series of automated, continuous regression suites.

As part of the lifecycle of any given services assets, a continuous regression test must be available (during any release cycle) to provide constant and predictable quality. This continuous regression test must be driven by the business requirements. These tests must include functional requirements, technical requirements, and performance expectations. If these early tests are requirements-driven then QA will have a significant advantage by reusing the test assets.

To ensure secure, reliable, compliant service assets, integration via the asset registry is compulsory. Continuous regression tests should be run nightly during the automated build and the appropriate test data made available via the central asset repository. Tests are then run consistently, without disrupting the existing development process.

This automated testing ensures the automatic validation of requirements and the reuse of test assets between development and QA. Automated regression suites also provide documented proof that the application policies have been enforced, allowing for a more predictable outcome.

Complexity of the SOA Environment
Developing and ensuring functionality in an SOA environment is very complex. The distributed nature of the systems and data make the construction of a staged test environment nearly impossible.

The design part of SOA often requires working with an unfinished or unavailable service; it would be ideal to emulate services to provide encapsulated services. A developer or QA engineer should emulate services and exercise business scenarios very early in the process to vet problems earlier and to judge the service validity and anticipated performance better.

Process Agility & Speed
Advanced platforms deliver an SOA infrastructure that delivers the speed and agility to meet more complex business demands. Unfortunately, QA processes are traditionally serialized and "over the wall." A collaborative and building-block approach to quality is particularly well suited to handling the complexity that comes with SOAs. If businesses want to achieve agility through rapid incremental deliverables, then organizations can't wait for a serialized quality process.

This approach must change for organizations to truly benefit from the agility that SOA can deliver. As such, an iterative and change-based quality process should be leveraged to deliver true SOA agility.

As seen in Figure 1, reusing the test artifacts created in earlier tasks in the business service evolution process lends itself to increased agility and speed.

In addition, the setup of the continuous regression suites mentioned earlier allows for phenomenal visibility into changes.

Change-based testing allows the team to understand the impact to change and versioning - testing only what matters saves time and delivers a complete and validated solution much faster and more accurately.

Integration
Business Partner Integration is still an "integration" event. Bringing any two business processes together will require some give and take. That said, even a standards-based approach to producing and consuming services can be troublesome. To eliminate finger pointing during integration, a business partner must have access to the service "health report" as well as access to an emulated stub with test data that mocks the service interaction. This will prevent errors early in the cycle with visibility into the service assets regression test performance

Development and Pre-Deployment
In a business process context, architects will have to make choices to deploy certain service assets over others. This decision can't be made in a vacuum. Furthermore, when architects are making service choices, they'll have to be able to test and verify the performance of the service asset. So developers and QA can test their business scenario or business process via intelligent stubs that are updated as a result of the nightly regression tests.

Conclusion
Due to the complexities of the SOA environment, there will be a distinct impact on the roles and responsibilities of the organization. Older methods of application testing can't be relied on to ensure quality for any SOA. In today's SOA world, logic is abstracted at the message layer as well as across systems, making testing more complicated and giving QA less control. Although the roles of development and QA will remain the same, the responsibilities of each group will need to shift and the quality process must start earlier in the development lifecycle to ensure secure, reliable, and compliant Service Oriented Architectures.