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.
