Recently, a colleague asked me about service-oriented architecture for an IT Business Edge special report, "SOA: What Is it?" I don't claim to be an expert, but I've been writing about SOA for nearly a year now, and she wondered if I had any sources who she could interview on the topic, "What's a service?"
I was a bit surprised. I felt the question itself was a bit dated. Surely, I thought, by now, everybody knows what a service is. Oh, sure they might wonder how granular it should be or how services should be classified, but basically, everybody understands the concept.
Last week, after the posting of ZapThink's "Why Service Consumers and Service Providers Should Never Directly Communicate," someone asked the Yahoo Service-Oriented Architecture Group to explain the difference between a service and an application. It started a hailstorm of posts from the members, including some of the most respected names in SOA.
In fact, as of this posting, people were still debating the definition of "services."
I thought Burton Group consultant Anne Thomas Manes best summed up the most commonly used definition of services and how they differ from an application:
My definition of 'service' is something that implements an autonomous capability. The term 'application' is somewhat orthogonal because applications are typically designed to support a single business unit's needs, while services are (or should be) independent of any particular business unit or application. I typically say that 'applications' consume 'services,' but capabilities implemented within an application can also be exposed as services.
Yahoo Group member Michael Poulin put it a bit more concisely:
I have found only one significant difference: Applications tend to be provider-centric and technology-oriented; services tend to be consumer-centric and business-oriented.
If you're into the nitty gritty of SOA -- I mean, you really want to follow the cutting-edge, nigh-philosophical discussions, about SOA, then Yahoo's SOA Group is the place for you.
But if you're more interested in the bottom line and getting back to business, then check out my colleague's interview with Todd Biske. Biske, an enterprise architect who writes the blog "Outside the Box," does a nice job of explaining the issues the experts are grappling with right now, while providing you with a working definition for services.
I particularly like how he addresses the difference between a service and an object in object-oriented programming, which I think can be confusing for those from programming backgrounds who are just dipping their toes in SOA:
OO is very much about the underlying implementation -- how we write code. SOA is more about how we break down the highly integrated business problem into manageable, independent units, and not about how we then implement those units. I view SOA as an approach to viewing enterprises as collections of services. ... I'd argue that we were practicing application-oriented architecture. Our primary unit of describing technology was the application. We need to change that to services.
Definitions matter, and I'm not trying to belittle the importance of defining services. But I think it's more important to consultants and other experts. And, at some point, Internet discussions tend to become bogged down in defining terms to the ninth degree, instead of focusing on the bigger picture of how it's being applied and used in the real world.
So, I was more interested in what Manes was prompted to say on her blog as a result of this discussion:
... I think I've become a bit jaded from the interviews I've conducted thus far. It has become clear to me that SOA is not working in most organizations.
I know of at least one recent vendor survey showing most companies viewed their SOAs as successful. But, frankly, I give more credence to Manes' report. She's a 28-year industry veteran, Burton Group VP and research director, former CTO and author of "Web Services: A Manager's Guide." She knows her stuff.
She assures us these companies are following best practices, using the best technologies, use governance processes and, in short, are doing everything right to ensure SOA's success. Despite the fact these companies have "implemented stunningly beautiful SOA infrastructures," writes Manes, "these SOA initiatives invariably stall out."
Kinda makes the brouhaha over defining a service a tad pedantic, don't you think?