Webdynpro for ABAP versus Enterprise Services

Question

Hi,
With ECC 6.0 the WebDynpro for ABAP will be available. After converting my well-known ABAP-dynpro screens to WebDynpro I will have the possibility to expose all R/3 functionality from within the portal.
Two years from now the Enterprise Services will be there. What will be the reason(s) for using enterprise services instead of WebDynpro for abap to make R/3 functionality available in the portal? I think at the end both functionalities can co-exist but what are the criteria to use one or both methods?
Greetings Theo

Answer 1

Theo,
This is not a discussion relegated to the bar...
First the short methodology is correct... Id the processes, expose major entry points as Services, orchestrate, publish Service Desc, endpoints, etc., repeat...
The real question remaining is, if I believe my entire process is incorporated with a single SAP system why would I expose Services (and add the additional layer)? 
I agree with the comment where if a process completely executes in a single environment there is no need to change its strategy and force it to be an orchestrated set of Service interactions.  That is not inconsistent with providing Service interfaces along the process so that it can be composed into other processes either not yet in place or requiring cross-system interaction.  ESA is not saying "break open the container and make every little piece operate as Enterprise Services", instead it guides us to Service enable components so that others can consume them in a standard way, regardless of implementation / execution environment.
As we think about leveraging ESA for the benefit of our businesses (our enterprise and the ecosystem of business partners and customers) we have to acknowledge that we do not and will not know where every step of a busines process will execute throughout time.  There may be tremendous value in executing part of a process that could be performed in that same SAP system in a completely different environment.  The main benefit of Service enabling is business agility for a reasonable cost.  I would argue that at least the main entry and exit points to major processes should have Service interfaces, followed by a more comprehensive assessment of internal process steps - looking for opportunities.
The other side of the equation is determining what additional consumers of the process could be found if major parts of the process exposed Service interfaces.  To say, "my process executes inside this one system, so I should not expose it as a set of Services", ignores the potential benefit of other systems being able to incorporate that process in their execution (or parts of a process).  As we expose more, well defined Services that represent aspects of enterprise business processes we create an environment where there is low cost, opportunistic integration based on standards.
Or put more briefly, make sure to execute your business process in an efficent computing manner, but do not let that constraint limit your thinking when it comes to Services.  They are two different (yet related) issues.  Services simply give us another way to leverage an asset we already have.  Make the asset available and if it has value to the organization, it will be consumed.
Hope that helps...
David