I’m always a bit dismayed when I hear the following terms mixed up, or combined: SOA service and business service.  In my mind, these things are different.  In one sense, they are related, but indirectly.

A business service is a function (or capability) of the business that is offered to one or more customers.  Those customers are often  internal, because this scenario is often applied to corporate supporting functions. For example, the accounting business unit may provide “accounts payable” services to every business division of an enterprise.  Those divisions are internal customers.  The business unit is accounting, and the business service is “accounts payable.”

In some cases, the customers of the function may be both internal and external.  Many years ago, the Carlson company took their marketing division and not only made it into a shared function, that their various internal divisions could use,  but that division was able to offer their services to the general market as well.  They provide a list of shared business services used by both internal and external customers.

The people who use shared business functions are “businesspeople” of all stripes.  They have work to do, and a business service is simply a way to do it.   A shared business service includes responsibilities, and therefore people who are responsible.  It is a kind of “sub-business” that has customers, and processes, and capabilities, and information.  In many companies, IT is run as a shared business service, providing technology services to many areas of the business. 

A SOA service is a different animal altogether.  Service Oriented Architecture (SOA) is an architectural style.  That means it is a set of software design patterns.  These patterns are united in their support of a basic set of principles.  The people who use SOA are people who write software.  (If you compose an application, even if it is simple to do, you are writing software.)

The logical data model that encapsulates this concept is below.  This is a very tiny part of the data model derived from our traceability model, which allows us to recognize the interdependencies between business processes, applications, and business units.  At the top of the image you see business services.  SOA services are on the lower right.  (click the image to enlarge)

A business unit may provide zero or more business services.  Not all of the capabilities required by a business unit may be involved in a business service. 

SOA provides the ability to share features.  Those features may provide information, or calculations, or data manipulation.  They may also include the limited automation of some elements of a business process.  SOA services are provided by “installed software” (we use the term “application” many times for this entity… a different blog post someday…).

Business-vs-SOA-Service

(note: I updated the image about 12 hours after posting this blog, due to an error in the original image -ANM)

The point of this post is to provide sufficient context to challenge the notion that SOA provides shared business services.  It does not.  SOA provides shared features that many business units call upon.  Those features are required by the business processes within those business units. 

Note to responders: before you flame me, take the time to try to map your concepts to the diagram above.  You may find that if you look for your concepts, and not your words, that you are simply using different words than I am to refer to the same concepts.  Disagree with me about concepts and I’m interested.  Disagree with me because I don’t use a word in the same way that you do, and we will probably not have a very interesting discussion.