Check Jon's latest diginomica blog!

Here's Jon's diginomica blog updates
Read Ultimate SAP User Guide kindle reviews Podcast Feedback

"I listen to all your SAP podcasts in my car, until my kids get mad at me and make me put on music for them instead. Keep up the good work!"

- Robert Max, 2007 Solution Manager Community of Interest, and Systems Management Special Interest Group Chair for the Americas' SAP Users Group - Visitor Feedback

"Jon, let me congratulate you on building a site which exclusively caters to SAP skills and careers and answers a lot of doubts young and senior SAP consultants have about what skills to have and get trained on."

More Site Feedback

"I have been reading your SAP newsletters for over a decade now... It's remarkable that you have now embraced the Web 2.0 delivery methods - Podcasts, Twitter etc - without sacrificing the in-depth nature of your analyses!" - Dave Sen, SAP Enterprise Architect - Reader Feedback

"I visit almost everyday to check out whether there is something new and what the future trends hold for SAP skills and careers."

More Site Feedback

"I was struggling with career direction a few years ago and you provided me with some extremely valuable advise. I've been very satisfied with my career direction which was influenced in large part by your coaching. Thanks again!" - Keith

New JonERP Feedback

"You have always been there with a prompt reply when it matters the most. You have really been a mentor in true sense."

- Hussain Sehorewala -

SAP Article Classics from

Jon has been writing about SAP consulting trends and answering SAP career questions since 1995. Over the years, he's published many popular articles online that have disappeared from the Internet. In this section, we are reclaiming the "best of the archives" and sharing Jon's classic SAP articles from years gone by.

In each case, Jon will write a new introduction explaining the highlights of the article and how the market has changed since it was published. We're hoping to track down some of the interview subjects in these articles and get their updates on how the market has changed since these classics were first published.
Jon Reed Interviews Dave Bernard, SAP EAI Expert Print E-mail
Article Index
Page 1
Page 2
Page 3
Page 4
Page 5

Reed: And do you see yourself fundamentally as an SAP consultant, or an EAI consultant?

Bernard: It really depends on the position. I see myself more as an overall integration consultant. I'll look for EAI opportunities, especially in SAP. If I were doing a web site search, I'd look for webMethods and SAP. I don't see myself as a pure SAP guy. I haven't seen myself as a pure SAP guy for about four years now.

Reed: But wouldn't it take a lot for you to take a long-term project away from SAP at this point? Wouldn't it be hard for you to leave something that has been a foundation for so long in your career? For example, if you had an Oracle-webMethods job offer, would that be hard to pull the trigger on?

Bernard: It would be hard to do, because I just see the SAP environment as more of a challenge. With Hasso Platter and four thousand developers behind him, SAP's always coming out with something new to challenge you with. I just see it as a real rich environment. It's not necessarily the case that I would always stay with SAP, but I probably wouldn't get too far from it, because I don't know what else would provide that richness and challenge.

Reed: Well, this is still a market where you end up being tied to one vendor or another. That's why SAP, in conjunction with various EAI integration tools, is going to be a good place to be, because as you said, it's a huge install base, and a lot of the cutting edge stuff is going on in SAP. That's one major thing that SAP's done in the last year - they've started to reclaim some mindshare, instead of just reacting to the Internet. SAP's started to go forward with more of a cohesive vision of how companies of the future might work, so I think it's becoming an exciting place to be again.

Bernard: I think you're right.

Reed: One more question - getting into the brass tacks of contracting, which a lot of our readers are interested in. Are you incorporated? Did you incorporate right away?

Bernard: No I didn't. But now I have a corporation, and because I have it right now I always bill through it. There are certain benefits, especially in terms of the medical and health costs you can expense. There are other benefits along those lines, but I also incorporated in case I wanted to hire and subcontract to other people. Incorporating is the only way I'd do that, because of the exposure. But there's nothing wrong with working on a 1099 basis. I worked that way for years with clients and it's perfectly fine. I wouldn't be in a hurry to incorporate one way or the other. Going directly to clients, I've never had a problem doing it on a 1099 basis. But if I were to go through brokers or subcontractors, especially with the larger ones, incorporation is the only way to go.

