Making solutions scale is nothing new. However, the SOA technology and approaches employed recently are largely untested with higher application and information and service management traffic loads. SOA implementers are happy just to get their solutions up and running, but, in many cases, scalability has simply not been a consideration with SOA, nor is load testing, or other performance fundamentals for that matter. We're seeing the results of this neglect now that SOA problem domains are exceeding the capacity of their architectures and the technology in many instances.

My daily routine is to answer e-mail from somebody, somewhere, asking me why his SOA doesn't scale. Unfortunately, the answer is something these people don't want to hear. It's really the fact that they took the wrong approach, used the wrong technology, and the fix is going to be painful. However, you can avoid these issues just by doing some additional planning and testing upfront before you commit to a solution.

The core issue is that many SOA technology vendors haven't focused on scalability in their solutions. Instead, feature/function enhancements are the rule of the day. It's more important to add orchestration features and more adapters to your solution than to figure out how to pump more information, and manage more services. So these single-threaded solutions, on top of the issues around Web Services in general, make for solutions that are more about integration than true business transaction loads. Not to mention supporting the notion of both reuse and agility.

Its dependence on the traditional architectures is the core problem of scaling SOA solutions. The most popular SOA technologies require that all information and services under management do so in a single server domain (in most cases). This processing is a mixture of service abstraction, service management, schema and content transformation, rules processing, message splitting and combining, as well as message routing (ESBs). This is despite the fact that Web Services, at their essence, are more about the distributed service invocation model that's not as well followed when considering instances of technology. Indeed, most SOA solutions out there are bound to a single service approach, and don't provide a smooth path to scalability.

While the scaling crisis around SOA isn't well known at this point, considering the fact that the larger SOA projects have just started moving, there are a few vendors that I've been watching that provide the distributed architecture needed to bring better distributed reliability to SOA. Rogue Wave's HydraSCA, for instance, provides a service grid based on "Software Pipelines," an architecture and methodology that enables the development and deployment of scaleable SOA-based applications. Rogue Wave is promoting Software Pipe lines as a cross-vendor approach to service distribution, and other key players are in there as well using similar implementation patterns.

What's interesting is that Software Pipelines, the approach and the instance of Hydra technology, increases scalability by providing concurrent computing of business services in and across servers, while preserving business rules. For those of us who have been in the business for a while, this is common sense scalability, meaning that the processing is distributed across more than one processing entity, and so the throughput increases using this parallel processing model. As long as this distribution is managed well...it's very effective.

There are other SOA solutions moving in this direction as well, and as SOA becomes more accepted, the ability to make your SOA scale is clearly going to be on the critical path. What's key is that those who select SOA technology that needs to scale consider the following basic principles:

• Consider performance and scalability as something that's systemic to the architecture; it can't be an afterthought.
• Make sure to do a proof-of-concept to demonstrate that the technology works as advertised, and work with the vendor to understand the best way to implement the technology.
• Consider operational issues during the design. Who's going to maintain it, and how?
• Learn how to do basic performance and scalability modeling. While never perfect, they do indeed provide you with a jumping off point when considering high performance and scalable architectures.
• Never be afraid to change approaches and technologies if they don't seem to be working out.