Don't Have a Cow, Man! Loosening up About SOA's Definition


IT Business Edge is running a series of interviews on SOA this month, trying to, once again, pin down SOA's definition, cut through the philosophical debating, and boil it down to something you can use.


I admit it: I'm tired of asking the question, "What is SOA and what does it mean?" I don't think we'll ever have one strict agreed-upon definition -- there will always be nuances, just as with all complex topics.


But, then again, I'm not sure the industry has to agree on the nuances before organizations can act on the basics of SOA. And I do believe there are enough widely agreed-upon basics to proceed. For starters, we know the building block of SOA will be services, and that they should be sharable and loosely coupled. Let's start there and see what happens next.


Still, you don't have to look very hard to see that there's a lot of confusion and just plain wrong-headedness about SOA, and that's one good reason to revisit the definition question.


Here's my most recent favorite example, posted by JP Morgenthal, who writes the Tech Evangelist. Morgenthal recently attended the charter meeting of a SOA Technical Committee and here's what he wrote about his experience, (I've excerpted the four I felt were particularly revealing):

"I walked away with some interesting observations that I believe are consistent, industry-wide and pertinent to anyone interested in SOA. 1. Where SOA was successfully sold to upper management and invested in, SOA was sold as a catch-all for re-factoring and integration efforts. 2. The group that successfully sold SOA in #1 does not appreciate attempts to discern architecture from technology. 3. For some individuals SOA and Web Services are inextricably linked in their mind and any attempt to separate them results in complete confusion. 4. Some individuals believe that SOA requires an Enterprise Service Bus..."

Matt Groening should open a Simpson episode with Bart scribbling on the chalkboard: "SOA is not a synonym for Web services and does not require an ESB."


So, it seems we're not done with this discussion just yet. Nonetheless, I was relieved that IT Business Edge's Arthur Cole -- and not me -- was the one asking the questions in this interview with Dwight Davis, a senior analyst with Ovum.


Cole brings a fresh perspective to the discussion, asking practical questions such as, "In what ways is the SOA changing business operations? Should we start planning for the demise of business applications like CRM and ERP?"


I thought Davis nicely sidestepped that last question -- probably because the answer is, "Yeah, well, we can only dream" - but his response to the first part is very useful for those of you still grappling with SOA and how this abstract concept would solve practical, daily problems:

"It allows you to have an IT infrastructure that is more flexible and adaptable and agile, as opposed to the more familiar rigid IT infrastructure with silos of functionality in which certain applications run on a specific stack of computing and software capability. ... you can have a world of pooled resources. ... In theory, you can arrange resources on the fly to come together to perform specific tasks and then reconfigure it all again for different tasks."

He also touches on SOA first steps to take and how SOA relates to cloud computing, SaaS, Web 2.0 and all that jazz. It's a well-done interview and very helpful for those just getting started with SOA.


That said, if you've followed the SOA-definition discussion for some time, you probably won't find anything new here. No offense, but it wasn't written for you. Still, I hate for anybody to feel left out, so I'd also like to point out this interview with Duane Nickull, chair of the OASIS SOA Reference Model Technical Committee and the senior technology evangelist for Adobe Systems.


The OASIS SOA Reference Model wasn't written to offer a strict definition of SOA, but to get everybody on the same page with the terms. It's more of a Rosetta stone, if you will, than a definition. Nickull said the reference model was never meant to give a definition of SOA:

"From the OASIS standpoint, .... we wanted to make sure that we could leave the world with work that would help them communicate better around SOA, and allow them the freedom that their definition of SOA can still be different, that we're not dictating to them what SOA is."

This frustrates some, who thought it should have defined SOA. The reference model was released two years ago, but I still see a lot of chatter and confusion about it, even among those who live and breathe SOA.

Nickull said the OASIS Reference Architecture will probably help address some of those concerns. It was released as a draft in April of this year and is currently in the call for comments phase.

This makes you wonder what is the point of a reference model. I think it's primarily more for those in the trenches, but I did ask Nickull point blank if CIOs and other high-level technology and business leaders could apply the reference model to their own SOA efforts. Nickull said there are a few key questions the reference model would help you understand about SOA:

  • If SOA is architecture, how do you express it as architecture?
  • Is it sufficiently different from other types of architecture?
  • If SOA is "X," what is not "X"? Or, what is an anti-pattern of SOA?

He also suggested IT should start any SOA implementation by answering some very basic questions:

  • What are my requirements?
  • What is the motivation to do this?
  • What is the successful end result of this?

I like these questions, because by answering them, you'll end up with something that matches your needs, even if you don't build something that meets the precise definition of SOA -- whatever that may be.