SAP Community Network Blog: 'Out With The Old, In With The New...'

https://www.sdn.sap.com/irj/sdn February 21, 2009

Blogs - https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12876

Subscribe

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 1: CHANGES) Ranjan Baghel Business Card Company: Fujitsu Consulting, Inc. Posted on Jan. 20, 2009 08:24 PM in ABAP, Web Dynpro, Visual Composer, Service-Oriented Architecture, SAP NetWeaver Platform, Java Programming, ERP, Emerging Technologies, Beginner, Interoperability

Print

Permalink

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] [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.

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.

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. 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 2Next, 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 is focused on educating and increasing awareness about SOA's many capabilities in terms of SAP technology. Working within Fujitsu Consulting's SAP NetWeaver practice, Ranjan educates SAP practitioners and customers about SAP Discovery System, while promoting the use of SAP ECC6 and the need to align with SAP's current and future go-to strategy. Add to: del.icio.us | Digg | Reddit

Any input and feedback is welcome... Comment on this weblog

Showing messages 1 through 6 of 6.

Titles Only Main Topics Oldest First • For Long time awaited info..we get it here

2009-02-19 00:53:14 Shilpa Thata Prakash Business Card [Reply] 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. Details: 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.

o For Long time awaited info..we get it here 2009-02-20 10:56:02 Ranjan Baghel Business Card [Reply] 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 help.sap.com/servicemarketplace 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

• R/3 to ECC 2009-02-17 04:35:25 Saurabh Desai Business Card [Reply] Good information...thanks

• Nice Blog... 2009-01-21 18:30:16 amit bhisekar Business Card [Reply] Hi, Nice Blog , very informative. Amit

• Very Good Blog 2009-01-21 07:24:13 Govindu Nagotla Business Card [Reply] Hi, It is a very usfull blog for all the SAP Consultants and the begginers. i hope next part will be very intersing. Govindu

o Very Good Blog 2009-01-22 13:05:06 Ranjan Baghel Business Card [Reply] 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... Thanks.

Showing messages 1 through 6 of 6.

Blogs - https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13035

Subscribe

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 2: IMPACTS) Ranjan Baghel Business Card Company: Fujitsu Consulting, Inc. Posted on Feb. 02, 2009 08:47 PM in ABAP, Master Data Management (MDM), Enhancement Packages, Emerging Technologies, Web Dynpro, Visual Composer, Service-Oriented Architecture, SAP NetWeaver Platform, SAP Developer Network, Java Programming, Interoperability, ERP, Business Solutions, Business Process Expert, Beginner, SAP Process Integration (PI)

Print

Permalink

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. Ranjan Baghel is focused on educating and increasing awareness about SOA's many capabilities in terms of SAP technology. Working within Fujitsu Consulting's SAP NetWeaver practice, Ranjan educates SAP practitioners and customers about SAP Discovery System, while promoting the use of SAP ECC6 and the need to align with SAP's current and future go-to strategy. Add to: del.icio.us | Digg | Reddit

Any input and feedback welcome... Comment on this weblog

Showing messages 1 through 7 of 7.

Titles Only Main Topics Oldest First • Core modules for business processes

2009-02-19 13:49:28 Bernd von den Brincken Business Card [Reply] 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.

o RE: Core modules for business processes 2009-02-20 12:05:26 Ranjan Baghel Business Card [Reply] 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

• Architecture and the SAP BPP 2009-02-09 07:03:32 Lucas Osse Business Card [Reply] 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.

o Architecture and the SAP BPP 2009-02-10 05:45:37 Ranjan Baghel Business Card [Reply] 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 (https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/11823). 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?

• Well written 2009-02-04 10:59:07 Pascal Menezes Business Card [Reply] This blog really brings out the differences between R/3 and ECC that I did'nt realise before.

o Well written 2009-02-07 06:44:25 Ranjan Baghel Business Card [Reply] 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

• Good blog and examples 2009-02-02 22:57:38 anand reddy Business Card [Reply] The blog was well written and gave overall picture very well..Thanks for the info. Regards, Anand

Showing messages 1 through 7 of 7.

Blogs - https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13197

