Skip to Content

How e-SOA affects the SAP consultant’s work

How e-SOA affects the SAP consultant’s work

Meeting with other SAP professionals and bringing the topic of eSOA to the table I find a pretty diverse mix of reactions.  I find people stating that it is ‘old wine in new bottles, and nothing is changing really’, I find people pointing out that it going to disrupt the SAP ecosystem completely and I find most of the blends in between.

Let’s have a quick look at the changes introduced by eSOA and how they are likely to affect the work of SAP consultants.

eSOA at a Glance

First, in my view and understanding of eSOA, eSOA is SAP its ‘brand’ of service-oriented architecture. And service-oriented architecture is to IT what ‘assemble-to-order’ is for manufacturing. In service-oriented IT we work with chunks of IT functionality that can be combined into meaningful applications using integration software.

These chunks of functionality are much larger than they used to be in IT. Exaggerating for illustration: the chunks used to be e.g. the functionality for a button on a screen while with service-orientation these chunks provide functionality for e.g. customer invoicing or order intake. So the chunks have become much larger.

The other element of service-oriented IT, the integration software, is in fact a range of products that make sure the chunks can communicate among each other, can be invoked in a certain sequence, can be presented on a single user-interface and have consistent data. The complete set of integration software is often called the integration platform.

A New Type of Fit-Gap

Creating applications using SAP products we used to perform so-called fit-gap analyses. Matching business requirements to SAP modules, and if parts were not fitting, either adapt the requirements, or the SAP functionality.  Having eSOA we do a fit-gap analysis, but this fit-gap now is of a different nature than it used to be.

Because the SAP product portfolio is becoming increasingly service-oriented it is or will be possible to do the fit-gap analyses at a much more granular level. No longer need customers either to accept the complete set of (albeit configurable) functionality of the SAP modules or make high costs for developing and maintaining bespoke additional or changed functionality. Because SAP is more and more based on services customers acquire much more freedom to exchange one or more SAP services for services of another (niche) vendor or for functionality already developed in-house. So the fit-gap for packaged-solutions is no longer a fit-gap between business requirements and the solution of a single vendor, but it is more and more a fit-gap between business requirements and the solutions of a whole range of vendors that offer solutions in a certain business segment.

New Types of SAP Professionals

This development will have its consequences for the profiles of professionals that work in fit-gap type of activities. Business automation professionals will need to be fluent in matching business processes to automation options available in SAP, SAP’s ecosystem and in the market as a whole. We need this for business segments like order management, customer relationship management, mobile sales, distribution and many, many more. Creating this type of professional and acquiring a certain influence with these professionals must be a major reason for SAP to actively create and sponsor its BPX community.

Another major change for SAP consultants is that the eSOA concept needs an integration platform. This is not a matter of just using Netweaver products to integrate services into a useful application. eSOA requires Netweaver, but Netweaver does not guarantee you eSOA! If used on a project-by-project basis Netweaver integration will not create an eSOA integration platform but a plethora of integrations that only adds to the complexity and rigidity in the landscape instead of fighting it. Creating an integration platform requires an architecture of the platform and a strategy to build it up, project by project. A new type of professional therefore enters the SAP world: the platform architect.

A third large change that will take place for SAP consultants is the fact that there will be more and more a distinction between the professionals that create a foundation existing of the platform and the services, and the professionals that ‘assemble’ the applications using the platform and the services. Creating the platform and the services requires focus on maximum re-use (and therefore on multiple projects) and robustness. Application ‘assembly’ requires speed, interaction with business users and more single project thinking. For best results these different types of professionals need to be managed and rewarded differently.


The changes taking place in the SAP ecosystem due to the proliferation of eSOA into the SAP products portfolio are considerable. It is bigger than the changes that took place when SAP changed from SAP R/2 to R/3. The change from R/2 to R/3 was mostly a technology change while eSOA changes the way functionality is selected and the way the technology is planned. Thirdly it requires different work styles and performance indicators for the platform – and service builders on one hand and for the application builders on the other hand. May you live in interesting times!

