"These must, indeed, be splendid clothes!" thought the Emperor.

Here's something I've been meaning to get off my chest for a while now. It's all this ongoing hype about Service Oriented Architectures (or SOA for short). I'm sure you've heard about it, but for those in need of a gentle refresher:

Simply put, SOA-based software applications are designed as a loosely coupled distributed network of services, from which one component can request things from another one in a standard way. Using SOA, the architecture of an application is based on dividing its functions into services that are accessed using some protocol like SOAP/XML/RPC over web services (although there are other implementation mechanisms in common use as well). Thus, the distinguishing characteristic of SOA based applications over traditional ones is that the primary structuring element is the set of services. Since these services can interoperate over different development technologies (such as Java and .NET), the services are reusable between different applications, thereby reducing development time, integration and ongoing maintenance costs. No wonder the evangelists of this stuff propose it as the holy grail for enterprise interoperability -- use a SO architecture and voila ... sounds great, right? Bzzzzt. Thanks for playing.

Let's looks at a few examples. The telephone and its associated directory service provides a standardized point-to-point connection mechanism that we're all pretty comfortable with. Similarly, SOA implementations specify how to locate and connect to other applications on the distributed network (the syntax of communications is specified by the implementing technology), but by definition, they can’t really help with the semantics of the communication, regardless of efforts such as the Resource Description Framework (RDF) or the Web Ontology Language (OWL). These approaches, while useful, can provide only another level of indirection but do not solve the fact that software cannot read an arbitrary communique. Try as you might to settle on a language for every possible call recipient, if the guy answering the phone doesn't speak your dialect, you're pretty much pooched. Ok, that's point one.

Secondly, in my business, which is focused on global derivatives trading systems and financial risk management, applicable enterprise level applications have an a priori dependence on firm-wide data availability and information standardization. In this domain, which many preach is the perfect application of SOA, it's often the scale of the problem that drives system complexity and makes software development so difficult. Let's take an international investment bank, with more than a million or so transactions per day created or amended, across seven time zones using, say, eighty front office trading systems. Now suppose the middle office wants to run a set of nightly global risk reports on the bank's entire book. You've got a two hour window to calculate the results, because that is the only time all the trading floors are closed across the globe and changes to the book are not being made. Keep in mind that each of those eighty trading systems represents transaction, counterparty, market and reference data in a completely different way, using a system specific proprietary lexicon -- all of this data needs to be collected and converted to a standard form on an intra-day basis for consumption by the risk reporting engine for each night's run. For example, if one system sends a trade with the counterparty code of I.B.M. and another IBM, these two codes need to be linked together or the corresponding positions will be incorrectly rolled up. When the reports are wrong this is a bad thing. The regulators can get involved and things get messy -- for good reason, this makes some people very, very upset.

Think about it. The IT challenge here is that the risk engine needs to access and price every single transaction (sometimes many, many times under scenario analysis) in the shortest possible amount of time and tally the numbers for the reports. Speed is paramount, and information standardization critical to the results. If an application needs to remotely call into a bunch of distributed services to collect the data, pass that off to another for analytics, you're a day late and billions of dollars short. You've already taken too long. Read: remote communication == "waaaaaaay too sloooooow". In other words, performance metrics and instant availability of standardized data are architectural requirements in a context where demand always exceeds capacity.

When you really look under the skirt, SOA is nothing more than the same old tried and true distributed computing concepts in a brand new dress. In any performance-critical, information-centric context, SOA does not address the most fundamental requirements for developing real-world solutions. In fact, it ignores them. The focus is on the wrong thing. It's not the interfaces to all of the systems on the network that are dynamically changing, it's the content. Remember the old saying? If it sounds too good to be true then it probably is? Well, you got it.

Now that I have that stake firmly pounded into the ground, I'd best get off this SOAP box ;-) and back to work. Cheers.