Snake oil, in its uncomplimentary form, denotes a miracle drug guaranteed to cure all that ails you, yet whose mechanisms are shrouded in inscrutable details that wither in the uncompromising light of science. As nations expanded their empires - most notably the United States in a rush to fulfill its Manifest Destiny in the 1800's - grifters would rumble into frontier towns in order to extract precious dollars from unsuspecting and ill-informed citizens, selling them secret elixirs of amazing potency. These medicine men would put on a great show for a town typically lacking in entertainment, short of the local saloon which was already so mundane to the locals. These people were looking for a release, a cure that required no effort, a turn to "modern science" that would relieve them of their sufferings and perhaps more importantly, their fear of the unknown which was vast in this unscientific age.
Alas, there continue to be snake oil salesmen (and now saleswoman), but their elixirs often take a form that's far more illusive than liquid medicine. Most modern day grifters no longer ride into town on a wagon, but rather use late night TV, well-placed "scientific" advertisements, or the Internet to ply their wares. The better-capitalized ones will fly in to town with their entourage, set up a meeting at a high-class hotel, dazzle an unsuspecting and ill-informed audience with their PowerPoint wizardry, then fly away, leaving their local representatives to rake up the cash that's been thrown on the floor. Almost immediately, these local citizens will feel wiser and stronger, simply having been exposed to these confident, polished, and well-fed men and women and their shiny brochures - why, even the articles in trade magazines proclaim that It Is Good! - but once back at work and faced with the real world, they quickly find that instituting some of these new-fangled ideas is not as easy as they were led to believe and that these elixirs are not so far-reaching as promised them. A little later, some of them will get an uneasy feeling that maybe - just maybe - there are some simple fundamentals on which their organization is not executing well, and that the whole elixir exercise was worse than useless, because it actually diverted them from their real problems while creating new ones. Far too many of those people will get over their discomfort just as soon as the next medicine show rolls into town: a little distraction now and then is always a nice way to avoid reality and give your bosses the illusion of progress.
Now, let me make something excruciatingly clear, lest you misunderstand me and thus send incendiary emails and/or impel my IBM management to take me behind the woodshed for a good thrashing: I am a strong proponent of Service-Oriented Architectures (SOA).
However, I tremble at the realization that the fundamental technical benefits as well as the costs and trade-offs of SOA are sometimes lost in the guise of Snake Oil-oriented Architecture.
IMHO, SOA's value proposition begins with the A in its acronym: architecture. There is sound, proven value in governing and growing a system's architecture; there are also hard decisions that must be made, many decisions of which cannot be known a priori (which is why a process shaped around the rhythmic incremental and iterative release of executables is so important). There are many things we already know about what constitutes a good architecture and what does not. Stripped away of all the hype, a Service-Oriented Architecture is essentially a variant of well-proven message-passing architectural patterns. The variance comes in the form that services are cleverly designed to take advantage of the Web-centric infrastructure that pervades many organizations: services allow you to send and receive semantically rich messages through firewalls.
Having said that, there follow a multitude of hard technical and process decisions that must be made, which the Snake Oil-oriented Architecture showmen often neglect to tell you about: what distinguishes a good service from a bad one? what should the granularity of a service be? when should I offer up a stateless service versus a stateful one? as for the stateful ones, how to I express their semantics, and how do I ensure their their misuse doesn't corrupt my system? how do I express the semantics of a society of services (only the most trivial services work in isolation)? how do I decide upon the semantics of the information transmitted by these services so that locally they are efficient and useful but that also globally they are consistent? how do I expose some services to some clients and hide them from others? how do I offer up variants on a service, so that different clients see a different face to that service? how do I ensure the security of critical services, such that I am confident I'm not opening up holes in my enterprise that will let the bad guys in? what services should I expose to the world, and what services should I keep hidden? where are services appropriate, and where are they not? how do I best expose services in a legacy system? who should own/maintain these services? are there alternative architectural patterns I should employ instead of services, and where, and why?
These are all architectural and process decisions, which is why I tend to emphasize the A in SOA. If you ignore the S in SOA for a moment and shine an uncompromising light on your organization's software development practices, you may come to realize that there perhaps are some simple fundamentals you need to work on first, so that you can then approach the S in SOA in an appropriate, confident manner, and derive the true value from this technology.
If you do otherwise and accept the unprovable proclamations of the Snake Oil-oriented Architecture salesmen by pouring their elixir on the aching muscles and oozing wounds of your organization's people and software assets and doing nothing else, than all I can say is that you will probably get the results that you deserve.