Sometimes when we're faced with addressing a complex engineering problem it's helpful to reflect on antipatterns. Doing so does more than track wrong solutions to common problems; it also focuses the mind on the interaction of the most important elements of the problem domain. This is true for all engineering, not just software engineering. Suspension bridge designers know to be on the lookout for torsional oscillations because of the collapse of the Tacoma Narrows Bridge, but they also better understand the importance of stiffening the structure in general. The goal is to limit the number of times the antipattern emerges and to notice it when it comes around again. SOA uptake is at a point where such a treatment of antipatterns is helpful.

In my job I work with Fortune-500 clients on SOA enablement. Like everyone else who works in this space, I have to try to cut through both the hype and the FUD (fear, uncertainty, doubt) surrounding SOA to right-size solutions for individual business problems. Sometimes the requirements are very narrow, e.g., "We would like to federate with external partners." Sometimes they are very broad, as in, "We would like to re-tool the entire enterprise for more efficient and agile execution." I like to think of SOA as the synergy between WS standards and tools, and an adaptive organizational structure that can leverage the technology to manage complexity better. In fact, when it comes to complexity management, I tell my clients that with an SOA approach we can fashion an architecture to get to their end state that can be wholly contained on one whiteboard.

Here are some fallacies about SOA that keep architects from being able to concisely contain their SOA solutions on that whiteboard.

1. It's Not a Platform
SOA can't be purchased solely from a platform vendor. IBM, BEA, Oracle, SAP, etc. actively market to their customers the premise that more from their product lines = more SOA. This is not to say that these vendors don't have good products that fit into an SOA quite nicely. We are starting to see serious BPEL, WS-ReliableMessaging, and WS-Addressing implementations from platform vendors. However the concept of the platform, which has gained acceptance over the last two years, serves to tie customers into a one-stop shop for both infrastructure and development. This is antithetical to SOA, whose standards make it possible and advisable to pick the best tools available for the task at hand (and no more). Throw in the marketecture avalanche and customers are reluctant to incorporate needed SOA infrastructure elements outside of the platform. By way of example, if you are planning to implement a partner federation model, you can't get there with a platform alone. Worse yet, we are also seeing stuff like BPELJ out of platform vendors, which is a recipe for tie-in masquerading as an unnecessary standard. The moral of the story: take a holistic approach to SOA infrastructure and avoid platform tie-in. A great place to start is at your favorite open source infrastructure project. Work your way up the food chain from there.

2. It's Not Just a New Name for an Old Development Paradigm
There is a lot of FUD being spread by my fellow Java developers and architects that SOA is just a new services architecture like CORBA or Java remoting. While it is certainly true that loosely coupled RPC service architectures have been around for at least 15 years, SOA is a deceptively powerful simplification of the paradigm. The use of XML and SOAP's realization of an intermediary framework finally gave us true extensibility. Microsoft's signing onto the standards gave us a shot at interoperability - imagine if Microsoft had not signed on and we had a world with XML and SOAP versus MS-XML and MS-SOAP. If it isn't obvious the power that these improvements brought to the table, tell me how to develop a federated security domain of thousands of partners around the world to run a global logistics business, for example, with Java and CORBA. We can do it today with WS security standards and tools, and express the architecture on that one whiteboard.

3. It's Not Custom
Almost all standards are built on other standards and add their own functionality. Standards are the life blood of SOA, even though many are still evolving. The evolving part scares people, but in fact there are very few standards that are truly final. SOA is best served by maniacal adherence to standards. Deviate from them only when they just don't get the job done. As an example, UDDI is probably the most prevalent case in SOA of an often avoided (or at least augmented) standard. However even in this case, registry vendors I am aware of take care to render standard UDDI on demand, and support UDDI as it evolves. So when the time comes to federate registries with other departments or partners via UDDI evolved, you're good to go. If you are eschewing UDDI for a shared Java properties file or other similar service location mechanism, you're on the wrong track. In general, finding a way to support standards in your SOA will keep you healthy in the long run.

4. It's Not Just Hype
Granted, there is more hype around SOA than anything we've ever seen in IT before. A year or two ago a perfect storm of research firms, infrastructure and platform vendors, and integrators emerged under the SOA banner in a post-boom business climate that demanded more functionality from less investment. Throw in the media coverage and the effect was to all but obscure the real technology revolution that was happening in the form of emerging standards and tools.

It is easy to dismiss the hype as "the next big thing," but real value is being experienced, especially by medium and large enterprises. The value comes in two flavors: the ability to address problems that were previously intractable with the new standards and tools, and the ability to become more agile and better manage enterprise entropy. A good example of the former is the use of SOA security standards to build application security frameworks in a much easier way that support things like digital rights management and portal security. Once you cut through the hype and apply the technology in its pure form to your problem domain, real value is easy to find - and lots of businesses are realizing it now.

5. It's Not a Data Integration Panacea
There is a limit to the amount of data source dissonance that can effectively be managed in an SOA. If you have a bunch of different data sources that have evolved over time into a frayed network, SOA is not going to derive a better integration mechanism for you. It's not going to make it any easier to combine result sets into a workable view, and it might make it much worse if you get the XML translation or granularity wrong. It's bad news to see a bunch of services exposed against different customer data sources, for example, with business processes trying to combine them into a unified customer profile. Look to a virtual data service to generate a holistic view of the data and then call that service from your wider SOA. You can either construct this service yourself or purchase it from one of the emerging EII vendors.