With apologies to the writers of Amadeus

MOZART [The fresh SOA Architect]

But it's new, it's entirely new. It's so new, people will go mad for it. For example, I have an activity in the second step - it requires calls to two services in parallel. Then a third service is called to verify the name of the customer, and a fourth to perform some security checks. Then a logging service makes five and so on. On and on, six, seven, eight! How long do you think I can sustain that?

JOSEPH [The jaded IT Manager]

I have no idea.

MOZART

Guess! Guess, Majesty. Imagine the highest number of services that could be orchestrated this way, then double it.

JOSEPH

Well, six or seven! Maybe eight!

MOZART

Twenty, sire! How about twenty?

Sire, only SOA can do this. In a traditional web application, if more than one service is called at the same time, it's just chaos.  No one can manage the flow. But with SOA, with SOA you can have twenty services all executing, and it's not chaos- it's a perfect orchestration. Isn't that marvelous?

The response that Joseph should give Mozart at this point is, "It is. Now answer me a question. How long do you think the customer will wait? Guess! Guess, Mozart! Imagine the longest time a customer would wait, then halve it. Will this new architecture be able to do that?"

The process of building out a SOA is a lot like composing an opera. There's a story(the architecture), an orchestra (the infrastructure), and a bunch of services (the singers). All three must be coordinated carefully in order to create perfect harmony.

You can't ignore any one of the pieces or you risk a lackluster performance that leaves no one satisfied and everyone wondering why they bought tickets in the first place.

A great composer like Mozart knew what melodies should be duplicated and by what instrument as well as how important the supporting harmonies were in creating the perfectly balanced musical score.

A great SOA architect also understands that the supporting harmonies (infrastructure) is just as important as the melodies (services) in building out a successful SOA.

Just as some melodies need to be duplicated by several instruments, so, too, do some services need to be duplicated in order to support service level agreements and to meet capacity demands. And just as counterpart harmonies support those duplicated melodies, balancing them, so too does a strong infrastructure support the duplication of services.

Whether you're just building out your first SOA or trying to improve an existing implementation, remember to consider the impact of infrastructure on its overall balance. It could be the difference between composing music that will live on for centuries (an architecture that will support the business for many years to come) and composing a song that you can't even give away free on the Internet (an architecture you'll replace in 2-3 years).

For more on the impact of infrastructure on SOA and performance, check out these resources:

SOA + WOA = NOA

SOA Delivery

The Role of the Adaptive Network in SOA

Centralized Authorization and SOA

SOA & Web 2.0: The Connection Management Challenge

SOA Performance: Round II

SOA and Performance

Imbibing: Mountain Dew