SOA

High Cost of SOA Test Environment Maintenance and Support
To contribute services to an SOA application, many organizations attempt to replicate and maintain their own test environments. However, replicating all of the components they need to interact with in their own staging environment is an incredibly costly process to manage. It requires a high level of configuration, licensing costs, and maintenance to keep that test build current, even if it is running on virtualized hardware (which also has some incremental licensing costs). Many enterprise systems that are leveraged by SOA are simply far too big, and have too much overhead to be virtualized.

Instead of creating an enormous test infrastructure by attempting to replicate dozens of changing services, SOA needs a strategy to decouple those teams from their dependency on the implementations. This will provide a way to test and develop against the current conditions that exist in deployment.

Grand Scale of Data and Systems of Record
The final, and perhaps the most difficult, obstacle to attaining enterprise-ready SOA is the sheer scale of the systems and data that need to be managed. To test the actual results of an SOA application, organizations need a realistic set of data to input, and then get out of the environment under test.

While they can map much of the interaction with other services according to the metadata set forth during architecture and design processes, but once they get past that ideal model of connecting the endpoints, they still must contend with the nitty-gritty of a CRM mainframe or enterprise system, and the administrative owners of that system. The data and business logic embedded at these layers have been added to and customized over the years. Implementing a complete mirror image copy of the system and data to test against requires another enterprise license and implementation team, which is far too costly.

Introducing Service-Oriented Validation
Service-Oriented Virtualization (SOV) is the IT strategy of simulating the real-world behavior of software assets that comprise an SOA application, thereby decoupling development and testing teams from dependency on deployed services and their underlying implementation layers.

SOV involves the practice of modeling and simulating both in-design and deployed services as virtual services, which are made available to the extended SOA team for testing and developing their own services and workflows, without reliance on a live instance of the services. When teams are decoupled from their dependency on deployed services and implementation layers, the expected SOA benefits of increased agility, faster time-to-market and reduced delivery cost are fully realized. To make an analogy, SOV is to SOA, as hardware virtualization is to the data center.

Examples of SOV within the SOA Lifecycle
SOV not only impacts the quality of the finished application, it plays a huge part in accelerating the development and governance processes of the SOA lifecycle. There are many more scenarios for adopting SOV practices that have yet to emerge within the enterprise.

SOV Use Case 1: Agile Development of New Functionality for SOA
Enterprises are moving away from the monolithic, slow-moving "big bang" implementations of yesterday, when entire applications were developed, tested and released as one sequential process, usually under a centralized authority.

Today, applications are loosely coupled collections of services, consumed flexibly as agile workflows at runtime, managed by distributed teams of agile developers and partners, for an agile SOA application infrastructure that will turn on a dime to meet changing business needs.

In order to contribute services that meet business requirements, developers and QA teams must test against virtual services that are also currently under development. If companies want to get the agility benefits of SOA, then all of these teams must develop and release their own services in parallel, on their own lifecycles, without having to wait on others.

The SOV Approach
Rather than waiting for other teams to provide access to finished services to test against, the team models the behavior of the services they rely on as virtual services (see Figure 3).

• A team that needs a copy of a service to test and develop against analyzes the behaviors of a service, its controls and responses to stimuli, and its underlying implementation and data as a whole to model a virtual service.

• A developer of a service can also publish an incomplete or "to-be" version of their service as a virtual service while in development.

• The virtual service is leveraged by other development and QA teams to test their own services.

• This saves development/QA cost and time of coding custom test clients or "mock services" that are not realistic models of the real behavior of dependent services anyway.

• It allows highly parallel, agile development and testing collaboration across the organization for faster, more predictable time-to-market with new functionality.

Example: Providing Access to Regain Agility
A leading financial services firm that split up its centralized development function to a more SOA-like model parceled out different business processes to specialized service development teams to enable shorter service delivery cycles. While initial results showed a faster delivery process, as soon as more new services supporting the SOA applications were pushed into deployment, a huge increase in customer support issues occurred.

To solve this problem, the company resumed centralized control over releases, requiring all "final" services be turned in by November, so a comprehensive environment of the entire SOA could be created for a two-month testing cycle resolving in January. If any error occurred during the yearly testing cycle, the system administrators would roll back those candidate services to the previous version. This meant only one development cycle a year - and a release only if everything worked right. This was not very agile by any definition.

By moving to an SOV model, the firm is now able to break out of this yearly cycle. Development teams now model against the target environment as a virtual service and conduct testing on-demand against that environment. They can also provide a hosted virtual service to other dependent teams, so they can have an earlier asset to test against. As a result, the company has disbanded its control committee and moved to a quarterly release cycle, with a continuous, agile release cycle, and build and test activities happening more responsively to customer needs.

Add Your Feedback

In order to post a comment you need to be registered and logged in.

Register | Log in

Please wait while we process your request...