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