How to map business process and enterprise service?

[Former Member]

Recently, I read some documents about ESA. I'm confusing about the relationship between business process and enterprise service. In other word, how to map the business process to enterprise service after the business process is analyzed? Is there any methodology/rule to define business process and wrap them into service in ESA?

[Former Member]

Hi Chen,

here is my <b></b>oversimplified<i></i> explanation that maybe will help you. ESA is not new technology but rather philosophy. It's an attempt to bring all good and tested design/development patterns to the entire Enterprise world. Simply in three principles it looks like this:

- design/code/deploy modularly: modules/nodes/services depend on each other not in a hardcoded way but via service catalogs and throught standard protocols. So they're quite interchangable and highly available.

- control fine/coars-grain ballance. Orchestrate new and existing services on a needed business level. Depending on required functionality create new facades for exisitng and new services;

- build your business logic on events and messages. Charge your BPM engine (workflow machine) for marshaling messages between the services and make the services treat only the messages. An opposite worst practice would be to either make the services statefull or to make a "workflow" procedure calling different services.

Again, it's an oversimplified version but sometimes it helps to shift your vision.

[Former Member]

Hi Wulff and Roman,

Thank you very much for your comments. But to Roman, I don't understand why "An opposite worst practice would be to either make the services statefull or to make a "workflow" procedure calling different services.". Are there any demerits if we wrap several services into one coarse-grain service which fit the business procedure?

Thanks and Regards,

Sherry

[david_sonnenschein]

Sherry,

I think Roman was really focusing on breaking the Services paradigm by making Services stateful. When we look at Services as building blocks to assemble new applications (capabilities) managing state between the Services basically defeats the benefit. You cannot abstract the implementation and have the service be loosely coupled if the the consumers need to know the details of what is going on behind the interface. Consuming Services cannot need to know where they stand in the process of another service. I believe everything above holds true when considering Services of roughly the same granularity.

When we compose new services from existing finer grained services there may be a need to inject some Service choreography in the new composite service. The key is that the business process encapsulated within that composite service actually defines the service, while the work of the service is primarily carried out by the fine-grained services assembled. State is still managed within the composite and not exposed outside the composite service - thus not violating the concept of no stateful services.

I do not agree that it is a worst practice to orchestrate services that represent a larger business process. The key is that state (and the entire process model) must live outside the stateless services themselves (insuring their potential use in other assemblies). State must reside in the BPM engine (or Process-centric Service) which is focused entirely on orchestrating the interaction of the other services.

You will notice that I switched words - Choreography versus Orchestration. The smart people who came up with the BPEL standard and all the people that argued about WS-Choreography make that distinction and I would encourage you to look at those discussions for better background and arguements than I can give here.

Sorry it too so long to get back to this great thread.

David

[david_sonnenschein]

It is a confusing topic because it likely involves looking at the problems through a different lense than we are used to. If we look at it like we do "application workflow" then we likely miss many of the elements required for loosely-coupled enterprise services. If we look at it like "Enterprise BPM" we focus on the major interfaces between systems and miss an opportunity again break the problem into leveragable Enterprise Services by going too coarse grained, too early.

I saw Kaj's note - what I am describing is not SAP's methodology - they are simply my thoughts on the topic.

First make the distinction between Enterprise Services that perform the work and encapsulate business logic and Enterprise Services that orchestrate the interaction between Services and encapsulate the process logic. Both are required to render a business process within ESA.

The concepts discussed within the specification for BPEL4WS I think provide a good point of view and are certainly a place to look for more info.

