Skip to Content

Picking back up where we left off from Out with the Old and In with the New: From R/3 to ECC & SOA (Part 1: CHANGES), this part transitions from the differences between R/3 and ECC on to the impact this change has had on the way ECC-based solutions are implemented.  

 

So when we consider the major impacts of the recent changes from R/3 to ECC on SAP users and customers, the biggest one in my mind is using (or being encouraged to use) a different implementation approach in terms of methodology.  

 

A Fundamental Difference: ASAP vs. Architecture-Centric Methodologies

 

The approach for implementing any system prior to ECC has always been based on ASAP methodology. It is what most SAP practitioners have followed when delivering R/3 based solutions and has been the methodology of choice by many among us. So understandably, such wide acceptance and familiarity of ASAP makes folks reluctant and slow to switch to an altogether new approach. But now that ECC is in the forefront, SAP calls for a new approach and has declared it as the Methodology for Accelerated Transformation to SOA (a.k.a. SOA methodology).

 

And there’s no denying that this is quite different from our standard ASAP methodology in that instead of using an approach in which implementation is almost primarily focused on configuration based solutions (ASAP) — ECC’s SOA methodology starts with a detailed evaluation of the customer’s unique business processes. So we see a major departure from using any baselines or pre-configured criteria, as is the case with ASAP methodology. 

Business process-based approach 

One important catalyst for the genesis of the SOA methodology was the limitations resulting from having a methodology centered primarily around SAP provided baselines, as well as an almost completely ‘one-size-fits-all’ solution approach. This usually meant that organizations’ business processes were not given enough emphasis nor were the underlying process-based problems completely addressed.

 

Alternatively, when looking at the SOA methodology as the appropriate counterpart to ECC, you will see that it is largely driven by a subjective view of the unique business and architectural requirements for every implementation. As mentioned in Part 1, ECC’s key differentiator from R/3 is that it moves away from a very rich and generic functionality that prevailed in the R/3 era, and moves towards a more business-focused approach, thus facilitating complete Business-IT synchronization.

 

Difference in Systems

 

Beyond the obvious differences in approaches to methodology, it’s not just on a conceptual level that you see how ECC has evolved past R/3. Even at a systems level, consider that both A2A and B2B integration are now capable of being completed with the use of Enterprise Services (Web Services) rather than proprietary methods like BAPIs, iDOCs, etc. Also, with the arrival of ECC’s new functionality using Switch Framework and Enhancement Pack-based upgrades, it’s clear that the focus is now on providing solutions specific to customers’ unique business and IT needs, rather than offering everything under the sun.

 

What impact does ECC and SOA have on SAP consultants, managers, shareholders, and customers (all SAP users)?

 

This was the question that had brought Part 1 to a close, which was intended to implant a lingering thought in your minds along the lines of: “What does (or should) this mean to me ?“  

 

It is plain to see that the onset of ECC and its improved functionalities described above are having a huge impact on the way we implement our projects. Frankly speaking, solutions are not (nor should they be) about bolting on function modules, IMG configurations, and traditional ABAP programs anymore. Nowadays, the most effective and optimized solutions that satisfy business and IT requirements come from really understanding first what those business and IT requirements are by getting entrenched in the processes at hand, and then relating those back to capabilities of the tools provided by ECC.  But in order to do this, understanding ECC’s full spectrum of capabilities and its supporting tools is key.  

 

You may be thinking to yourself, “this suggests that business problems weren’t being addressed before ECC – is this really the case?”  

 

Below are 2 major reasons in support of why examining the business problems are more relevant today (with ECC) than before (with R/3). 

 

The Right Tool for the Job 

 

One explanation as to why ECC provides more flexibility in terms of addressing unique requirements is that, there are multiple tools to perform a similar function. For example, you have more than 4 different tools for creating/modifying sales order screen — WD ABAP, WD JAVA, BSP, Visual Composer, HTMLB, Adobe Forms etc. They will more or less all provide a screen to create a sales order on ECC backend, but it’s really a matter of knowing which tool would be the most appropriate to use, based on the requirement at hand. Therefore, the technical developer would need to know and choose the right option that would be suitable for that scenario. The same idea would apply to other components of the solution as well (PI, MDM, etc).  

 

The Right Role for the Job 

 

Another reason is related to the point above, but has more to do with the type of role that is required for such a task as described above. This task would be a good assignment and suitable for someone in a ‘Solutions or Enterprise Architect’ role, who could assess various tools and an provide an overall IT approach in the context of the business requirements. Additionally, a person in this role would need to have a good understanding of the functional (business process-related) issues, while also showing strengths in several different technical areas, mostly in newer technologies such as NetWeaver. People with a strong techno-functional skill-set often transition quite smoothly to EAs. 

 

