Defining Business Services Key to Building Strategic SOA

Loraine Lawson

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.

Add Comment      Leave a comment on this blog post
Nov 6, 2008 2:20 AM Mike Rollings Mike Rollings  says:
I believe that the difference between a service and a business service is embodied in the way that each evolves from a technical perspective or a business perspective. Many organizations are just creating services reminiscent of component-based development. Yet, if they want to maximize the business relevance of SOA, business services (a.k.a. business capabilities) must become a focus.More information is available on this topic in my post to our Executive Advisory Program blog ( RollingsSenior Analyst, Executive Advisory ProgramBurton Group Reply
Nov 6, 2008 6:09 AM Steven Rdzak Steven Rdzak  says:
Loraine,I am on my second go around with SOA at my current company and the 1st time around we approached the service design problem from a technical perspective and a provider centric perspective. What we ended up with was wide variations in service granularity, data schemas and interaction patterns that made it nearly impossible to successfuly orchestrate those services in a business meaningful way. For round #2 we came at it from a business process design philosophy and consumer centric perspective. What we now have are services that are aligined with key business functions, that operate on business messages based on a shared data schema of business entities with uniform interaction patterns across the service inventory.We now are beginning to meaningfully orchestrate these services using BPM technology and we have succeeded in delivering value with our SOA infrastructure.We still don't have business owners for these services, but our business is owning their BPM processes and we can show them how their processes send business messages, in a language they understand, across business process boundaries via the business services.Keys to getting to business services were the following:1. When developing solutions talk business flow between business functions, and avoid application A talks to appplication B etc.. (this is a very hard shift for most business and IT people)2. Start with the data! A common shared understanding of the business data entities and their attribution is key, independent of the application models I must add too!3. Standardize patterns of business messaging - think how you can make it easy for the consumer to use the service because the consumer at this level is a business user/process.4. Govern, Govern, Govern - project teams will fall back to old provider/application centric habits if oversight is not in place to keep pushing a business centric viewpoint.Also, you are not going to have hundreds of business services (how many discrete business functions does your business have?). We have ~ 15 with a few more slated. Now of course there are many operations for a given function the service provides, but the key to adding value for the organization is to simplify and think strategic!! Reply
Dec 6, 2008 1:10 AM Nick Malik Nick Malik  says:
Hello Lorraine,I am not fond of using the word "Business Service" to refer to a SOA service that happens to be closely tied to the business process (as opposed to a SOA service that is tied to a supporting operation like Entity data retrieval). Both kinds of SOA services are, in the grand scheme of things, simply expressions of software. Business has been using the concept of a 'business service' for many decades, primarily to mean 'the services that my organization offers your business.' So a consulting business may list 'consulting' as its business service.I have no problem with creating a subtype of SOA Service that is designed to meet the needs of a business process, and calling that subtype out as being valuable. It is quite valuable. The core concept of SOA is that value comes from these kinds of SOA services. But it is confusing to our customers, who are after all, business people (many of whom read business books, and business magazines, and may have attended business school). Our customers have a concept that they have associated with the word 'business service.'And that concept is not connected to computing.Let's be cognizant of one of the major problems that technologists face when working in a business: the inability to speak the language of the business. To combat this problem, we MUST know what terms our customers use, and we MUST use their terms in the way that they do... which includes avoiding the temptation to use the same word or phrase in a totally new way.Because, sooner or later, an architect will open his or her big mouth, in the company of a business person, and utter the word 'business service' in front of a business customer. At best, he or she will generate confusion. At worst, derision and dismissiveness. I'm OK with the term 'SOA business service' or 'SOA process service' or even 'business-oriented service.' It sounds like a nit-picky thing to say, but honestly, it matters.--- Nick Malik, Enterprise Architect, SOA Architect, Microsoft IT Reply

Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.