Why Do We Overcomplicate Technology Messages?

Feb 6, 2007 by Sinclair Schuller

Generally, most of my posts introduce a topic, question, or label (we’ll call it x), and then I provide a y to describe and foundationally support x. Well, for this post I’m going the opposite direction. For this particular x, I find that the sheer mention of it causes people to cringe and howl. Instead, I’ll give you y first, and then x (kind of like Jeopardy, but not really, but kind of). Here goes y

Imagine a technology that lets you reuse other technologies you’ve already bought and built regardless of how these other technologies were made. This same technology will also make sure that any technology choices you make in the future can be easily integrated into your existing system.

What x am I talking about in the above y? Service Oriented Architecture, or vernacularly known as SOA. Ok, go ahead and cringe now. Why am I bringing up the continually beaten dead horse? Because to this date, I want to vomit while reading the various descriptions of SOA on the web (particularly those provided by SOA vendors). Is it really that hard to relay a simple message? I’m basically jumping in on Thomas Otter’s side, as highlighted in his recent post on SOA. It seems like there is a trend in overcomplicating messages within the technology. When you have an established technology or product, there is no reason to obscure or overcomplicate your message when marketing the said product. Apparently, SOA is a magnet for obscure definitions. Some examples:

“Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application’s business logic or individual functions are modularized and presented as services for consumer/client applications. What’s key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation.” 
-http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html

“SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.”
-http://www.xml.com/pub/a/ws/2003/09/30/soa.html (To be fair, this one attempts to set-up a simple analogy before hand)

“Service orientation is an approach to organizing distributed IT resources into an integrated solution that breaks down information silos and maximizes business agility. Service orientation modularizes IT resources, creating loosely coupled business processes that integrate information across business systems. Critical to a well-designed service-oriented architecture is producing business process solutions that are relatively free from the constraints of the underlying IT infrastructure, because this enables the greater agility that businesses are seeking.” 
-http://www.microsoft.com/biztalk/solutions/soa/overview.mspx

One thing companies may want to consider is to follow Otter’s advice: “The way to talk about SOA is not to talk about it” or don’t define SOA with the word SOA, and don’t get all architectural on us. After all, what is more understandable: Peanut butter is a healthy, tasty food that goes well with grape jelly or Peanut butter, a processed form of Arachis hypogaea that maintains a creamed consistency, is a flavorfull food that is often used in a pairing with processed grape food and provides its consumers with antioxidants, monunsaturated fats, and Resveratrol, all of which are generally associated with fortifying the human body against cardiovascular and coronary-artery diseases. Personally, I like chewing on peanut butter and jelly, and not on mouthfuls of words.