Reed: Dave, that's a great overview of the SAP-EAI career landscape. Thanks for taking the time to speak with us.

Bernard: No problem, Jon, I enjoyed the discussion.

Asking the Expert: SAP EAI Technical Q&A with Dave Bernard, SAP EAI Consultant
August 12, 2002

Believe it or not, even after our six- part interview with Dave Bernard, questions about SAP-EAI remain. So for those readers with a desire to dig a little deeper into SAP-EAI technology, we present this SAP-EAI Technical Q&A. In this feature, Dave wrote out responses to questions we posed to him about SAP-EAI implementation issues. Specifically, we asked him to detail the keys to successful EAI implementations, as well as the biggest implementation mistakes to avoid. In the process of addressing these questions, Dave gives us a deeper understanding of the technical nuts and bolts of SAP-EAI installations.

Jon Reed: When connecting SAP to external apps like i2, which approach seems to work best - using an overall EAI plan and vendor like Vitria, or connecting SAP directly to i2 via vendor-generated APIs and custom interfaces?

Dave Bernard: Because the software vendors are constantly enhancing their products, it's difficult to have a hard-and-fast rule that survives the next product release. If the customer environment is a stable one - R/3 firmly established, with i2 being the only extended enterprise app we want to implement for the foreseeable future - going with the vendor's standard interface mechanism is usually the best route, since vendor-guaranteed support could trump any product connectivity shortfalls.

On the other hand, if a new enterprise deployment, merger, or upgrade is underway, with lots of new apps involved as well as legacy apps, and there is a mandate for many-to-many communication, a full-blown EAI product is usually the best bet. An EAI product is quicker to standardize, and it's a better bet that the EAI vendor will have at least some level of stated adapters/connectors for many of the apps in question. The trade press has really focused on the lack of integration as a dirty little secret of extended enterprise apps (CRM, SCM, B2B, etc).

In response, to address the challenge of integration, enterprise apps vendors have in some cases formed quick, pragmatic alliances with certain EAI vendor(s) to bundle-in EAI product bits into the enterprise app package (e.g. SAP re-badging webMethod's B2B server and adapters into SAP Business Connector, i2 ‘adapting' available integration technology). Problems with this "alliances" approach occur when a company like Ariba allies their products, such as Ariba Buyer, exclusively with an EAI vendor like Tibco for standard R/3 connectivity, while the particular customer happens to be a webMethods Enterprise shop. At that point, tough decisions need to be made - do you go through the trouble of providing an EAI-to-EAI connection? Do you maintain a staff trained on two EAI products? Do you rely upon the enterprise apps vendor's promises to support the shop's preferred EAI vendor within "n" months?

Jon Reed: One thing that we're all curious about is whether EAI can actually deliver on its hype. Can you tell us about projects you've been on where you really have seen a return on investment in an EAI infrastructure? Have you seen some real success stories along the way?


Bernard: As an implementation guy, I don't usually stay on-project long enough for a real hard ROI to be determined (or declared!). But I have been a part of a number of EAI projects that resulted in improved performance and increased efficiency. I've detailed several areas where EAI can have a positive impact on an enterprise environment:


(1) Standardization of GL interfaces - Since the general ledger abstracts the status of the business, many interfaces end up reconciling to the GL. In the traditional SAP world, this has been done with custom pre-processing for RFBIBLI00 BDC (taking into account dreaded differences of coding block, country-specific date format, account type and function group...). More recently, this work has been done in IDOC format, utilizing SAP's ALE technology, and now we see the same work being performed with BAPIs. Even if you're able to standardize on one or more of these (hopefully one only), there are limitations in error notification and re-processing.

For the BDC route, the question is: how will the end-user team learn and be comfortable with stepping through screens via BDC (too often this has to be relegated to an IT team member...). For the IDOC standardization option, what if there is no other client justification for maintaining the potential complexity of Business Workflow? In the case of BAPIs, how do you manually fix data already received if the BAPI fails? And for all of these standardization routes, how do you cross-train the end user AP/AR clerks in the various methods, when SAP was supposed to standardize everything?

