ESA/SOA Architecture and SAP

Question

I just went through the ESA/SOA documentation.
In case of implementation of an ESA/SOA concept, we
follow 4 steps.
1. Analysing the core business processes
2. Forecast (Componentizing)
3. Design of the services
4. Implementation
My question relates to 3rd phase.
It talks about retaining the existing investment
made by industries in the current systems/
developments.
So say take an example, i have SAP system 4.6 C
having standard as well as specific functionality
implemented in ABAP.
So how the ESA / SOA architecture will help in
retaining the existing investment made in ABAP
developments.
Few of the issues came to my mind:
1. Not necessarily all ABAP developed have
   there business logic done in function modules.
2. It will involve rework of making all these ABAP
   to make it usefull for ESA.
etc...

Answer 1

Yogesh,
You raise some good points.  In fact we had some similar constraints on re-use (use existing ABAP code as Services) at a client I worked with that already has a number of Services in production.  We leverage BAPI's as Services directly and through XI 3.0.  So just because you have ESA working for you, does not mean that everything SAP 4.6c is automatically useable as a Service.
For instance custom functionality that has been embedded in a set of dialog screens may be very difficult to extract to form a set of coherant Services (case above).  If complex logic has been placed directly in the screens themselves, you will a have harder time dealing with this.  The ESA / Services paradigm, as well general coding principals for component-based development encourage the separation UI and Business logic, but everyone can cite examples of doing it, so there is no reason to ignore it.
The short answer is that "yes" it may involve re-work to leverage the code already developed as Services.  Does this invalidate the statement "leverage existing investment in ABAP as Services"?  No, regardless of language ABAP or Java, code that was never intented to be used as Services will likely involve some re-work/re-configure.  The key is that many of the builing blocks of code that are used can be readily exposed as Services, and that most business functionality can be "wrapped" in a Service facade that makes it usable as Service.  The key is that the hard part has been done, you have code that meets a business need.  The additional step of making it serve as a Service or set of Services is a minor incremental cost.  Here the contrast is pushing something built and tested in a new direction to make it more valuable to the Enterprise -versus- considering buiding something completely new.
Also do not just limit your thinking to ABAP in 4.6c.  You could do some re-work in ABAP to expose capabilities as Services and then leverage NetWeaver to help turn them into the Enterprise Services for the organization.  With Netweaver you have many tools to help you do this with minimal effort.  For instance, if a set of Services are extracted from existing ABAP code (building blocks) that then need to be orchestrated to meet the business need you could use our ccBPM capability of XI to do this instead of the dialog screens that existed before.  You will quickly find you have many Services that can be used by other parts of the organization and mechanism to decouple your implementation from the consumers that use it.
For completeness, not all existing code in ABAP should be turned into Services.  There is plenty of valuable functionality that is only valuable in the context of the R/3 environment.  Part of SAP's use of ESA, is that <u>we</u> are re-working everything we have over time to create and leverage Services.  When we do this, customers have the same Services to leverage "as-is", and we have provided a technology platform (Netweaver) that allows you to extend our Services without creating many of the "custom code" issues that have been a part of the upgrade lifecycle.
David