Subscribe

Out with the Old and In with the New: From R/3 to ECC & SOA (Part 3: CHALLENGES) Ranjan Baghel Business Card Company: Fujitsu Consulting, Inc. Posted on Feb. 15, 2009 12:21 PM in Beginner, Business Suite 7, Emerging Technologies, Enhancement Packages, ERP, SAP Developer Network, Service-Oriented Architecture

Print

Permalink

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 is focused on educating and increasing awareness about SOA's many capabilities in terms of SAP technology. Working within Fujitsu Consulting's SAP NetWeaver practice, Ranjan educates SAP practitioners and customers about SAP Discovery System, while promoting the use of SAP ECC6 and the need to align with SAP's current and future go-to strategy. Add to: del.icio.us | Digg | Reddit

Any input and feedback is welcome... Comment on this weblog

Showing messages 1 through 20 of 20.

Titles Only Main Topics Oldest First • legacy systems and consultants

2009-03-09 12:25:01 Marcello Urbani Business Card [Reply] 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?

o legacy systems and consultants 2009-03-09 16:21:17 Geoff Sadler Business Card [Reply] 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.

• Missing something 2009-03-04 09:17:12 Phillip Pugh Business Card [Reply] 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?

o Re: Missing something 2009-03-16 07:23:35 Ranjan Baghel Business Card [Reply] 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 - http://en.wikipedia.org/wiki/Service-oriented_architecture. 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 - https://wiki.sdn.sap.com/wiki/display/ESpackages/SAP+ERP+6.0. 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

o Missing something 2009-03-09 16:58:15 Geoff Sadler Business Card [Reply] 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.

o Missing something 2009-03-04 16:18:30 Patrick D McCarthy Business Card [Reply] 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.

Missing something 2009-03-05 09:03:39 Phillip Pugh Business Card [Reply] "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?

Re: Where do I go to see all this functionality that we're missing? 2009-03-16 07:44:29 Ranjan Baghel Business Card [Reply] Check out these links - http://solutionbrowser.erp.sap.fmpmedia.com/, https://wiki.sdn.sap.com/wiki/display/ESpackages/Enhancement+Packages, and https://wiki.sdn.sap.com/wiki/display/ESpackages. On a side note, Google and SDNs’ search feature also come in handy for information searches like these.

- Ranjan

Missing something 2009-03-09 16:40:41 Geoff Sadler Business Card [Reply] BPM, Composition Environment, Process Integration. These are the 'tools' that deliver the icing on the SAP cake

• Not so easy "Teaching the old dog new tricks" 2009-03-04 09:03:35 Eric Barfield Business Card [Reply] 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.

o Not so easy "Teaching the old dog new tricks" 2009-03-04 18:44:07 Michael Nicholls Business Card [Reply] 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!

Not so easy "Teaching the old dog new tricks" 2009-03-06 13:57:08 Ranjan Baghel Business Card [Reply] 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.

o Not so easy "Teaching the old dog new tricks" 2009-03-04 16:25:28 Patrick D McCarthy Business Card [Reply] 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!

• ROI on ECC & SOA 2009-02-25 14:35:05 ram Upadhyay Business Card [Reply] 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. http://soa.sys-con.com/node/847118 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

• Maybe ASAP to blame 2009-02-24 21:41:42 Geoff Sadler Business Card [Reply] 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.

o RE: Maybe ASAP to blame 2009-02-25 18:19:26 Ranjan Baghel Business Card [Reply] 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!

RE: Maybe ASAP to blame 2009-02-26 16:51:33 Geoff Sadler Business Card [Reply] 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.

RE: Maybe ASAP to blame 2009-02-27 06:00:00 Ranjan Baghel Business Card [Reply] 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.

• BPX has an important role to play 2009-02-23 04:52:48 Owen Pettiford Business Card [Reply] 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 (https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/9512) 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 (https://wiki.sdn.sap.com/wiki/x/STo) or contact me.

o RE: BPX has an important role to play 2009-02-23 15:49:15 Ranjan Baghel Business Card [Reply] 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 - https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/13278. 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

Showing messages 1 through 20 of 20.