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.
PingBack from http://blog.a-foton.ru/index.php/2008/12/01/creating-a-distinction-between-business-services-and-soa-business-services/
My understanding of Service in an SOA is Business Service to which the IT is being oriented with the help of architectural style that is hence called Service Oriented Architecture. SOA improves deviates from the component based architecture in a way that the abstraction level is increased to meet the Business functions capabilities. In traditional component architectures the focus is only IT in delivering the static requirements given and business orientation might not be on the top priority. So in way when we say Service in SOA we are mainly focusing on the Business services replica in IT space along with other Technical services required to deliver the business. In this article some how depicting the linkage is not clear even though the article said the linkage is indirect.
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?
— N
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).
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?
— N
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.
Thanks
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,
— Nick
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.
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?
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
Mahesh
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.
— Nick
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"
Hello Peter,
You answered my question brilliantly, and I appreciate it. The problem you are solving is organizational, not technical.
I posit, however, that you have taken two problems and generalized into a single word. The concept of using agreements to govern behavior, and create “experts” in a capability, is the concept of a service. I agree that this generalization is accurate.
I suggest that it is not useful, and that further breaking down the concept into business services and SOA services is essential for implementation.
This is because the nature of human beings. If you have a person that represents a group of people that represent a service, that person (manager) can sign the agreement. That person can represent the concept of “expertise” and the business can hold that person accountable.
The essence of a business service is that you hold people accountable for them. A SOA service can be easily explained away in mathematical terms, because you cannot hold a person DIRECTLY accountable. The software has a bug, and you can tell a person to FIX it, but that person is not fired for the fact that the bug exists.
If a team of people were to make the same mistake, over and over, from the time it was discovered until weeks or months had passed, the entire team would be fired.
It is wildly complex for business services to rely on business services more than one or two layers deep, so the organization won’t do it. Large organizations self-limit the depth of shared capabilities by moving more and more of the business responsibility up to the business.
SOA services are not self-limited. A horizontal service (like security) can be used by a series of organizational services surrounding entities, activities, and shared processes before you start building services that are specific to a LOB process.
The shallowest part of the stack is the LOB process itself. One layer of SOA services, in nearly every case, is used to derive the LOB SOA service from shared components. This is fundamentally different and diametrically opposite from the nature of the business service, where far greater depth exists in the LOB side and far less exists in the shared side.
This is a reflection of the nature of human accountability.
So while it is interesting to create an abstraction that encapsulates commonalities of these two types of services, I maintain that it is both (a) not useful, and (b) counterproductive.
It is not useful because these two kinds of services don’t solve the same problem. It is counterproductive because the business is led to believe that IT believes that they do, and that either generates mistakes, creates confusion, or generates laughable derision in the relationship.
When SOA works against the relationship between business and IT, it fails to deliver value in the long run.
Re:
> Multiple business services, by way of their business processes, may all need a feature provided by one SOA Service.
Is a business process fully encapsulated in a single business service?
Can you give an example of a business-feature provided by one SOA service that would be needed by multiple business services?
The reason I point to a business-feature rather than other technocentric features like encryption is that those can be provided by components, without needing SOA.
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>
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.
— Nick
Hi Udi,
You has a tough question to answer in a blog: "Is a business process fully encapsulated within a single business service?"
A business service is the externally-visible face of a business. "External" is relative, in that a shared business unit may offer its business services to other business units within the enterprise. For a finance group, it’s externally visible service is the capability of managing accounts payable on behalf of any of those business units. It is not external to the company, but it is external to the accounting group.
Some business processes are never incorporated into an external business service. For example, in the human resources group of an enterprise, it is quite likely that an incoming resume will be checked against the existing database of applicants to see if that person has submitted a resume before, and to take a look at the jobs they have applied for. (You can learn a lot about a person that applies for both the Chief Information Officer and a Junior Developer position).
Other business processes make use of a shared business service. For example, in the marketing division, if a campaign makes use of a printing company for creating a set of trade-show signs, that campaign may use the accounts payable service of the finance team to pay the bill.
The real distinction, as I’ve pointed out to Peter, is that a business service is run by a person or team that you can hold accountable for the performance of that service. There are people on both ends of the contract.
Features are another thing altogether.
Now we are talking about features of software. The features can be described logically, and provided by one or more SOA services (if they are available in that format). Note that there is no requirement that the feature be provided by a SOA service. The feature could be provided by some other infrastructure, or simply an application, without the use of a SOA service at all.
Because a feature is a logical thing, it is often the case that features are described at a high level, and that high level features are composed of lower level features, sometimes for two or three levels, before you get to the point of composing those features from SOA services.
A horizontal feature may be "shared authentication" as a way of recognizing that an application participates in single-sign-on.
An business-oriented feature may be "sales agreement approval workflow" which may decompose into a feature set that may include: "worklist for in-process sales documents by role", "ability to set sales agreement policies by program", and "submit request to offer non-normative sales terms."
The business-oriented feature of "sales agreement approval workflow" is one that, at least for Microsoft, is needed by more than one line of business. For example, we may sign a sales agreement with a Walmart to sell a large number of XBox games. We could agree to sell millions of copies of Vista through Dell Computer. We could agree to sell a thousand copies of Windows Server to an enterprise like General Electric.
Salesmen working for Microsoft in these three cases are working for different lines of business.
In each of these lines of business, there are wildly different business rules. I cannot go into details, but suffice it to say that account managers for these different lines of business would not be able to quickly switch jobs with one another.
(Note that an account manager working on different accounts within a single line of business would normally use the same rules. For example, Dell and Lenovo are treated equally, since both are Original Equipment Manufacturers).
In this case, we could choose to create a business unit that provides "sales agreement management" to the enterprise, but we do not. The lines of business each have their own groups that manage sales agreements. No need for a shared business service.
On the other hand, all three could, potentially, make use of features like "sales agreement approval workflow." Those features could be enabled by many SOA services.
Sorry for such a long response, but you asked a tough question. I hope this was clear.
— Nick
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?
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,
Udi
Hi Udi,
It sounds like we are both using the same phrase to mean completely different concepts. I appreciate your patience.
I’m not going to disagree with your concept, although it is unclear to me how it is used. Just as you are doing, I’m curious to learn how you are using the concept to solve real-world business architecture problems.
What I can glean by working backward: your concept of a Business Service is something that completely encapsulates a business process. Therefore, it is at a high enough level to represent the complete interaction that a particular business unit will have when involved with an “enterprise process” (your word).
So, in your model, an enterprise process is composed of ‘interactions’ with various business services, each of which encapsulates one or more business processes. Did I get that right?
<<edited by Nick on 12/12/08 — No, I did not get this right. See later comment >>
Hi Peter,
I had this nice long response and I was just about to post it when I deleted the entire thing by accident. Can I blame the computer for it?
First off, let’s map terms. Your business unit is the Australian Bureau of Statistics. That unit requires a set of capabilities to operate.
We look in the master list of capabilities and we select a few. Let’s say: produce surveys, sign up survey participants, issue survey requests, collect survey data, translate and cleanse statistical information, organize and store statistical information, and publish reports.
We look to the master list of capabilities because other bureaus of government may also need to do some of those same things. Perhaps the social welfare department also needs to organize and store statistical information? (I’m conjecturing, but hopefully you get the point). By using a common taxonomy of capabilities, you can use the best practices from one business unit in another, and perhaps even leverage some common tools or training or even bits of business process.
Once we have created a list of the capabilities for your business unit, we can do interesting business architectural analysis. Let’s say that the parliment has changed your mission slightly, and added a survey that they want to see collected.
You could produce a capability heat map, which is a diagram that shows each of the capabilities of the business and, using a visual indication, illustrates which capabilities are mature, as well as which capabilities are needed to be mature. A capability that is too mature can garner a reduction in investment, while a capability that needs to increase in maturity can garner additional investment.
Determining maturity requires that you break each capability into four parts: the people, the tools, the processes, and the information (entities). Each is ranked on a maturity scale.
One thing that you have told me, by saying that each of the teams performs a set of activities, is that you have organized the bureau around business capabilities (excellent).
Also, by the fact that you are including references to these capabilities in a process model, it tells me that either you are creating "high level" process models that reflect generalized flow (not useful for measurement… useful for clarification and understanding), or you have a situation where a capability provides only one ‘core’ business process. Both are common.
The salient point is that while the business process is not the same as the capability, it is common to use the same name. Note that process refers to people and tools, but does not encapsulate people and tools. It changes independently, and the notion of being able to reuse a process is only meaningful if you can use the process in other parts of government where there may be different people or tools.
The fact that these capabilities are not actually broken out and offered as separate services to the business tells me that these are capabilities, not business services. To be a business service, it has to be something that is part of the external face of the bureau.
You could say that each survey is a business service, and that each survey requires a set of capabilities (mostly overlapping). The processes may vary, depending on the particular survey.
Each business processes demand features that are delivered by software. Variations in business processes can require different features. Hopefully you don’t require totally different tools for each survey, but if you do have many tools, you can look to see if there is an overlap in the features. If there is, an opportunity for simplification may be to use one tool that provides a superset of features. (This becomes an interesting conversation in a dev-oriented IT shop like Microsoft).
Does this help?
— Nick
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?
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.
Hi Udi,
Thank you for the link. I understand your terms much better now.
The problem is not in the definition of a business service. It is in the definition of a business process. You use a completely different definition than I do.
Business processes are, by definition, a series of tasks that the business performs. They are not algorithms that computers perform.
Humans are involved in business process activities. That is where business draws the line. I don’t drive this. I did not invent it. But if I want to communicate with business users, I must adopt this definition.
Humans are involved. That is important.
Here is what that means: If you have four tasks, A -> B -> C -> D in a business process, and you automate the transition from B -> C, then you have a new business process that looks like this: A -> (B+C) -> D. You have gone from four activities to three. The process has changed.
The combination of B+C is no longer part of a business process. In the past, it was. Not any more. It is now an algorithm.
You hide that combination into a business oriented SOA service (good thing). You refer to that business oriented SOA service as a "business service" and you refer to the logic of connecting B with C as a business process. (bad use of words)
I cannot use either definition of a "business service" or "business process" that you use. I speak with business customers. The definitions you provide are in a different language than they use.
Enterprise Architecture is here to remove obstacles to IT success, including fighting complexity, reducing semantic dissonance, and improving IT practices + tools + alignment in order to bring value. In my role, your terminology would get me laughed out of a presentation.
Laughter is not a good way to build credibility.
I am not disagreeing with your designs. I LIKE YOUR DESIGNS. I disagree with the words that you use to describe them.
Every time you use words like this, you do a serious disservice to the people that you seek to educate, because they must unlearn the terms later.
— Nick
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.
— Nick
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.
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.
— N
Well, it is February 2nd, and today, the Open Group is announcing the general availability of TOGAF version