Occasionally, you'll see someone talk about business services in SOA. I confess: I haven't contemplated the difference between a service and a business service very deeply.
I just sort of assumed a business service would more closely approximate a business process. If I had thought about it more, I probably would've assumed that, for the most part, when people say "services," they're talking about business services.
A recent piece published on Symbian Developers' Journal -- a subsidiary of Sys-Con Media -- pushed me to think more on the subject. Now, if you're an enterprise architect, you may have already considered this question.
But for most people -- including IT executives, managers, business analysts and particularly developers -- I think this piece will challenge you to think more clearly about what it takes to create a business service and, by extension, help you see how SOA can be a strategic enabler, rather than just a new way of building software.
The first thing I check on any Sys-Con piece is the writer's bio, because I've found their pieces are vendor-written a bit too much for my comfort. Sometimes, the article is still useful, but often the author's recommendations tend to sway you toward a solution that looks suspiciously like the product offered by the author's employer.
I was relieved to see this piece was written by an IT architect for the Swedish Railways named Aristo Togliatti. Previously, Togliatti was an enterprise architect at SVT, the Swedish State Broadcaster -- so he's speaking from experience, and not a need to push products which, in my book, instantly gives him more street cred.
Togliatti manages to get to the heart of an ongoing problem for SOA advocates -- the definition of services. Defining "services" is a bit like defining "obscenity" -- it's hard to explain, but you know it when you see it. Unfortunately, that's not particularly helpful for those of you in the trenches, trying to work it out for yourselves.
Togliatti not only defines a service, but he deftly tackles the key question of how you can make SOA a strategic enabler, as opposed to just a collection of services. The key to understanding SOA, he writes, is understanding the difference between services and business services:
"A service is, as said before, just something doing something. A Business Service is a service that is relevant to the business we are running and therefore creates some kind of added-value for the organization."
I also like his simple, but effective, distinction between a service and a business service:
"But how do I know if a service is a Business Service? Well, if your development department created it without consulting your business then it's probably not a Business Service. In order to create a Business Service, you need to know what your business requires and this has to be done in cooperation with the business itself."
If you're wondering how something "so IT" could really impact the business, I think you'll find Togliatti's piece helpful. At one point, he admits he may be delving into a "SOA utopia," but at least it's an understandable look at the SOA "big picture" -- even if we never quite get there.