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

Loraine Lawson

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.

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
Sep 10, 2008 6:57 PM Rob Eamon Rob Eamon  says:
Interesting thoughts.The items from Morgenthal seem to point out that we may not yet have agreement on the basics of SOA, let alone the nuances.I like that you used "shareable" instead of "reusable." Awesome! Reply
Sep 11, 2008 12:03 PM JR Rajan JR Rajan  says:
By the way, I still didn't get what SOA means!!!!!!!I was curious, because I used to run a training program called SOA - 'School of Administration'.Regards Reply
Sep 11, 2008 3:19 PM Loraine Lawson Loraine Lawson  says:
JR Rajan-There's also the School of the Americas. I use a SOA google alert, and I get all the protest news.SOA - service-oriented architecture. Email me at the link above and I can send some other information, if you wanted more. Reply
Sep 11, 2008 4:23 PM Francis Carden Francis Carden  says:
These should be interesting interviews.I have an interesting, not often talked about aspect of SOA.Where does the business logic (code) go to join services? How much business logic is required ? When presented to the user, more code is likely required (to integrate the services to the UI).And doesn't all this code become the legacy integration problem of the future and really mean that SOA is a bunch in glorified subroutines that may or may not be re-usable.I see more copy and modify of services than re-use to reduce the amount of code needed but that in itself defeats the objective..What is needed in my view, is rapid service enablement of existing applications and processes. These can be rolled out immediately and allow business and IT to step back and watch for a bit and then focus on build REAL services over time.... OpenSpan (for which I work), enables EXISTING applications that users use today, to be moved to the server and exposed as services. It just WORKS and works RIGHT NOW. Agile, iterative and puts you on the path to the new Architecture. Reply
Sep 11, 2008 4:48 PM Duane Nickull Duane Nickull  says:
Hi Lorraine:I just want to further clarify a few points. First - the OASIS SOA Reference Model work has been an OASIS standards since 2006 and is actually widely used as a base reference model for SOA. Within the RM work, the main concepts of SOA and the relationships amongst those entities are described in detail although it is a model, not architecture per se. It is an artifact that allows the comparison of a wide range of Service Oriented Architectures by noting the consistent components of each.The OASIS work describes SOA as " an architectural paradigm for matching needs and capabilities amongst disparate domains of ownership" and focuses on a view of architecture starting with "services" as the action boundary between the consumers and providers of those capabilities.The great strength of this RM work is that it allows those with differing views of SOA to reconcile their differences by using the RM work as a point of reference (hence "reference model").Within the OASIS group, there is ongoing work on a reference architecture (different and more concrete than a reference MODEL) which is what was released as a RFC in April this year. Anyone interested can check out both of these works at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm 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.