Skip to Content
Author's profile photo Former Member

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 3: CHALLENGES)

While the changes from R/3 to ECC were addressed in Out with the Old and In with the New: From R/3 to ECC & SOA (Part 1: CHANGES) and the impact of those changes were then examined in Out with the Old and In with the New: From R/3 to ECC & SOA (Part 2: IMPACTS), this 3rd and final blog takes a new direction which is focused on the challenges around this change. Specifically, it reflects on why there has been a lack of understanding about the capabilities of ECC, and how this has had a direct impact on the true realization of SOA as well as on fully leveraging the benefits brought about by these new capabilities. This unawareness is particularly important considering SAP’s clear direction that SOA is actually an integral part of ECC and Business Suite 7 architecture. 


So let’s look at how and why, in many cases, people have not adjusted as well as hoped to the utilization of new architectural capabilities of ECC (while sticking to the ways of R/3), which can have repercussions in implementations because the returns that these platforms are capable of providing are not being fully realized. 


Why the utilization of enterprise services on ECC has been a slow and not-so-smooth process for some


Take a look at this article: SOA Remains a Mystery, Say SAP Users by Leo King (…in it you will notice that according to a recent study, many SAP users  (in this case UK-based businesses) are still pretty much in the dark when it comes to either understanding SOA or having an implementation strategy around SOA. The example provided by this article is intended merely to point out the lack of SOA adoption that is occurring among the SAP user community — and not just within UK, but within other regions as well.


Since ECC was officially released, there has been a general attitude among SAP users that would point to a not very widely supported or welcomed use of ECC’s SOA-enabling capabilities. Instead, there is somewhat of an apprehension when it comes to utilizing Enterprise Service-based functionalities within ECC, suggesting a difficulty to adapt to the many changes that have happened since the R/3 era.


Some common reactions to SOA (ECC’s enhanced capabilities) among SAP users who are not necessarily ‘onboard’ with these changes


1. “I don’t have to know about SOA”

The main culprit for this unresponsive attitude in my opinion is a prevailing lack of awareness about what is “under the hood” of the newly upgraded platform (ECC),- whether we talk of functionality & capabilities, the range of components, or about enhancement packs,  switch framework, and so on. It’s true that there is quite a bit to learn about all the advancements of ECC, however, it is not as overwhelming as it might seem, especially since SAP Community Network has provided so much learning material around ECC’s many capacities. If people really want to learn, they have vast amounts of information available to them within SCN alone. 


2. “SOA is too involved & complicated”

Another reason for the slow adoption has to do with common misconceptions that exist in terms of new approaches that introduce SOA. For instance, the idea some people have that “SOA involves extensive development efforts and additional licensing” is actually unfounded. In fact, it’s just the opposite, since acquiring a license for ECC is all that it takes to access the components and tools which are capable of enabling SOA. And as far as development efforts are concerned, using a SOA-based solution approach can actually reduce implementation time dramatically (thanks to use out-of-box enterprise services and enhancement pack capabilities).  


3. “SOA is not mature enough”

And here’s another general misconception: “Enterprise services are new and not tested”. While there are plenty of reasons that dispute this claim, a detailed explanation goes beyond this particular blog topic. There have definitely been enough success stories and evidence over the past couple of years which point to enterprise services  being very capable of enabling appropriate, technically solid, and reliable solutions for customers over the years. 


4. Uninformed statements from the SOA Nay-sayers

Another reason why ECC’s capabilities around SOA have not completely caught on is just plain skepticism and denial. Hearing things like, “Everything should be done by configurations” and “SOA is still a marketing hype”  simply come across as uninformed statements, and would suggest that there is a big learning curve in store for the owners of these kinds of statements. 

And finally, the lagging adoption of ECC is also due to folk’s prevailing mode of tactical thinking rather than long-term or strategic ways of thinking. The focus instead, tends to be on fast and cost-effective implementation (to the extent that the word “accelerated” sometimes frightens me when it comes to describing project methodologies/approaches). It’s like saying “Let’s just go with the quick-fix approach instead of tackling the bigger issues”.


In other words, people choose to launch into a 4 to 6-month rapid-implementation without pausing for a minute to think about how that implementation might (or might not!) be able to support new product launches down the line, or perhaps how it would impact the merger that the company might be going through in couple of years. I’m not trying to undermine the need at times for cost-effective and short lifecycle implementations, but rather am pointing out the need to keep the larger, more long-term direction of an organization in sight. 


Some ‘work-arounds’ with these above-mentioned challenges


The key here (especially in terms of the preceding example) is to involve strategic-thinking and enterprise architect-based roles from the very get-go (even before the implementation’s start), in order to keep a broader perspective in sight when making solution-driven decisions. 


In my real-world experience educating about new approaches that move away from the ‘R/3 way’ of doing things to both practitioners and customers, there have been many times when it was better to avoid using the acronym “SOA” altogether. It’s as if a negative connotation has been attached to SOA (mainly due to the reasons listed above). Instead, the best approach is sometimes to bring the focus primarily on ‘Enterprise Services’ or ‘Web Services’ which people seem to be more receptive to, rather than referring directly to the term ‘SOA’. This whole idea was very eloquently explained in another blog called “SOA is Dead”. 


However the education process unfolds (with or without the word ‘SOA’), it’s better to learn about these new approaches sooner rather than later, and by whatever means possible. Keep in mind that SOA is as much a part of ECC as the Business Suite is, so let’s wave goodbye to R/3 and welcome all that ECC and its counterpart SOA bring to the table. 


It’s also worth pointing out that SAP is really ahead of its competitors in terms of service-enabling its core ERP platform. We should really leverage these benefits in the solutions we develop and provide to customers as much as possible.  

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Owen Pettiford
      Owen Pettiford
      This set of blogs is a must for all SAP customers who have upgraded to ERP 6.0 and are wondering what all the fuss is about.

      In my blog about different types of eXperts (The specified item was not found.) I highlight the need for the BPX to pull together the traditional with the newer techniques.

      The great news for SAP customers is that new and old can co-exist and that you do need a Solution Architect / Enterprise Architect who understand the various capabilities and their pros and cons.

      The terms SAP use for this role is BPX - the BPX is a person who takes the highlevel guidance from an Enterprise Architect (e.g which components are in his kit bag and why) and applies these to business problems.

      If you are interested in learning more about the BPX role please visit the BPX Community and join the lastest Role Play Community Project ( or contact me.

      Author's profile photo Former Member
      Former Member
      Thanks for your feedback Owen.  I completely agree that the role of BPX would play a key part in projects involving ECC & other business suite applications.
      I know that there's a lot of information about the role of a BPX, but still I feel that there's a need to have a more tighter/focused definition of roles and responsibilities of a BPX, specially in context of different phases of a SAP project involving ASAP or SOA methodology . For example, take a look at this blog by Bernhard - [original link is broken] [original link is broken] This captures some of this information very eloquently with examples. This latest role play community project would definitely help in hashing out details about roles & responsibility of a BPXer throughout different phases of a project. Thanks again for bringing this to community’s attention.

      - Ranjan

      Author's profile photo Former Member
      Former Member
      May I suggest that after years of hammering people that ASAP was the way to implement and run SAP, that this could be the culprit for people not moving away from R3 mentality.

      A blog by Deloittes CIO/CTO stated that they did not consider that ASAP was an ideal choice for building services in a SOA environment.

      Maybe it is time to push the Accelerated ES Methodology more to get people to understand how SAP and SOA work together. 

      Author's profile photo Former Member
      Former Member
      Probably this point which you bring up could be a whole new blog in and of itself - very insightful! I do agree that methodology has a big role to play in terms of holding people back from realizing SOA's full potential. Because really, at the end of the day it's about the methodology which provides a framework for any project implementation, isn't it? So being stuck in the ASAP world definitely has its own limitations.

      ASAP methodology is primarily focused on a packaged implemenation approach which revolves around bolting on the fuctional components and jumping right into the configuration through IMG, and filling in missing RICEF gaps through ABAP codes. So the starting point in this case is really application/technology centric, and less about actually looking at the problems that a project would aim to address.

      With newer methodologies such as AGILE and the Accelerated SOA approach, on the other hand, the focus starts with the analysis of the actual process. Clearly, this calls for a big need of upskilling especially among project managers, since they are in many ways owners of the way a methodology is utilized for a project, and therefore need to step out of their ASAP bubble and look at the project from a process-centric viewpoint (as opposed to functional-centric one). In addition, role of a solutions architect hasn't been very relevant in ASAP driven R/3 world, and may be it's time to give that role it's due importance in ECC world.

      Great thought Geoff!

      Author's profile photo Former Member
      Former Member
      The thought that ASAP may be an issue arose after a conversation with a SAP 'expert'. 

      I am currently working on a project to implement a methodology that enables and promotes SOA in the most effective manner we can. As the enterprise is a mixed environment I have had to consider SAP and non SAP SOA in the methodology.

      The meeting was about the benefits I had discovered and could prove by using the SOA approach to delivering solutions with a view of applying them to a SAP project that will sit on the ECC core, i.e. SOA capable. 

      I advised this person that the only way you could get re-use and therefore benefits was by ensuring that you followed a methodology that promoted re-use to as highest level you could get it, i.e. requirements etc.  His response was “oh, we will use ASAP as our methodology”.

      Now I am not a SAP expert, but by using ASAP as your development methodology you have assumed that you will develop inside SAP, i.e. you have become application centric.  Not only that but you may not be leveraging off the re-use you could achieve if you are only looking at certain SAP functions, i.e. FI etc. 

      I agree with you that if you consider ASAP as your methodology then your mindset is in R3 space, not SOA.  

      Author's profile photo Former Member
      Former Member
      I’m very surprised at the description you gave about your interaction with this SAP “expert”, prompting me to add another point here.

      Thanks for sharing this experience Geoff -- it is so telling as to how lagging some of the “experts” seem to be when it comes to broadening their perspectives beyond the ASAP realm. It also completely relates to what I’ve experienced at many of my recent engagements.

      The reality is that no single client is a 100% SAP shop -- most (if not all) organizations have heterogeneous environments that involve SAP as well as non-SAP systems, so it would be plainly understood that any SAP implementation requires integration with these non-SAP systems as well. Because business processes are not tied to any one system, in order to develop a good solution you first need to develop a good solution <<architecture>> by taking on a more 'holistic' approach to the complete system landscape.

      This to me is really the best way of going about it, but over the years, my observations have been that many teams leading SAP implementations often charge full speed ahead into a project with the mission of bolting on function modules and then handing off the integration part to the technical teams, who are often left with using outdated methods of integrating with things like IDocs & EDIs (almost as a way of compensating for going the ASAP route). Needless to say, this has a direct impact on the quality of the solution.

      A remedy (or rather, alternative) to this should be to start any implementation with an adequate level of process analysis. Fortunately, the role of the business process expert (BPX) is moving in the right direction in this respect, and once that role is more formalized and incorporated into the SOA/ECC-based methodology itself, I think we will start to see a big change in the way projects are run (hopefully!)

      As I pointed out in my blog, one should really appreciate the great lengths that SAP has gone to in terms of effort / $$ to make their platforms interoperable by incorporating industry standards (SOA, XML, etc...) But instead of leveraging these efforts, many folks are still following the path of what you very poignantly described above and based on what I have seen. It is still the archaic ASAP - R/3 approach that many still favor, which is attributed to the various reasons I mentioned throughout the blog.

      Maybe it’s time for some of these so-called “experts” to UN-learn some of the things they are doing, perhaps more out of habit than out of practicality.

      Thanks again Geoff for giving your insight.

      Author's profile photo Former Member
      Former Member
      Thanks Ranjan,

      This is indeed very interesting blog !

      I would like to put some light on another common reaction on SOA.
      However below link take you to a contrary approach for SOA.

      Here important part is that how ECC & SOA reflects positive ROI ?
      A simple metric could be set of :
      All the services being created, Cost to build each service, Integration costs related to service reuse and All service reuse opportunities.

      Yes, if right architecture is on place, SOA over ECC will definitely give positive ROI and a stratigic move to customers.

      Best Regards
      Ram Upadhyay

      Author's profile photo Former Member
      Former Member
      The article above is very good and I would like to see more of this.  I have observed issues in the following areas.  In a company with a large implementation of SAP change requires a strong incentive from the top down.  I think the new global economy will assist movement to ESOA.

      Most individuals require incentives via the management to move from the safe classic R/3 ABAP stack to the Java stack.  I believe the ESOA is the same.

      A. Experienced ABAP developers whom should lead the move from ABAP to Java just do not do it.  It’s not so easy to replace them as it takes years to hand over the experiences.

      B. Experienced BASIS personal do not move from ABAP configuration to taking on Java stack issues that well.  A perfect example is the term ‘BASIS’.

      C. The more recent one is business experts or business analysts.  It would be wonderful to find someone with 20 to 30 years experience on the business process side that would be happy to install NWDS with BPM and use it.  In time this will happen.

      Author's profile photo Former Member
      Former Member
      ABAP WEBDynpro with either NW Portal or the new Business Suite 7 (just upgrade your ERP6 to EhP4 and you get it)NWBC is much simpler than it seemed at first.  My top ABAP programmers learned the WEBDynpro and BP Building Block techniques in less than 3 weeks, even my most die-hard group (when faced with layoff) only too 5-6 weeks.  The time saved aallowed me to make one of two choices; layoff those that did not get with the program, or FINALLY catch up on our backlog.  We are catching up on our backlog.  Even my 'oldest dog' learned quickly!
      Author's profile photo Former Member
      Former Member
      Hi Eric
      It sounds like you're saying you only get SOA by moving to the Java stack. I don't think this is completely correct - or I hope it's not!
      Author's profile photo Former Member
      Former Member
      Hi Eric / Michael – Technically speaking, the Java stack is NOT a prerequisite for developing applications based on SOA.

      ABAP stack is actually a self-sufficient SOA environment, because through its ICM (Internet Communication Manager), the ABAP stack provides the capability to provision as well as to consume web services.

      Conceptually speaking, however, the crux of this debate (Java vs. ABAP) is that neither is really an absolute prerequisite for SOA -- what is actually the definite prereq is a stack of well-defined business cases with corresponding business requirements which can THEN be addressed by a proposed SOA-based solution.

      I’ve seen time and time again that the focal point on approaching the requirements & their corresponding  services often gets drowned out by back-and-forth technical discussions about ABAP, JAVA, interfaces and so on... 

      When the business priorities and processes are addressed from the very get-go, only then can the benefits around agility & flexibility provided by Enterprise Services be fully leveraged with SOA. 

      I want to emphasize here that before getting in the nitties & gritties of ABAP or Java stacks, it is very important (if not crucial) to first understand the real business challenges and how those challenges can be addressed by leveraging the key benefit of SOA -- agility. Obviously re-use is a close runner up for being most beneficial when using SOA, but the discussion needs to start with the core business benefits that an agile SOA-based solution can bring to the table.

      Author's profile photo Phillip Pugh
      Phillip Pugh
      We upgraded to ECC 6.0 this fall.  We are basically developing just like we always have. I don't get it. What is the issue?  Why is SOA etc... the solution. I guess I just don't understand the problems and I sure don't have a clue what the solutions are.  As the lead here I probably should be up to speed, but I don't even see us in race.  Maybe we're so far behind we can't see how far that is.  Any suggested further reading?
      Author's profile photo Former Member
      Former Member
      Missing a lot.  With ERP6 (ECC6 + HCM) there is a rich environemnt of Business Process Methodology functionality that more closely aligns SAP with your business needs.  When you couple it with SAP's Best Practices, not only does the Business part of your company win, but the development costs of SAP Customized programs drops 70%.  We are the world's largest Outsource provider (no we have no relationship with Fujitsu) and have a large group of companies that do use this technology/methodology coupled with ABAP WEBDynpro, and a much smaller group just like yours.  When we compare support costs between groups, that 70% claim is true! In our client base, those that still do things the 'traditional' way is shrinking very fast, and so are their outsourcing costs.
      Author's profile photo Phillip Pugh
      Phillip Pugh
      "there is a rich environemnt of Business Process Methodology functionality that more closely aligns SAP with your business needs."

      Like what?  Where do I go to see all this functionality that we're missing?

      Author's profile photo Former Member
      Former Member
      BPM, Composition Environment, Process Integration.

      These are the 'tools' that deliver the icing on the SAP cake

      Author's profile photo Former Member
      Former Member
      Check out these links -,, and On a side note, Google and SDNs’ search feature also come in handy for information searches like these.

      - Ranjan

      Author's profile photo Former Member
      Former Member
      I’m not sure if any of the below relates to your implementation, hopefully not, but here is my 2 cents worth.

      If your implementation of SAP covers everything that your business does then no problems, you can keep doing what you have always done.

      But I know few companies that don’t use other IT solutions to deliver required functionality that SAP either doesn’t do or is perceived to not do well.

      If you have a lot of these other solutions, the effort to integrate the whole becomes harder and harder etc etc.  Also the amount of duplicated functionality across all these solutions is normally high, i.e. how many copies of customer and product details do you have?  When you now need  to launch a new product or you decide to go into another business things start getting difficult as the change crosses many ‘system’ boundaries’ and IT lags the business desire to move fast.

      So how does the move to an SOA/ESA mindset change this?

      We try to get re-use at the highest possible level we can.  Re-use business process fragments, service enable code and re-use it, reuse portlets etc etc.

      We don’t lock up the business process inside the solution code.  The business process is at a higher abstraction than the execution code.  This means that the business process can change independent to the code and visa versa.

      We don’t build everything in SAP if it already exists somewhere else in our organisation.  We service enable that functionality and use the tools in the SAP ESA stack to either call those services or to place them in compositions.  Conversely we service enable Sap functionality and allow other solutions to use them so that business functionality exists in only one place.

      Just some of the differences I have found in the mindset change needed.

      Author's profile photo Former Member
      Former Member
      Phillip – it would be difficult to comment on the problems and issues that you are talking here without any information on business processes that are enabled by ECC in your environment.

      In terms of suggested reading, I would start by understanding the core concepts and related benefits of SOA, which are described very nicely on Wikipedia here -  As a follow up, you need to understand what has changed from R/3 to ECC/ERP, and how SOA relates to this change. Some of this information has been captured very nicely on SDN wiki here - These links have extensive information on enhancement packs and enterprise services, that are fundamental to SAPS’ SOA strategy. Finally, you have to relate all this information to your business processes, and see how it can be utilized to improve them. From what I’ve seen, this final step is the most critical part, and also the most challenging one because it requires someone with just the right balance of business & technical skill set to drive it.

      - Ranjan

      Author's profile photo Marcello Urbani
      Marcello Urbani
      Thanks for this series, I really needed some framework to put together these new technologies and buzzwords.
      Said that, when I read stuff like this I wonder if we live on the same environment.
      In most places I worked so far (or I heard of)
      A)I tried to limit my usage of OO ABAP because other developers had problems maintaining it.Moving this guys to web services could be costly and needs a strong leadership.
      B)most non-sap systems was legacy ones that used flat files for communication, or perhaps OLE/RFC:
      C)web technologies was only used for marginal projects

      Also, you say architects was not common in SAP projects until yesterday but needed now: where are they expected to come from?

      Author's profile photo Former Member
      Former Member
      Marcello Says "Also, you say architects was not common in SAP projects until yesterday but needed now: where are they expected to come from?"

      Ah but this is the big problem.  Those that know SAP well know it via R3 not ECC.  Those that know SOA well don't know SAP. 

      This I see as the weakness at the moment in SAP's move into SOA (ESA), the fundamental thought processes of the majority of the SAP 'expertise' base is not in the SOA space. 

      I have talked and worked with many SAP experts since ESA (and ECC) was confirmed as the direction for SAP .  I found that few understood the fundamental nature of the strategy and what changes it would mean to how they did their job.  Since that time, more have grasped the concepts and the nature of the changes but the default view is still the R3 view.

      This causes everything to look like a SAP solution, rather than looking at the business and technical landscape and selecting the appropriate tools for the job.  Worse it sometimes locks up the functionality inside some  customisation of SAP when it may be available via standard SAP in a different functional area or now via an enterprise service.

      Where should the architects come from?  Well either SAP experts have to gain a wider view of IT and become holistic architects or the generalist architects have to gain a greater understanding of SAP’s strengths and weaknesses.  Both of these pathways take time and effort that may not be available to most people at the moment.