An EAI approach allows standardizing the R/3 side of the integration into a single set of processing and formatting routines. Pre-processing can be done through a custom intermediate SAP function module, or better yet, upstream with a custom Java extension at the EAI server level. EAI persistence allows recovery at various stages of processing, or a new ABAP exit (or use of R/3 shared folder and custom processing, or email from either R/3 or the EAI broker) can present a standard user interface allowing a user to see and change invalid data. With a single standardized GL interface approach, the functional IT analysts can get out of the business of production support, freeing them up for other duties.

(2) Business intelligence on the fly - Standard R/3 ERP presents many opportunities for rolling up operational data into SAP's BW. While developing interfaces (especially external ones involving a closed loop integration), custom SAP tables (or DB tables in general if not using SAP) can help track status, not just to provide an audit trail, but to provide performance statistics and decision-making intelligence. With internal interfaces (e.g. remote printing of government-regulated documents, with confirmation feedback to SAP) and external interfaces (e.g. pre-noting of bank accounts for electronic payment of new employees), both internal application and external business partner activity can be monitored and tracked for performance.

(3) Extended business processes - It seems that many third-party processing service providers still do not expose what we think of as "B2B" (Internet, XML) interfaces. This can be for reasons such as security and guaranteed delivery, as well as slowness to change. In sensitive areas, point-to-point ftp is still looked upon with suspicion. Nevertheless, most such processing service vendors (Travel and Entertainment Card, Payroll, Freight Carrier Management) have announced at least an XML or Web Services initiative.

Until such a time as real, non-EDI B2B is supported, EAI remains a viable mechanism for external interfaces with trusted business partners. This may seem to fly in the face of the classical division of EAI for internal interfaces, B2B for external interfaces. But it makes sense if there is, as there should be, a corporate mandate that all interfaces are to be EAI unless otherwise justified. If, as the EAI vendors promise, their EAI servers are B2B-ready, then once a company and its business partners are B2B ready, substituting the newer technology for the former should be little more than "plug it in and test it."

EAI then becomes an intricate part of an extended business process. This was always the promise of EAI: that not only reliable transport, common data superset objects, and pre-built adapters would provide quick implementation of the plumbing, but rather that EAI would allow actual extension of the business process itself.

Such business processes I've seen this approach work for have included: (1) A flow to bank clearing houses to provide automatic payment to vendors and employees, with a return flow allowing vendor and customers to check in on status, to reconcile what has been paid, and to allow the accounting staff to confirm. (2) A flow to a payroll service provider depicting new hires and employee status changes, with a return flow of amounts charged against specific payroll and deduction accounts. (3) A flow of freight shipments made to an external provider, allowing economic shipping point determination and a return flow of invoices paid, so that the loop is closed and the books updated.

(4) Unified support and maintenance - With a single standard for interfaces, a smaller programming team can handle routine fixes and data extensions, as well as the introduction of additional apps to be integrated, with a narrower set of skills required to be learned. Likewise, the help desk and infrastructure team can focus on a smaller domain of points to be fixed, which can later be expanded as performance requirements present themselves. This ongoing, post-initial implementation return from EAI is a real one, and one not often presented in vendor promotional material. This offers a true cost-savings to the enterprise.

mySAPcareers: On the flip side, you've probably seen your share of EAI mishaps or project scope problems where nothing really got accomplished. Do you have any cautionary tales or advice for how to avoid EAI-related project misfires?

Jon Reed: Here are some critical warning signs to watch out for during an EAI project:

(1) Not probing deeply enough during vendor selection - Vendors will claim parity and superiority with the competition, and will showcase similar-sounding functionality. Nevertheless, there are very real differences in things like invasive versus non-invasive adapters/connectors; flexibility in data mapping and transformation tools; persistence of in-transit data, etc. Be sure to ask probing questions so that there are no surprises down the road.

(2) Expectations set too high and too fast - Despite vendor representations, EAI is not necessarily a quick and simple implementation with quick returns. With EAI, there is definitely a learning curve, and this spans the development and architecture teams. In fact, there may be early questioning on the value of EAI because of disappointing extended ROI timetables. The pure B2B side has tended to be simpler, and capable of demonstrating quicker wins than the blue collar EAI integrations (at least, until back-end integration needs to occur!).

