Skip to Content

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

This topic comes in 3 installments. In the first blog, we shall walk through the changes that have occurred over the years concerning SAP’s ERP technology, and what ignited these changes. We’ll also take a look at how SAP’s present and future go-to-market strategy of the ECC platform shares a close connection with SOA, and how the two are interrelated.


Then in the second and third blogs, we’ll dive deeper into the impacts of this overall change from R/3 to ECC, considering why it is necessary for SAP practitioners and customers to increase their awareness and up-skill themselves in terms of the new capabilities that ECC brings. The third blog will also reflect on why we see evident push back and slow assimilation from some SAP users in terms of fully realizing and utilizing the enhanced benefits of ECC (of which SOA is an integral part).


But let’s not get ahead of ourselves…first let us see how ECC came to be what it is today.


What has changed from SAP R/3 to ECC


So we all know that SAP has gone through a lot of changes since the 1990s. Just to summarize briefly…  R/2 became R/3 (which is related to the term ‘real-time’ and consists of 3 tiers of architecture or layers: Presentation, Application, Database). With the advent of R/3, R/2 was used mostly for mainframe architectures.


Then in 2004, what was considered to be SAP’s R/3 enterprise (version 4.7) was enhanced with the addition of SAP’s first web application server (WAS 6.20), thus providing integrated web capabilities that were actually built into the ERP platform for the first time ever.


It is important to note here, that although the ITS (Integrated Transaction Server) platform had already come into existence offering web-enabled capabilities, the major disadvantage of ITS was that it was not integrated with what at that time was a completely ABAP-based core application server of R/3. There were other complexities involved as well, due to having 2 non-integrated application servers (which I won’t go into as part of this blog).

WAS, on the other hand, provided a completely integrated application server core of ERP. Also, the inclusion of both ABAP and JAVA stacks (complementing each other in countless ways) greatly enhanced the capabilities of WAS, as compared to R/3’s application server. One of the many examples of WAS’ web-enabled functionality is its ability to expose BAPIs as web services. This particular feature supports the notion that WAS is claimed to have lead the way for the ERP structure to have its underpinnings grounded on SOA, mainly because of its capacity to expose core SAP functions as web services.

So here we are in 2009, and it has now been 2 years since SAP officially released their latest version of ERP, which we know as SAP ECC or ‘ERP Central Components’.

As we bring the focus primarily on R/3 and ECC, it’s important to realize that within a timeframe of 10-15 years, SAP have gradually and increasingly brought a more versatile and multi-faceted environment for enabling flexible business solutions.

The diagram below depicts the overall shift from R/3’s highly stable but rigid functionality to a far more sophisticated platform, which has been designed to be a lot more adaptive and agile.


Changes from R/3 to ECC
































Moving from left to right, the architecture gets more loosely coupled from the core, while the SAP NetWeaver-based application platform provides the architectural foundation and progressively assimilates more technologies. Also, by 2007 you see SOA becoming the focal point of ECC’s architectural strategy, supported by the fact that literally thousands of enterprise services (the heart of SOA) cover all the major functionalities inside ECC.


So here’s a recap: SAP R/2 –> R/3 –> SAP R/3 Enterprise –> mySAP ERP 2004 –> SAP ECC/ERP 6.0


Now that we’ve covered a brief history of SAP’s evolution over recent years, it is important to identify and address the REASONS that brought about these changes and why this evolution of the platform was necessary to support business demands of today.


Why this change was necessary… 


Today’s business demands for ERP are far different and more complex than the demands of yesterday, simply because there is big distinction between the current-day business models compared to the business models of the 1970s. The main factor with business models of today is the high level and frequency of change that organizations experience (due to acquisitions, mergers, shorter product lifecycles, and globalization). SAP has responded to the changing demands for ERP by addressing what is more relevant in the present for SAP customers and practitioners, which can be summarized as follows:

  • The need for flexibility and cost-effectiveness to configure/customize
  • The need for easier integration with non-SAP platforms
  • The need for better reporting and process visibility for decision-makers
  • The need for better support for industry-specific business needs


Essentially, R/3 is not feasible in current business requirements anymore, primarily due to the following 3 reasons:


  1. No longer boundary walls of just internal processes 

    In previous years of doing business, customers generally focused on their internal processes. They didn’t have much linkage and direct system interaction with external forces such as their vendors, suppliers, partners, nor was the idea of having extended business networks very common or necessary before. But gone are the days when companies could function independently from their suppliers, partners, and vendors. Nowadays, these companies are required to integrate their systems with the ‘enablers’ mentioned in order for their businesses to thrive.

  2. No longer a need for extensive training

    Another reason that this change needed to happen: since the R/3 system was so rigid and rich in its functionality, it was built to be utilized primarily by highly trained users. So there was a good deal of training involved in enabling users to be able to maintain the system. Also these days, constant user training is not very feasible or practical in any given organization’s continuously changing environment. 

  3. No longer can generic solutions be applied – because business cases vary

    Because the R/3 system had more generic functionality, it could not necessarily apply to every business, and everyone knows –- no two business models or business’ processes are exactly alike, since there are always variations. So there ended up being a lot of customization required to work around R/3’s general functionality, thus making future upgrades more difficult and expensive.


 Here’s a brief summary of what has changed


