SOAs are in essence distributed systems, meaning that the services are running all over the place, as are the data services, and persistence layers. As such many SOAs that I'm seeing deployed have a tendency to be out-of-balance or a disproportionate portion of the processing is taking place within a small group of services, and the others are not pulling their load. Thus, you may have the old 80/20 rule again, SOAs are in essence distributed systems, meaning that the services are running all over the place, as are the data services, and persistence layers. As such many SOAs that I’m seeing deployed have a tendency to be out-of-balance or a disproportionate portion of the processing is taking place within a small group of services, and the others are not pulling their load. Thus, you may have the old 80/20 rule again, with 20 percent of the services handling 80 percent of the processing. So, how did this happen? Many who create SOAs simple place services interfaces on existing processes and APIs and call it good, and don’t really understand what’s in those processes or opportunities for redesign to optimize the architecture. Thus, you just have lines of code that are repurposed as services, and little architectural thought goes into how all of those services work and play well together, and do so while sharing the load.“Services balancing” is something we have not explored yet in the world of SOA because there are not that many SOAs yet, first of all, and performance is typically is an afterthought (so is security, as I’m finding, but that’s for another blog). However, a few SOAs where performance is a concern, are finding that their SOAs are out of balance, and they have to move quickly to fix the issue to optimize their implementation. So, what do you need to consider in terms of service balancing?First, as the services are designed you should consider the overall balancing of processes between the services. Truth-be-told, sometimes you’re stuck, and there is little you can do to move processing from one service to another. However, more often than not your services are “balanceable” and you should consider how the processes are distributed across services, as well as logical organization of those services. Second, you should learn to create a performance model using the profiles of the services. While these are not foolproof, they do indeed provide a basis of understanding pertaining to the performance tradeoffs of your SOA. You would be surprised how much a little time invested in analysis will save your butt during implementation. Performance is clearly one of those things. Software Development