If you're implementing full-blown EAI and B2B at the same time, I suggest focusing on quick B2B paybacks, as well as a pilot EAI deliverable, so as to deliver to management some quick and measurable payback, while at the same time starting work on the mainstream implementation. Assignment of team members with real experience in the technologies and products used will go a long way in mitigating risk inherent to project delays and mid-rollout malaise. Inexperienced team members can delay the project in two ways: first, targeted milestones are missed because the task could not be completed (and implementors are too often loathe to raise an early warning flag); and second, because the inexperienced tap the experienced for knowledge, thereby diverting the senior team members from completion of their own tasks.

(3) Lack of standardization in interface design - More than one business process or application may require the implementation of a similar interface. For example, third party plant maintenance application, an indirect materials e-procurement product, and a B2B customer interface may all require the replication of a purchase order in SAP for inventory valuation and invoice processing. If this is the case, a generic Purchase Order interface, utilizing a common PO object, a common custom pre-processing function module, and BAPI wrapper program in SAP will minimize duplication during the development of each interface. Even worse than duplication is the erroneous path of allowing each integration to take on a different "style," which is possible even with EAI tools. The solution is a unified early critical oversight and review of all interface design.

(4) Lack of planning for data re-usability - Business objects and XML document design should be reviewed by the "data czar" to ensure conformance to common denominators or already established common enterprise norms. Each interface requiring material or inventory synchronization should not have a developer designing a whole new item master object. Re-use doesn't "happen," it needs to be designed-in.

(5) Lack of management commitment to EAI - If there isn't top-level support for using EAI for all new interfaces - even the most simple point-to-point ones - it will be too easy to avoid EAI, hence putting at risk the promise of re-use, maintainability, and modular deployment. Any exception to the use of EAI, such as the inability of a third party vendor to support a business requirement with an EAI-ready interface should be approved by a high level director, and should be justified and documented, together with a statement from the vendor as to when to expect this interface to be EAI-ready.

(6) Over-compartmentalization of implementation team - Assigning one person to be a Siebel person, another to be the EAI guy, another to be the mainframe guy, another to be the SAP person, and still another to be the business process designer is not a wise approach. Like the game of "Telephone," there is too much chance for some essential bit of meaning to get lost. If you're doing a very simple point-to-point interface, this compartmentalization of skills may be feasible, but only in the case of small, "cut and dry" projects.

As the requirements become more complex, such as the roll-out of a new business process requiring multi-directional flows with external business partners, the more the team members have a feel for each others' disciplines, the better the chance for success. This is another way of saying: put the most experienced team members - the ones combing cross-technical and business knowledge - on these sorts of EAI projects.


JonERP Feature Interview

Browse Jon's YouTube SAP Videos
Read Ultimate SAP User Guide Reviews

What is Jon Up to Now?

Track Jon in real-time on Twitter
See his latest diginomica blogs

Get Jon's SAP Blog + Videocast Feed (or Email Notifications)

Jon's "Get All My SAP Content" RSS Feed

or Subscribe to the Feed by Email

The Latest JonERP Feedback

"I have referenced your articles on for my internal Fujitsu colleagues on how the functional skill set is changing. It's not just theory, but real life change and the need for new SAP skills."

- Ranjan Baghel, Associate Director, Fujitsu America - Site Feedback

"I can't imagine any SAP professional who is serious about their career not utilizing the website. I know I used it frequently when I did SAP consulting. I use it even more now and I know my colleagues go there quite frequently to increase their knowledge of the SAP market, it is a source of great information."

- David Dawson, SAP Direct Hire Consultant, Acsys -

More Site Feedback

"Jon, you are definitely spot on with your analysis of the SAP market. I've been using your websites for over five years now. Instead of buying all the SAP books, I use your stuff to catch up with what's new in the ever-increasing SAP market." - Mark Reader Feedback

"I've kept up with your site for a long time and your articles via and elsewhere. I just realized a few months ago that you were also the author of the first SAP Consulting book that I read when I decided to take the leap from working at a Utility company to becoming an SAP Consultant. The SAP Consultant Handbook is a staple for any SAP consultant, new or experienced. I just wanted to thank you for the quality work."

- J. Michael Peace, Independent SAP Consultant -