The extent to which ERP has evolved from R/3 to ECC can best be summarized by the following points in relationship to the images below:
































[Above image adapted from Dr. Hichem Maya’s presentation called “SAP NetWeaver® Overview” from the SAP World Tour ’06]


In a nutshell, the main differentiator is the SAP NetWeaver platform. With NetWeaver as the foundation, ECC is capable of assimilating the use of both JAVA and ABAP languages and easily supports new product introductions. Since NetWeaver Developer Studio is for JAVA-based development and ABAP workbench is for ABAP-based components of the new ERP system (but with improved and additional features), it is clear that these development tools significantly enhance ECC’s functionality, further supporting and validating the main distinctions from the R/3 system listed above.


Additionally, the user interfaces have a noticeable contrast when weighing R/3 against ECC. What sets them apart is that in ECC, one can easily develop/customize the user interface according to user preferences (with the use of in-built tools like Visual Composer and WebDynpro). Similarly, the layout of ECC’s UI is way more process-centric as opposed to transaction-centric, thereby further facilitating usability for business users and streamlining workflow.


So now that the key differences have been identified, I shall bring the first part of this topic to a close.


Next, I will pick things back up in Out with the Old and In with the New: From R/3 to ECC & SOA (Part 2: IMPACTS) by addressing the impact of these changes that have happened from R/3 to ECC on a solution approach level and a system level, as well as the need to up-skill in order to keep up with these changes.


In the meantime, one more thing for you to mull over is…


What impact does ECC and SOA have on SAP consultants, managers, shareholders, customers, etc…? 

You must be Logged on to comment or reply to a post.
  • Hi,

    It is a very usfull blog for all the SAP Consultants and the begginers.

    i hope next part will be very intersing.


    • Glad you found it useful Govindu – I’ll try my level best to make the next part very interesting 🙂 while sharing some thoughts/evidence as to how & why the adoption of ECC/SOA has been a bit slow to catch on…


  • Hi,

    The key information, which may sound simple, but usually experts fail to communicate in lay men terms – why NW – when R/3 had WAS – is R/3 having limitation for only abap developments.
    This was a great insight.We(around 10 members) are waiting for such blogs .

    Suggestion:Would be more helpful if you can write a blog, that explains architecture of ECC based on NW with high level process steps
    Eg: For a layman, if you have to explain the data flow happening in ECC 6.0 with NW as platform having 3 layers(DB, App, Client).Here DB – oracle.Usually we wrongly refer R/3 as backend.
    If a customer for first time he is using ECC 6.0 with NW, assuming nothing is installed etc –
    List the steps to have GUI client.exe + Abap system installed with RFC users(define this) + Logical names(Define this + why) + jco connections etc etc..till he uses as end user.
    High level, simple explanation would really help.

    • Hello Shilpa – Thanks for your positive feedback, it really makes the whole effort worthwhile.

      I think you brought up a very valid point about ‘experts failing to communicate in lay men terms’. It’s almost taken for granted that day to day users of SAP products would be familiar with basic information about SAP platforms  –  such as R/3>ECC evolution that has been captured in this blog. But, the reality is quite different, and sometimes these assumptions/misconceptions have a big impact on the way SAP’s products are implemented & leveraged, and invariably creating a certain perception about SAP products and consultants (SIs) implementing these products.
      Regarding your second point about a blog with details, such as installation steps and other technical details, I’m not very sure if it’s worthwhile to recreate this information, as most, if not all of that information is available on for all SAP products. Having said that, I will definitely give more thought about writing such a blog without making it overly detailed, and without re-creating the content that’s already out there.

      – Ranjan

  • I thought the terminology “SAP ECC 6.0” had been retired in favour of “SAP ERP 6.0”?

    Which is correct, nowadays?  I don’t want to confuse the client.  The latest materials seem to refer to the latter…

    • Yes Christopher, you are correct. Officially the term ECC has been retired in favor of ERP, but still ECC 6.0 is most commonly used term even for ERP 6.0

      This article from Jon Reed has very good information on saps’ latest naming conventions – According to this article by Jon – “The “ECC” term is still in use, because technically it still represents the enterprise core of ERP 6.0, but it’s not a term of emphasis when SAP describes its new solutions”

      Hope it helps !

      – Ranjan