Creating a distinction between business services and SOA services
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...).
(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.
Comments
Anonymous
November 30, 2008
PingBack from http://blog.a-foton.ru/index.php/2008/12/01/creating-a-distinction-between-business-services-and-soa-business-services/Anonymous
November 30, 2008
The comment has been removedAnonymous
November 30, 2008
Hello Kotesh, I wonder, if you were to create a conceptual model of what you just said, and then attempt to list the "things" that are services and the "things" that are business services, what would that model look like? Tell you what... do that. Create a model and share it. Then, it would be far easier for me to see how, or whether, our viewpoints differ. It is not at all clear how you would view a 'composite application' in your definition. Is it not a composition of services? What do you call those services, and who uses them? Are there two types of services, and if so, how do you differentiate them? --- NAnonymous
December 01, 2008
I am sorry but I don't agree. To me a service (business or otherwise) is simply a contractually defined piece of work. You communicate with a service provider by a message dialogue. You don't know if the service is software or not and the service doesn't know if you are software or not. In an IT context "services" can be anything from business services e.g. accounts payable, down to low level IT services e.g. send email. A service can be a complete process (a composite application).Anonymous
December 02, 2008
Hi Peter, You use the phrase "anything from business services ... down to low level IT services" so in your language you made a distinction between a business service and a "low level IT service." If they are the same thing, you would not need to have made the distinction. Clearly there is one, even for you. Could you tell me the definition of a business service, then? And the definition of an IT service? Why did you make a distinction if you believe that there is none? --- NAnonymous
December 03, 2008
I'm having trouble mapping my concepts to yours, so let me just ask some questions. If I have a SOA Service responsible for customer data, and it publishes a message when customer data changes, is it a service provider or a consumer since it is "calling" subscribers? Is there a "master" for data as well? Is a SOA Service runnable, or does it map to lower level executable elements? Is an SOA Service fully within the boundary of a Business Service, or can multiple Business Services use/own a SOA Service? Hoping to gain some clarity. ThanksAnonymous
December 03, 2008
Hi Udi, I'll copy your questions into my response to make it easier to follow. >>If I have a SOA Service responsible for customer data, and it publishes a message when customer data changes, is it a service provider or a consumer since it is "calling" subscribers?<< Interesting question. I have an answer, but it may not match yours, and that's OK. From the viewpoint of how this information is used, it is important to understand that the connections between applications across a service interface create an "indirect" dependency. As long as the dependency is tracked consistently, it may matter only that we have "one" definition for an environment, not necessarily that we have the same one across environments. That caveat aside, I look at it this way: In a Call-response scenario, the "CRM Portal" requests information from the "Customer service" and the service responds. The meanings should be clear that the consumer is the "CRM Portal" asking for information and the Provider is the "Customer service". In a real sense, the EDA scenario is different primarily in the expectations of the communication protocol, but not in the flow. The "CRM Portal" subscribes to events because it is asking for information. It may make the request only once and there may be hundreds, or thousands, of responses, but the response is still an attempt to fulfill the request. Therefore, the "Customer service" is still a provider. You can reasonably make the case that these two systems do not know about one another, especially in a well designed EDA environment. That is fine. They both know about the environment. So you could represent the relationship as: CRM Portal consumes message from Bus provider. Bus consumes message from Customer service provider. Make sense? >>Is there a master for "data" as well?" yes. There is a master for business entities, and another for business events, and another for business documents. They tend to come in a bundle. Adding in these elements and relationships into the view I extracted for the blog makes the diagram much more complex, and I didn't want to go into detail in this blog about what the various relationships mean... so I left them out. These concepts are very much present in the underlying model. >>Is a SOA Service runnable, or does it map to lower level executable elements?<< The SOA service is logical. It is provided by many instances of "installed software." So a single service can be provided by many applications, or many instances of the same application, etc. There are mappings off of "SOA Service" for other elements that are not illustrated in this view, as mentioned above. If I install a unit of software that does nothing but provide a Customer service, it is one element in the "installed software" entity, providing the "Customer" service. >>Is an SOA Service fully within the boundary of a Business Service, or can multiple Business Services use/own a SOA Service?<< Multiple business services, by way of their business processes, may all need a feature provided by one SOA Service. Likewise, any Business Service may need the features of many SOA Services, or may need many features, each of which may call upon SOA Services. So, to answer your question, multiple business services can use a SOA service. That would be normal. Hope this helps, --- NickAnonymous
December 03, 2008
I wasn't making a distinction between business services and low-level IT services as services but they are usually implemented differently. Of course, implementation makes no difference to the service consumer. In my mind the difference between business and IT services is like the distinction between data and metadata - it is just a point of view.Anonymous
December 03, 2008
Hi Peter, I think the problem with the notion of a service as "just contractual" is that it doesn't actually happen in the real world that way. A business service, like accounts payable, has people on both sides. Some people need the service. Others provide it. This is important because business services have a person, somewhere, that is responsible for the results. That person is accountable. If you have people on one side and a machine on the other, there is no one to hold accountable. That is not a business service. Clearly, we can generalize many times, each time, becoming more and more vague. At some level, there are just "things" and "relationships between things" and "lifespans" for each. But if you want to create a database of invoices, it doesn't do a lot of good to have a "things" table. You need to be more distinct in order to be clear. And if you want to own and manage an IT infrastructure, or build an enterprise service oriented architecture, you need to be more distinct than the definition of a service that you are promoting. So let me finish by asking: if the definition of a service is a "contractually defined piece of work," then what problem can you solve by defining a service in that way?Anonymous
December 04, 2008
Hi I am not an expert on SOA. However I would to like venture to express some of my thoughts about a distinction between SOA Service and Business Service from conceptual perspective. These thoughts I believe are aligned to the initial diagram in this blog. Please feel free to correct me if I am wrong. To me a business service is something that has defined business function, for example providing a stock price for a given symbol. This service will make use of SOA Services to make its functions available to users on premises and in the cloud. SOA service is part of set of services that provide infrastructure for business services (for example Windows Azure services, a cloud services OS that provides infrastructure in the form of various services to publish a service in the cloud). So a stock service may have some functions that are available to users on premises and some functions for users in the cloud. Set of SOA services will provide needed infrastructure to enable this requirement. Stock service i.e. business service, will provide a service model in the form of configuration about its endpoints, the bindings that it intends to use for each endpoint and also contract that will enable discovery of its functions over net. Both, a stock price provider and a service that provides an infrastructure to stock price provider are services using SOA (architecture). The difference is one making use of other to provide a defined business function in the cloud. So the distinction between business service and SOA service can be summarized as - business service uses set of SOA services to make its functions available as a service over net or in the cloud. Thanks MaheshAnonymous
December 05, 2008
Hi Mahesh, While your description is eloquent, it is not aligned with the intent of my original article. One thing that the geeks like us tend to do, and it is a bad thing, is to create a term that "we" have never heard of, and define that term... but that term may have been used by someone else already. Business service is a concept that exists in business. It has been around for decades. It means to create a business function that is used by other business functions, like accounting or human resources for a large enterprise. We don't get to redefine this word. We are used to using a linguistic convention of defining a word (service, in this case) and then putting an adjective in front of it to differentiate different types of that thing. In this case, we overlapped prior art, and defined a word that was already in use. All of your uses of "business service" fall into the definition of what I have termed a SOA service. --- NickAnonymous
December 07, 2008
In my organisation the idea that there are services with contracts between them (wheteh performed by people or software) IS new. We are coming from a very siloed structure where everybody and every system does everything (including in software development). We have been very loathe, culturally, to have experts. Similarly, because a service can be seen as being "the expert" we don't have many (this is slowly changing). So if a service is a "contractually defined piece of work" the problem solved is "splitting the work up into services that can be shared"Anonymous
December 08, 2008
The comment has been removedAnonymous
December 08, 2008
The comment has been removedAnonymous
December 08, 2008
Your points are valid in that part of the business that runs the business (accounting, HR etc) but in our case, producing statistics, we are more like a factory where the "business" services I am talking about are like the machines on the factory floor (they convert the raw material "data" into a finished product "information". Currently these "machines" are not service oriented which makes them hard to "wire together" and "automate". Maybe I need to come up with another name to describe them? (but statistical services already has another meaning!) PS You don't get fired for making mistakes in a government department <g> PPS As long as the mistakes are consistent then statisticians don't care as it is the trend not the number that counts <g>Anonymous
December 08, 2008
Hi Peter, Interesting. I'm not directly familiar with your work, but it sounds like you are providing information statistically derived from raw data. The question is: who is providing the data? Is a system, or a team of people that run a system? If it is a system, then you may or may not be able to provide a SOA service. If it is a team of people responsible for delivering information, and that information's quality is insured by a legal agreement, then you have delivered a business service. I understand the confusion. ITIL uses the term 'service' to refer to a 'business service' in my nomenclature. Many others do as well. The problem with using the single word 'service' is syntactical. In the English language, if you add a modifier to a noun (e.g. say "SOA service"), then you are identifying either a subset or facet of the noun itself. You are not defining a new thing. Therefore, it would be incorrect, in English, to say that a 'service' is a different thing from a 'Web Service,' yet clearly the intent of ITIL is that a service is a radically different thing from what SOA folks would describe as a web service. I avoid that confusion by simply not using the general term 'service' at all, but only use the term with a modifer like 'business service' or 'SOA service'. If your team provides a business service, the name can often be derived from the 'value' that is provided, not the algorithm used to provide it. Therefore, perhaps it is less interesting to say that they are statistical services, and more interesting to describe the value provided by the analysis? (I don't know what that value is, so I cannot suggest much. Perhaps a 'Process Measurement Service' or a 'Customer Behavior Intelligence Service?') I hope that my guesses made my point understandable. --- NickAnonymous
December 08, 2008
The comment has been removedAnonymous
December 09, 2008
This has been a very interesting discussion so far. I hope you don't mind if I continue it? OK I think I need to give you a bit more detail about what we do. The Australian Bureau of Statistics collects information from and about people and businesses and produces information products e.g. tables, data cubes, maps etc The incoming data goes through a series of processing steps (like a car factory) such as editing, aggregation, seasonal adjustment, publishing. Each of these steps is performed by a team of people using IT systems. (we used to be grouped around the survey but we are moving to being grouped around the processing step). It is these processing steps that I am getting people to think of as "services". In fact we are starting to embed these "services" as activities in business process maps (with the end goal of automating the process). These services are not for "running the business" or "interacting with the business" but do flow out of doing BPM, SOA and EDA as business architecture practices. So what would you call them?Anonymous
December 10, 2008
I'm beginning to see where we disagree. As I've described in a previous blog post (http://www.udidahan.com/2008/04/23/visual-cobol-enterprise-processes-and-soa/), I see business processes as being entirely encapsulated in a business service. Larger processes that cannot be entirely encapsulated in a business service occur as a series of events that the various business service raise. Jim Webber calls these larger process "enterprise processes" which I think is a fine name for them, distinguishing them from business processes. As such, business services do not need to be shared. I've found that as fewer things are shared, autonomy is increased, both at design time and at run time. I'm having difficulty getting a clear picture of how all the pieces you described work together, but it is absolutely clear to me that without understanding that one wouldn't be able to design a solution to a real world problem. I look forward to seeing on your blog more fully developed solution described according to the principles you outlined. I guess that we can agree to disagree until then :) Respectfully yours, UdiAnonymous
December 10, 2008
The comment has been removedAnonymous
December 10, 2008
The comment has been removedAnonymous
December 11, 2008
Nick, In my post on SOA, EDA, and CEP (http://www.udidahan.com/2008/11/01/soa-eda-and-cep-a-winning-combo/) I outline the various events that business services raise and subscribe to, and how those cascading events bring about enterprise processes in the field of retail. Does that make things clearer?Anonymous
December 11, 2008
Ok so by your definition a business service is part of the external face of the ABS e.g. completing a survey, accessing a population table. Fair enough. As I mentioned within the ABS we have work groups assigned to different parts of the overall process. These work groups use systems, processes, people to perform a function e.g. data editing, data analysis. They perform that function on large groups of related surveys e.g. surveys of business activity in different sectors. I think you want to call that function a "capability" and I have been calling it a "business service" (for want of a better term)? In the ABS we tend to use the word "capability" for more generic functions e.g. data storage, search, collaboration, and personal skillsets e.g. leadership. (Actually some people resist using the word capability except when it is being applied to people). I think we are getting close to agreement on the terms. It is helping me. I hope it is helping you.Anonymous
December 12, 2008
The comment has been removedAnonymous
December 12, 2008
Hi Peter, This discussion helps me a great deal and I appreciate it. No one really knows a concept until they have to explain it. By having this discussion, I am more able to focus on key points with other folks, something that came up this week when discussing Complex Event Processing with an architect here. I appreciate that you are finding different definitions of capability than I am using. I'm looking to publish my model in the not-too-distant future. --- NickAnonymous
December 13, 2008
Nick, Re: "you refer to the logic of connecting B with C as a business process" I've re-read the post I referenced to see where I say that the logic a business service performs internally is automated, and haven't found it. "You refer to that business oriented SOA service as a 'business service'" Actually, my business services aren't at all like your SOA services. They are business architecture constructs and have little to no connection to software. Sales is part of the business. So is inventory management, customer care, etc. Business services "merely" represent that highest level of business. Inside these business services, people often do the work. Sometimes, their work is automated, but even then its still inside the business service. - And on the whole laughter thing, well, I've heard it's good for the soul.Anonymous
December 17, 2008
Hi Udi, It is clear to me that we are using fundamentally different metaphors for understanding business. I base mine on EA concepts exposed in Zachman, TOGAF, ITIL, RM-ODP, and IEEE-1471. No where in that auspicious body of work do you find the notion that a business service places an event onto a bus. Only a SOA service can do that. The fact that you refer to your services having that behavior means, in my mind, that you have created SOA services that are aligned to business concepts. To call them a 'business architecture' construct does not align with my use of the term 'business architecture.' Given the fact that I am an enterprise architect, that term has some pretty specific connotations to me. I cannot imagine using it in the way that you do. I see no problem with understanding the business in terms of structural groupings. You can call them any term you'd like. How's "fudge groups" sound? Personally, I don't care what the word is. The important thing is to look at your definition of "what composes a fudge group?" Once we do that, I will have no problem placing your concept on the map illustrated in the post. So far, you have included things like people, processes, tools, and information, which makes me think that you are either describing a specific set of business capabilities or a product offering that encapsulates those capabilities for the consumption of other departments. That makes sense, and it maps to the term 'business service' in my model. But then you follow on with behavior that cannot be attributed to a business service, like sending a SOA message or participating in event exchange mechanisms. Your view is not wrong, in any real sense. because I cannot say that any view is right or wrong. I try to see all of the views, and I look for the underlying concepts below them. So do not take this as a criticism of your view. However, the use of terminology that you are presenting is not aligned with the same words used elsewhere. Your logic becomes opaque, as I'm sure my logic may appear to you. We may simply have to agree to disagree on this point. --- NAnonymous
February 02, 2009
Well, it is February 2nd, and today, the Open Group is announcing the general availability of TOGAF version