Recognize that you will likely end up making "Business-centric" Services, stringing them together with "Process-centric" Services, and then perhaps even calling that a single larger Business / Enterprise Service (and perhaps repeat again...). <i>[Wouldn't a white board be great here?]</i>

Second, look at the issue of Domains of Services. If the Service is part of a particular business domain only and has no value or meaning outside the domain then it is likely something that will be wrapped and orchestrated into something larger that does have meaning outside the domain.

So I do not go on all day, I guess I would summarize the concepts by saying, be prepared to create Services, and orchestrate them into coarser grained business Services. Take those and make new composite services that have value to another layer of the business / organization. Use the concepts of Domains to guide the decision about who owns the ability to change and evolve services and the process models that orchestrate them.

Hope that helps a little.

-- David

[Former Member]

Hi David,

You idea enlightened me greately. Thank you very much! Now I still have some questions about your idea.

1. You pointed out that if we look at ESA like "Enterprise BPM", we may focus on the interfaces between systems and miss something. Actually, I don't understand the meaning of "break the problem into leveragable Enterprise Services by going too coarse grained, too early." Could you please explain it in a more detail way?

2.You also pointed out the Domain of services. I would like to know how we can identify the Domain of services along business process? I think the Domain you mentioned is something like Granularity of services. I'm also confused about how to identify the service granularity along business process. I think services, domain of services and granularity of services should be thought about together when defining services from business process. Do you think so?

[Wulff]

Hi Sherry,

I like to add some of my thoughts about that discussion. From my point of view ESA is much more than just another BPM or Enterprise BPM. ESA is adresses six key areas and I think all of them are really needed:

- <b>People Productivity</b> as the word itself describes...it's about portals and productivity.

- <b>Embedded Analytics</b> has to integrate transactional and analytical content.

- <b>Service Composition</b> is used for model-driven service composition and services orchestration.

- <b>Service Enablement</b> is about a Enterprise Services Repository filled with business meaningful Enterprise Services and service patterns for enabled objects. Excactly this is where SAP has years of experiences.

- <b>Business Process Platform</b> is about service enablement of all application platform objects and engines. This is the place where "BPM" for core business processes resits.

- <b>Life-Cycle Management</b> has to cover the deployment, configuration, operation and change management for ESA based processes.

Therefore the term "BPM" is located in serveral layers of an ESA approach. On the level of <u>Business Process Platform</u> BPM is providing the choreography for core business preocesses.

At <u>Service Enablement</u> BPM needs to compose out of granular services (I would say "atomic" services)

buiness meaningful services (here we have "molecular" services).

The third level where BPM could be used is <u>Service Composition</u> because exactly this is the place

where serveral Enterprise Services could be combined to a process representation.

To come back to the discussion:

1. The question should be how to indentify business meaningful services which could represent single process steps. ATP check, Credit card check, ... could be examples. In theory this service could be out-tasked, defined more flexible etc. This means that processes needs to be evaluated for Enterprise Service candidates. Afterwards you can check against SAP's Enterprise Services Repository for already existing Enterprise Services. The evalution for enterprise services candidates will be supported by the metodology mentioned by Kaj and David.

2. I think domains in this context should be motivated by business and/or functional areas. Depending on the granularity. For example Order Fulfilment Services, Master Data Services, Search Services... These kind of serices can be combined again to services such as "Search of Master Data" (Search Service + Read Master Data Service) etc. or can be used to generate UI to be used in a ESA application.

Your thoughts?

Very best regards

Wulff

[Former Member]

And I have one additional question, from the management point of view. Manager's concern is about how this all fits into company's Balanced Scorecard. Is there any analysis or smth made on this topic - question is not only about money - TCO (i have read a lot about the TCO of SAP NetWeaver), or smth like that - but about other views of the BSC (knowledge, BP, customers, etc.).

[Former Member]

I would request you to vist the blog series "The Architect's world" & visit the link https://www.sdn.sap.com/sdn/developerareas/netweaver.sdn?page=cccp_series.htm.

Maybe, this would be of help to you. Do let me know if you have any queries.

Thank you and best regards

Kartik Iyengar~

[former_member583013]

That is indeed an excellent question. We have developed a methodology that we are currently using internally for how to identify services along business processes. We are planning to make this methodology available externally too, but I do not yet have a specific date for that.

[Former Member]

Hi Kaj,

I'm very interested in your methodology to identify services along business processes. I have read many documents about ESA and web services, and I found they rarely described the relationship between services and business processes specifically. Now we have the technology (such as NetWeaver) and the methodology of identifying business processes (such as ARIS) for enterprise/web services, but I couldn't find the bridge to combine them. So I would be very pleased to know some idea about your methodology about identifying servies along business processes. Or some documents about it will also be helpful. Thank you!

[Former Member]

Hi Kaj,

Still struggling on this same subject some 2 years later...

Posed questions during SAP TechEd'06 in Amsterdam last week on integration of top-down approach starting from business process models and bottom-up approach building guided procedures & composite applications.

Attended various sessions, had several interviews, even got referred / invited to an interesting ES community meeting - however, no clear answers (yet). Can you elaborate on SAP's methodology anytime soon?

Looking forward to explore true SOA implementation in more detail,

kind regards,

Günther

[Former Member]

Hi Gunther,

SAP released new enterprise architecture framework. This framework is also dealing with mapping enterprise level services to business processes. The approach starts with business capabilities (conceptual services), business processes that describe how the enterprises reach capabilities, logical services (Information services) and mapping logical into applications.

There's some data available on the SDN and we are working to add much more.

HTH,

Natty Gur.

[Former Member]

Natan,

Do you know where this enterprise architecture framework can be found? Are you talking about the Enterprise Service Design guide, or something different?

Also, I agree with the previous comment that although this thread is quite old, it is by no means an issue that has been solved. I am currently doing research now on how an organization can properly define the appropriate level of granularity for their basic enterprise services. When is it too small to have value to the business, and when is it so abstract that it can no longer be easily mapped to existing technical services (web services) below?

One comment that struck me earlier in this thread, is the simple fact that an enterprise service must represent a piece of business functionality that represents a step in a process and can theoretically be out-tasked, out-sourced, re-ordered, etc.... that way it provides enterprise agility and potential competitive advantage for the organization. Do you guys agree with this? Do you think there are other major key factors that must be considered?

Thanks,

Matt

[Former Member]

Hi Natan,

Thanks for your reply. Indeed, your contribution to SAP TechEd’06 on SAP’s enterprise architecture framework was very interesting and promising. As are your blogs, EA c’ty presentations, ES c’ty documents and other information that I could find on this subject.

Even more so, I am curious to learn in more detail how to integrate top-down SOA approach starting from business process models and bottom-up SOA approach building guided procedures & composite applications.

Whereas SAP’s enterprise architecture framework may very well provide answers from a conceptual perspective, how do you envision putting true, adaptive SOA into practice using SAP (e.g. VC, CAF) and third party (e.g. ARIS) components?

Can you elaborate on this and/or direct interested BPXs to relevant information and/or proper work groups as to receive updates on proceedings and progress? Looking forward to your response & further contributions and hoping to continue our discussions,

best regards,

Günther

[Former Member]

Matt,

I’m not talking about Enterprise Service Design guide; I’m talking about SAP enterprise architecture framework. right now the framework is available just through SAP business consulting services, I can forward you to the right person. The framework will be publicly available in the fist quarter of 2007. Finding the right granularity service is one of the problems that many enterprises are dealing with today. I think that it’s very hard to come up with cook-book that will help you find the right granularity for enterprises. This is a task which required more interment knowledge of the enterprise. That’s one of the reasons that we’re pushing enterprise architecture as a methodology to help enterprises in the adoption process of E-SOA. It is possible to come up with the right granularity services, but in order to do so you need to get better understanding of your business and the needed information to run the business.

We are talking about three levels of services. 1) Technical services exposed by SAP, other vendors and the enterprise. 2) Logical services that are based on the business and represent the business needs. 2) Composite services: collection of technical services which addressing certain business need. From enterprise architecture point of view we are after the logical services. We want to make sure that all of the business needs will be addressed by services, which we don’t have services which not related to any business need and to make sure that services are reused properly. From our perspective solution architects should map technical services to logical services and create composite services (the Enterprise Service Design guide fits here).

