This article focuses on the third type of virtualization – virtual services – which happens outside the data center. For the rest of the SOA application lifecycle, our ability to create virtual test beds only goes so far. Businesses often rely on actual live implementation for the purposes of validating and developing for SOA; however, these complex interconnected environments cannot be replicated by hardware virtualization techniques. We need to extend virtualization into the actual distributed software components and services running on those environments.

The Challenge: If SOA Can’t Virtualize, It’s Not Agile
Virtualization at the hardware and data center level generates an almost immediate payback in saved operating costs – potentially saving several million dollars in IT costs on a near-immediate basis.

However, when we distribute component- or service-development tasks across multiple teams, we often forget that these teams still need access to live versions of the rest of the application in order to complete their own development and testing goals. There is still a high level of dependency and interconnectedness between all of those teams to deliver a completed workflow. For larger-scale enterprise systems, this puts a harsh limit on the ROI of SOA.

There is a way to connect these two technologies using service-oriented virtualization, or SOV: the strategy of simulating the behavior of deployed software assets, and the synthetic construction of those not in existence, that make up an enterprise SOA application.

Maximizing the value of SOA on a larger, enterprise-wide scale is difficult, if not impossible, without also leveraging SOV.

Challenges: Stumbling Blocks for SOA
Companies adopt SOA best practices to realize business agility and cost benefits. Unfortunately, when the SOA application attempts to scale to meet the real-world needs of larger enterprises, the best-laid architectural and governance strategies for SOA still fall short, even with virtualized servers. There are several reasons why this happens.

Contention for Shared System Resources
SOA is all about leveraging enterprise systems by offering them up as shared services. However, the problem of access to shared resources plagues every single SOA initiative. A manager of a key ERP system or mainframe may be protective of their application in production and limit development and testing teams from directly accessing the application to avoid unforeseen issues (see Figure 1).

In addition, even if access is allowed, live services are often constrained by the demands of multiple organizations in an SOA environment. Agility suffers when teams are forced to queue up for access to a realistic environment to test and develop against. In larger-scale enterprise applications, creating another instance of the environment through hardware virtualization alone is cost-prohibitive.

Discontinuous Development and Integration Lifecycles
Developers need modeled service interfaces as placeholders to determine how their services will interoperate with others. For example, one development team is building out customer data, while a second team of developers is creating account data. The two teams will rely on each other’s services as the applications are being developed in tandem. Each team is relying upon access to near-finished or implemented services to prove that their own services interoperate correctly.

SOA enables agility by loosely coupling components as services, so they can be developed and integrated in parallel by smaller, more distributed teams. How can we actually achieve such a level of parallelism when there are still dependencies?

Picture the typical project plan or Gantt chart (see Figure 2). There is always a next Dependency of an available component in the project that must be met before the next development team can continue on the next component. This is exactly the mold we are hoping to break with SOA.

Increased Complexity and Heterogeneity
While a number of initiatives for doing SOA are Web services (WSDL/SOAP) centric, only about 50% of the SOA initiatives at best-in-class companies are Web services based. There are a variety of technologies being used to create SOA middleware, which may be very valid, and possibly better for a given organization than a Web services stack, for instance, using an ESB with little reliance on Web services.

To ensure SOA quality, teams need to validate the implementation and side-effects that occur across heterogeneous technologies, as opposed to just testing their own selected Web service or middleware layer.

High Cost of SOA Test Environment Maintenance and Support
In order 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.