What I’m pointing to here is that the architect role is needed more than ever now that ECC is the system in place for at least another 3-4 years, and this role will continue to be more important as SAP technologies progressively improve. In the R/3 world, the concept or term of a solution architect was practically irrelevant and non-existent. But this is definitely not the case anymore. Obviously what this means for technical developers is a need to up-skill in order to be familiar with tools like NWDS and the ABAP workbench-based development tools of ECC. But probably more importantly, what it means to functional consultants is a major need to increase their overall awareness about these architectural changes that have happened from R/3 to ECC and to be able to integrate this knowledge into their process- and functionality-centric work. Jon Reed had summarized this nicely in his blog, How is the SAP Functional Skill Set Changing?

 

Leveraging ECC with SOA-based Solutions

 

Taking a step back from the changes that impact us as SAP practitioners, there are two 2 key benefits of SOA which can be encapsulated in two words: Adaptibility & Reusability.  

 

The key driver for the change from R/3 to ECC is actually adaptability (meaning the ease with which solutions can accommodate unforeseen changes in an unpredicted context), and in order for that to happen, the focus should be more strategic / long-term in addition to looking at the immediate requirements at hand. All this should be able to happen in conjunction with any day-to-day & major actions that are being taken by decision-makers.  

 

And by the way, SAP has gone to great lengths to incorporate industry standards in their ECC-based solutions in order to ensure interoperability in a heterogeneous environment. So one should think twice before going with a solution component that does not utilize these recommended industry standard-based components. This final point is what architects and key stakeholders must bear in mind in order to incorporate this strategic vision in their solution approach.

To report this post you need to login first.

7 Comments

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

    1. Ranjan Baghel Post author
      Thank you Pascal & Anand for your positive feedback.

      You would assume that architectural differences between R/3 & ECC are common knowledge, but from my experiences I found that this is one area where there were a lot of misconceptions. Addressing some(if not all) of those misconceptions was one of the main objectives of this blog.

      Regards,
      Ranjan

      (0) 
  1. Lucas Osse
    Hi Ranjan,

    Interesting blog you wrote. I sense some worries in your article on the role of architecture. I think it has to do with a sort of development stage an organisation is in. I wrote a blog about it ‘When is it time for what architecture?’.

    Have you studied the new accelerated SAP approach? I saw only pretty high-level content on the SAP BPP. I think the platform deserves more attention, as it is meant to be used in many different projects. But maybe I missed some parts.

    Regards,

    Lucas.

    (0) 
    1. Ranjan Baghel Post author
      Appreciate your input Lucas. You’re right in noticing that there are some underlying concerns in my blog, not only about the important role that architecture needs to play, but also the crucial need to involve a solution/enterprise architect (and how this is missing in many cases).

      I have also seen in my experience that the projects are generally driven by the functional groups from the very get-go, so the overall direction of the project in a way hinges on their delivery of blueprint, etc. But a lot of times the functional folks don’t have sufficient knowledge on ALL of the technology components available with ECC, so this results in a utilization or approach that is not the most ideal for addressing the particular problem at hand (from an architectural perspective).

      Another thing that I’ve noticed is that typical SAP ERP implementations based on rapid implementation models usually lead to an insufficient level of architectural analysis, due to the shortage of time.

      Your blog sounds like a good read, I will definitely check it out. Also I’m assuming when you write ‘accelerated SAP approach’, this is in reference to my mention of ‘Methodology for Accelerated Transformation to SOA’. You might want to check out Bjoern Treutel’s 2-part series on the topic if you haven’t already seen it (SOA Methodology Blog Series, Part I: How to disenchant the haunted SOA library).

      When you talk about SAP BPP, are you referring to the actual Business Process Procedures that are created at the time of configuration in ECC, or do you mean SAP’s Business Process Platform?

      (0) 
  2. Bernd von den Brincken
    My experience from various projects with SAP R/3 and ERP is that there is a certain lack of flexibility in the the core logistics modules MM, SD and PP.
    This means often that not all of the business processes can be implemented in SAP, unless there is a will and budget for larger programming efforts, which is often not the case.

    I understand that ECC offers improvements in the fields of (web) presentation and interoperability.

    But does ECC offer more flexibility in the core components as well? This would mean replacing the core modules by new, more modular code.

    (0) 
    1. Ranjan Baghel Post author
      Bernd – It’s true that SAP R/3 had a certain lack of flexibility in terms of accomodating changes, and with ECC SAP has tried to address those by changing the underlying architecture. To clarify that point further, the improvements in ECC are not only on presentation and interoperability, but also at configurational level through usage of enhhancement packs, switch framework and industry specific content. There’s some great blogs & articles on these topics on SCN – You might want to check those out.

      Also, it might come across as a generic statement, but it’s very important to accurately define the key drivers of the required change to ensure that delivered solution addresses those drivers. This is even more important in case of ECC, because you have the flexibility of utilizing different approaches/tools for the same problem , and this decision on the approach can make a big difference between good solution versus the other. In other words, more flexibility also comes with more responsibility for solution designers/architects.

      – Ranjan

      (0) 

Leave a Reply