From R/3 to ECC & SOA

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.

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 Part 2 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...?

Ranjan Baghel , an Associate SAP practice Director in Fujitsu, educates and advises SAP customers and practitioners about utilizing SAP's latest go-to strategies around ECC6 and its SOA underpinnings.

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

Picking back up where we left off from Part 1, 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.

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 Part 1 and the impact of those changes were then examined in Part 2, 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 (CIO.com)...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.

Ranjan Baghel , an Associate SAP practice Director in Fujitsu, educates and advises SAP customers and practitioners about utilizing SAP's latest go-to strategies around ECC6 and its SOA underpinnings.