From my point of view in order to support the business agility services needed to be align to business capabilities (or business scenario groups, business scenarios and processes from the solution and business scenario maps). Capabilities are what we are doing in order to reach the enterprise business goals and objectives. Capabilities can be drilled down into sub capabilities and you can drill down any level that meets your business. Capabilities can be seen as conceptual services. Part of the capabilities will be delivered by humans, part by IT and part by combination of human and IT. While capabilities are what is needed to be done, each capability can be described by one or more business processes. Business processes are how we are doing capabilities. There for capability can be described by processes and processes can be composed from capabilities, it simply depends on the level of capability that you’re trying to describe.

I believe that in order to really create agile service oriented IT solution we need to find out which one of the capabilities can be delivered by IT systems (usually by finding out if the capability needs information as input or output). Following this logic each service represent a capability and that enable us to support business changes (BTW, most of the business changes are changes in the way that the capability is done == processes)

HTH,

Natty Gur

[Former Member]

Hi Gunter,

I'll start from your last comment. I believe that strong community around any initiative is one of the key success factors. I'm looking forward to continue this conversation and expand it to other medias.

I know that the information regarding our enterprise architecture framework is pretty limited by now, but we are working on set of articles and white papers to help spread the word. in a matter of fact we are working on a new paper about mapping service level services using the framework. we'll be happy to get a group of users to comment on the paper before formal release.

You're totally right that the framework deals with conceptual (and also logical) perspective. that's exactly who we see the framework. more actual and physical approach should be address by solution architect and set of tools and methodology for this level of work. BUT .... although this hard line that we trying to draw between solution and enterprise architects, we do have clear vision of how all those tools will incorporate together (especially ARIS). I can't elaborate now, but the EA work will have a direct influence on other phases of the IT cycle and vice versa.

HTH,

Natty Gur