Simpler SOA Definition for the Skeptics

Loraine Lawson

Joe McKendrick's generated a bit of talk-back after his post, "Ten Ways to Tell It's Not SOA." David Linthicum even added on to the list with a post of his own.


Predictably, not everyone agrees with McKendrick's list, but that's OK. As Elwood. P. Dowd said in my favorite movie, "Harvey":

"An element of conflict in any discussion is a very good thing. Shows everybody's taking part, and nobody left out. I like that."

One particularly harsh critic posted that he disagreed with half the list, and then returned later to outline why at length.


Others offered light-hearted feedback that revealed a general skepticism about SOA. One poster wrote:

"If it it doesn't work, it's SOA. If its a 3-hour lecture with no information content, it's SOA. If it's recommended by non-tech people, then it's SOA. If it's as useful as art criticism, it's SOA."

There was more, but you get the gist.


I thought McKendrick's list was fun, and, like him, I've heard all of those points expressed time and time again from various SOA experts.


Although I have to say I thought Linthicum's addition

"If this is a change in 'paradigm' and not a change in 'architecture' ... it's not SOA"

was a bit unfair, only because I think you can't have the paradigm shift without the corresponding architecture change -- and if you just change the architecture without the paradigm, I've got to wonder how well you really understand the architecture.


After a recent interview with SOA consultant Ron Schmelzer of ZapThink, I think a paradigm shift is exactly what's needed when it comes to SOA. In fact, I think that's probably why this SOA definition thing is harder than it needs to be -- it requires quite a shift in how you think about IT and how IT works with business.


During our chat, Schmelzer shared what has quickly become my favorite definition of service-oriented architecture. He suggested we start to think about SOA as a spectrum, rather than "as a set of discrete activities that if you don't do it, you're not doing SOA, and if you do, then you're doing SOA."


And then he added this incredibly simple definition:

"It turns out that service-oriented architecture is a collection of things that we do that increasingly service-orient our enterprise. ... The general approach for figuring out which services to build and the approach for managing those things in an environment that has change is called service-oriented architecture. That is what SOA is."

I suppose you could reword this to fit McKendrick's post by simply saying: "If it's not enabling services and it's not an architecture, it's not SOA."


Like I said, McKendrick's list covers a lot of the "rules" you'll hear about SOA. But I wonder if this complexity is what's fueling skepticism about SOA. Schmelzer's simpler definition shows it doesn't have to be so convoluted.


In addition to Schmelzer's definition, articles such as "Introducing SOA Design Patterns," by Thomas Erl, have helped me move beyond skepticism about SOA.


Analysts frequently talk about how "SOA is not about technology" or how "SOA's really about the business and business processes." That's all well and good -- but it's also pretty soft and it may be part of SOA's PR problem within IT circles. Bottom line: Somebody has to design and build your SOA. Erl's article describes exactly the sort of real-world implementation details that have been largely missing from SOA discussions.


He's not giving you specifics about how to build your SOA, of course -- your implementation will depend on your business needs. But SOA design patterns can help you identify pattern solutions to common problems, and even help you save time and money.


"Introducing SOA Design Patterns" was recently made available for free download on SOA Patterns - the Web site for Erl's upcoming book of the same name -- but was originally published in June's SOA World Magazine


Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.


Add Comment      Leave a comment on this blog post
Jul 10, 2008 4:18 PM reamon reamon  says:
"particularly harsh critic posted that he disagreed with half the list"Hey, it wasn't half the list. It was 80%! ;-)Hopefully the comments were useful, even if deemed harsh. Reply
Jul 11, 2008 5:24 PM reamon reamon  says:
A simpler definition would be useful for all, not just the skeptics!The vast amount of material available seems to focus on the wrong areas. Lots of articles titled "SOA and XYZ" with SOA seemingly encompassing everything under the sun. Lots of information about why X isn't SOA. Lots of vendor bashing (Linthicum seems to lead that particular parade, which is highly ironic).Lots of debate about ESBs, WS, REST, registries, governance (lots about governance!), SOA benefits, sharing/reuse, etc. Some of that is useful, particularly for implementation and defining processes.But there is precious little on the two primary aspects of being SO--service design and separately standing interfaces. Indeed, most case studies mention the services almost in passing--"which connected to the services that were developed."In my opinion, a lot of the debate, confusion and difference pertain to topics that are related to SOA, but actually have little to do with the core of SOA--the defining and developing of services and their interfaces. What makes a good service? How many different interfaces to a service are reasonable? What is the appropriate level of abstraction for service operations? What are the challenges mapping interfaces to service implementation?If its not enabling services and its not an architecture, its not SOA.Spot on! Reply
Jul 11, 2008 7:46 PM reamon reamon  says:
One last point: Of the 15 points (Joe's + Dave's), just 3 of them mention services. The focus seems to be on surrounding activity, rather than on service definition, development and management.You touch on this with the "pretty soft" comment on what analysts typically say SOA is about.It reminds me of an old, old Byte magazine Abort, Retry, Fail article (http://home.tiac.net/~cri/1998/elehunt.html) on matching up people with jobs based on how they hunt elephants. A good number of articles about SOA, including the list of "it's not SOA if...," seem quite similar to this line in the article:"Quality assurance inspectors ignore the elephants and look for mistakes the other hunters made when they were packing the jeep."While packing the jeep is important (governance, rational technology usage, etc.) we need to be more mindful of the elephants. :-)Schmelzer's description is excellent. Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.




Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.

Subscribe Daily Edge Newsletters

Sign up now and get the best business technology insights direct to your inbox.