SOA economics: addressing 'boundary costs'

Who's going to pay for this SOA?

Often, the costs of handling and processing SOA-based services gets spread all over the map. This has implications as SOAs grow in scale and complexity.

Oracle's Dave Chappell discusses the matter of "boundary costs" as part of a new article on application grids.  He explains why boundary costs may not be so clear-cut:

"Consider the following scenario - an XML document that may have originated from an internal application, database, an external business partner, or perhaps converted from an EDI document, needs to be processed by a number of services, which are coordinated by a BPEL process or an ESB process pipeline. The common approach is to place the XML document on the bus and have the bus invoke the services in accordance with the process definition, passing the XML document as part of the service request payload. Each service that needs to process that data will access the XML accordingly. Interaction with a database may also occur.

"However, in practice there are challenges to scalability when using this approach. What is the cost of crossing the boundary from one service to the next? How many times does that cost get incurred in the context of invoking a simple business process? What if the XML document is really large in the multi-megabyte range, or there are lots of them numbering in the thousands, or both?"

The costs can multiply if large XML messages and data files are being passed from one service domain to another. Dave says one way to manage boundary costs is through implementation of application grids that spread compute operations across a distributed network of machines to "lessen the processing and memory requirements of our data consumers - SOA services, application servers, and client applications."

He adds that using an application grid "can also implement patterns where we pass around references to data, rather than the data, resulting in huge efficiency gains in the communications layer, and dramatically reducing or eliminating the boundary cost."

Dave raised some good issues in his article, and as SOAs grow in scale and complexity, the loads on servers and infrastructures will grow significantly as well. If one business unit starts the SOA ball rolling, and other units begin accessing and reusing its services, who should pay for all the new equipment and software to support growing demands for reliability and scalability?