You must be Logged on to comment or reply to a post.
  • Great explanation of how the SAP world is changing. Sure, SAP professionals can still do their job in the ‘old-fashioned’ way, but with these new types we can deliver much more flexibility and quality to the end users. And even faster when you live according to the E-SOA philosophy. Model in stead of code. Re-use in stead of build. Build to adopt in stead of build to last.
    Solution architects (technical perspective) together with the Business Process Experts (functional perspective) and the Platform architects will conquer the SAP world in order to optimal fulfill the customer requirements. Be prepared to live in these interesting times!
  • Dear Lucas,

    when i went through your blog i found it to contain more on giving the changed scenario for a consultant.
    The Roles and Resposibilities of eSOA project implementation consultant will change.

    I would like to add some comments after reading your blog – hope you would be able to answer them for me.

    1) Netweaver integration will not create an eSOA integration platform but a plethora of integrations that only adds to the complexity and rigidity in the landscape instead of fighting it
    Based on the above context do you think eSOA has brought in the complexity or was it there before eSOA itself ?
    How do you think then eSOA as many analysts call will ease the way things will go ahead for ERP vendors ?

    2)Creating an integration platform requires an architecture of the platform and a strategy to build it up, project by project –
    I Would rather say that it should be Building  a integration platform as the core platform already exists which is Busines Process Platform where the core SAP Applications are the Base.

    3)When you have called a new type of professional to be a Platform architect –
    Why cant we call them as “Integration architect” as they are building an integration platform in your explanations

    4)For best results these different types of professionals need to be managed and rewarded differently –
    Does Rewards will only enourage professionals to manage eSOA based projects.
    Why dont we consider this as an amalgamation of different expert professional skills merging at a single point.

    It was a nice and wonderful blog with a different taste to eSOA.
    Hope you continue to dwell more on these kinds of topics


    • Dear Venugopal,

      Let me try to provide you with some answers from my perspective

      1. The point I want to make in my blog is that if Netweaver is used on a project-by-project basis it will create a large number of uncorrelated integrations. What we need is an integration blueprint or architecture. The headlines of that are given by eSOA. Each new project builds up part of this architecture to create, in the end, an integration platform.

      What I see is there are projects that work from the assumption that if one or more products from the Netweaver stack are being used then they build up the eSOA platform. OK, they might be building up experience with the Netweaver toolset, but if there is no integration platform architecture there is little chance these projects build up a an eSOA integration platform. 

      So I do believe that eSOA is the way ahead, but I know it requires work at the drawing table.

      2. I interpret this question as some mutual misunderstanding on the terms integration platform en business process platform. I use the word interation platform for the stack of integration functionality that is required to ‘do’ eSOA: portal, ESB, BPM, MDM, design-time tooling (e.g. ARIS) etc. To my knowledge SAP uses the word Business Process Platform (BPP) for the integration platform plus the set of Enterprise Services (ES’s). This combination can be used to integrate ES’s into useful applications.

      3. OK, I think that anyone architecting an integration based on a portal-type, MDM-type, ESB-type etc. of product can call him/herself an integration architect. I would like to make a distinction between these type of professionals and those that ‘integrate the integration’, that is those that integrate the integration tooling in a platform (as explained above). These professionals are the platform architects.

      4. So based on the above we have the people that create the BPP (the integration stack plus the enterprise service) and those that based on this BPP create the applications. The people that create the BPP focus on robustness of the integration layers and maximum re-usability of the enterprise services. Those that create applications for end-users build these applications as fast as possible, re-using as much as possible the existing enterprise services and integration facilities in the BPP. So the BPP creators need to have a different mindset than the end-user application creators. Therefore they need to be motivated and rewarded differently.

      So it not so much that we need rewards to motivate people to start eSOA projects. Starting eSOA projects is a strategic choice that requires new skills, and to create and grow in these skills we need to reward the right skills.

      The new skills are a mix of existing and new skills. I expect that this will change the actual profiles of SAP consultants. Until that time we need to work with a mix (amalgamation) of SAP consultants with today’s profiles that together provide those skills.

      I hope this sheds some more light on the items in my blog. Looking forward to your answer.

      Best Regards,

      Lucas Osse.

  • Overall, a very good article. However, I’m not sure I agree with the statement that eSOA is a “brand” of SOA. Standard SOA can be a messy place as Web services are consumed from many different places. eSOA provides the business process builder with a coherent, standardised set of services with a centralised service repository, good governance and the ability to develop composite applications.
    • Hello Alistair,

      What I mean with a ‘brand’ of SOA, is that there are more providers of SOA and the (range of) products of each of them have their merits and drawbacks, as you point out. Some more merits than drawbacks, some vice versa.

      But this triggers the question, what are the merits and drawbacks of eSOA compared to other SOA ‘brands’?

      Any suggestions?


      Lucas Osse