Check Jon's latest diginomica blog!

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

JonERP.com 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 -

JonERP.com 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 JonERP.com 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 -

JonERP.com Reader Feedback

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

More JonERP.com 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 JonERP.com

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 as for your first project after SAP, what skills were you using - ALE, EDI, ABAP?

Bernard: It was primarily ABAP at that point. As a consultant, it's one thing to have a broad background in a number of different areas, but what you really need to focus on is what a particular client's needs are at a particular time, which may be only a subset of all the skills you have. But my first project was primarily ABAP, involving interfaces, conversion programs, things like that.

Reed: At some point, you got involved in some pretty interesting EAI-type initiatives that involved extending and integrating SAP with other systems. But what's interesting about your career is that unlike some people who got involved in EAI and best-of-breed applications, you never really left SAP very long. As you mentioned earlier, some folks completely bailed out on SAP for Siebel, i2, and Ariba as those markets were opening up. But you managed to extend into some of those new best-of-breed areas while maintaining a core set of skills in SAP and continuing to work in SAP-based environments. This has allowed you to retain a core set of marketable SAP skills as many best-of-breed consultants are losing steam and trying to get back into SAP. From the start, you seemed to have a real interest in integrating external applications into an SAP architecture. When did you first envision how you might play a role in that area?

Bernard: Well, let's start with your comment about how I've always lived in an SAP world - that wasn't necessarily always by design. At this point, I could do EAI now on webMethods solely - on Oracle Applications to an IBM Mainframe, for example. But over the years, it seemed as though a lot of the large integration projects which I liked the most involved SAP, and because of my SAP background, there was something extra for me to leverage there. It allowed me to walk in and be more productive and more of service at the same time. It wasn't necessarily by design, but that's the way things turned out. In the long run, I think it served me well.

As for how I managed to move from ABAP into SAP-EAI, I actually had a pretty long background in integration, whether it be with a "roll your own" type architecture, using a series of shell scripts and FTP file transfers, or using message-oriented systems such as IBM MQSeries. That sort of infrastructure and middleware was already around when you were moving data in and out of SAP, but I guess the whole EAI push began in 1996 and 1997. Around that time, a few early EAI vendors were coming out with these new suites, and a lot of us technical folks said "Why? We already have ways of moving data around."

With these EAI packages, part of their initial impetus was the goal of taking SAP and the best-of-breed, or what you called "extended enterprise apps," and trying to tie them together. A lot of those best-of-breed apps were looking pretty sexy to clients, but there was no way to tie them together. These third party vendors didn't necessarily have the connectivity that companies needed - that's the thing everybody scratched their heads about after the fact. That was really the first big push of EAI.

Reed: Once you became an independent contractor, was there a point where you said to yourself, "This EAI work sounds very promising; I'd like to do more than just basic ABAP projects. I'm going to seek out some SAP-EAI projects where they're doing some cutting edge things"?

Bernard: I started out as an ABAP guy, and from there, I started expanding within the SAP space. I saw that integration was going to be big. Starting with version 4.0, SAP was going to support BAPIs. And even with 3.0, SAP was using its ALE technology to integrate different instances of R/3. It was not just talk, it was actually being delivered with 3.0. Based on my background in integration, I definitely had an interest in getting involved there, so I jumped into that and focused on integration as much as I could. I sent myself to as many trainings and seminars as I could on those subjects. I just made sure that I was valuable to my client whenever SAP integration issues came up. ALE and the use of extended applications was really a big thing that I became interested in, and it was a natural transfer from that type of integration work to EAI.

Interestingly, we're seeing something similar with the SAP-ALE Users Group, which used to be called the International ALE User's Group. Within the last year and a half or so, they changed their name to the IBI, or International Business Integration User's Group. Their next semi-annual meeting in April is going to be dedicated to EAI. It seems as though there is that tendency to understand, "Well, ALE is the SAP way of integrating with SAP or pseudo-SAP systems, so what if we take it one step beyond that? How do we integrate with non-SAP systems, but treat them as peers in a unified environment?" That's the way the technology is going. It's a natural progression.

 

Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP EAI Consultant, Part Three
June 16, 2002

In part three of our interview, Dave brings us up to date with a brief history of the evolution of EAI technologies. Then, he tells us more about the EAI projects he's been on, and the implementation issues to keep an eye on when embarking on an EAI initiative. This week's edition ends with Dave's thoughts on how SAP might fare head-t--head against some of the EAI specialty vendors like Tibco and webMethods.

Jon Reed: Do you recall your first project experience integrating SAP with some type of external system, or using some type of environment like webMethods or an application like i2?

Dave Bernard: In order to answer that question, I think it might be helpful to offer an overview of how this EAI market emerged.

Reed: Sounds great, Dave, go ahead.

Bernard: If you look at the roots of EAI, EAI comes from at least four different traditions - first, there's the original B2B tradition of EDI. From there you had certain translator vendors that saw some of the advantages of integration beyond the batch static format of EDI. Early on, Mercator began to expand and offer some ALE-type interconnections, and some neat data transformation tools. But oddly enough, in retrospect, none of the other big EDI vendors like Sterling really made that leap into the EAI world, or I should say, the XML world.

And then you have to consider the message-oriented middleware vendors - IBM's MQSeries is a big one. MQSeries started out as reliable, robust, and recoverable data transfer. They really didn't do the higher-level functional type transfer, but they made sure your data got from point A to point B. And from that technology base, with some additional technology from Neon Systems, IBM came out with MQ SI. MQ SI is a set of higher-level, callable interfaces to do EAI, so that's how the entered the EAI market.

The same thing happened with Tibco in the financial industry. Tibco grew from a reliable, message-based system to more of a full-blown EAI product. And then there were vendors that entered the EAI market at the get-go: Crossworlds and Vitria come to mind. You could call these two "blue collar EAI vendors" - they came in, rolled up their sleeves, and did the plumbing between legacy systems, SAP, other ERP systems, and they provided all the tools for that. Only after the fact did they start to realize there was this whole other B2B side of things, and they needed to offer XML connections, Web Services, and RosettaNet type connections, so they eventually saw the light there.

And the final, most recent category of EAI are the pure-bred web vendors that decided to become EAI or full-service integration vendors. webMethods is a good example. webMethods was probably the first XML-type vendor to really make it big, and with their acquisition of ActiveWorks, they are now able to deliver a complete solution - EAI, as well as B2B. Some of the other first B2B or web-based vendors such as Extricity were eventually acquired. So there's this whole evolution towards almost the same functionality from many different EAI vendors that came into the market from different directions. At the same time that this is happening, there's been a real market shakeout. Some vendors have been acquired and some just couldn't compete and just went away. Like everything else in the software market, by the time the shakeout is over, we'll have maybe three big vendors or so. There's been a gradual merging of services and a natural consolidation has occurred.

Reed: That's a great overview of the origins of the different kinds of EAI vendors and approaches. There really does seem to be a convergence of EAI/web-based B2B vendors and technologies into one consolidated marketplace.

Bernard: In terms of projects where I started to see this kind of functionality in play, I guess I was fortunate enough to be involved with projects where companies have truly decided to make a strategic commitment to EAI. This isn't always the case on EAI projects. For example, you can run into situations where companies are just trying to patch two applications together and don't really have an overall EAI strategy - they haven't looked ahead to how this one EAI solution is going to fit into their future architecture. This kind of approach to EAI usually doesn't make sense economically, and they're not projects I would typically want to be involved with.

In those instances, just the cost of paying for licenses and maintaining the system can be pricey. It's just hard to justify that type of project. Unless of course the vendors are bundling the solutions together, then that may be a different case. But at any rate, I've been lucky enough to work on EAI projects where the company has made a strategic decision to implement an overall EAI solution, invest in the training and maintenance of that system, and unify all of their systems and applications using the same EAI solution. On the projects I've been on, I've been fortunate enough to see that strategy in place, so that you really had to get a special exception to violate that rule and get out from under the EAI umbrella.

Now this leads us to another point. When you're thinking about putting in an EAI solution, you first want to determine whether or not the environment is conducive to EAI initiatives. Companies that are changing quickly are good candidates for EAI. On the other hand, if the environment of the organization is a stable one - no major changes on the horizon, no corporate mergers, no big upgrades going on, no acquisitions of new products, and the current interfaces work - then there's probably no need to launch a major EAI initiative.

Reed: Once a company decides to implement an EAI solution, what kinds of issues emerge?

Bernard: In the implementation of EAI, there's some real interesting characteristics to look for too. Maybe there are the same growth stages in any implementation, but at least in the case of EAI, when you first sit down with the client's personnel, the question "Why EAI?" seems to come up a lot. But the more they see it, the more they realize that beyond the marketing blitz, EAI projects can be pretty complex. This leads to a major realization, and the next thing you know the client is saying: "OK, this is not something that is just plug-and-play; there is a lot of work involved."

They start to see that there's probably a lot of custom development work involved despite all the good tools - not only within the EAI application using Java exits, but also, very possibly, within the enterprise apps that the company is integrating. And the more intelligent those enterprise apps, the more likely they're going to be need an SAP connector, or a PeopleSoft adapter. And using that adapter will very possibly involve the need to do some custom programming and some custom data formatting.

So as companies realize what they're up against with EAI, there will be a lot of questioning: "Does this really make sense? Why did we decide to do this?" It was the same way with SAP in the early days - a lot of people questioning why you have to do things a certain way. But once things are in place, the wisdom of that strategic EAI approach starts to reveal itself. It happens at a lot of different levels. It happens in the ease of maintenance of interfaces by a very small team. Once EAI is up there, and you have trained people, then they understand at least the core part of what needs to be changed if, for instance, there's a new data field that needs to be added.

So the long-term enterprise maintenance issues can be handled by a much smaller team, and you don't need so much individual specialization as you did before EAI. Secondly, if the original design crew really had a charter and the support of design for re-use, and the experience and the drive to do it - if they did that right, then as you bring in new apps, or new possibilities for apps, you can re-use what's there. But remember that the re-usability has to be designed in, it doesn't just happen by itself.

There's one more case where EAI proves its value. I haven't seen this in any marketing slides, but I think EAI enforces a discipline on the approach that an implementation team and development team takes to a project. It forces them to think along a common line, so there's not a lot of questions thrown around.

Reed: When you're talking about this kind of EAI design and approach, are you thinking specifically in terms of a third party middleware solution, or could it be that a company would opt to simply use SAP's proprietary tools along with some custom work? Or are you talking about an overall EAI architecture plan where you plug in different pieces from different vendors along with some custom work?

Bernard: I'm talking about purely from a specific EAI product standpoint, basically plugging in middleware...

Reed: ...from a third party, "best-of-breed" EAI vendor like webMethods or Tibco?

Bernard: Exactly. But as we look to the future of EAI, you bring up a very good point. There are certainly different EAI adapters that SAP will be offering, and I think we'll see that more and more from the major enterprise vendors. As we've seen in the past, once niches like EAI are identified, somebody is going to fill them, and I think the big software guys are going to be the guys to do it. The first approach a vendor takes with EAI is usually partnering or bundling/relicensing other products, so we'll see Ariba re-badge Tibco to say, "This is our connectivity product of choice." In the case of SAP, in their new announcements of mySAP technologies, they have a lot to say about web services, and integrating various components using Java and ABAP. But SAP's major direction is packaged integration in the box. I wouldn't be surprised to see them come out with extensions that do adapters to third party apps. It's not that they want to promote it, but if somebody's going to get that business, it might as well be them.

So I see more and more of the applications vendors themselves providing built-in hooks. They're going beyond just saying, "We have APIs," or "We have these BAPIs." I see them going one step further. Now, I don't know if that's a panacea for customers, and I'll give you an example. I mentioned Ariba bundling in Tibco as a way to connect with SAP; well, one of Ariba's customers may have made a strategic choice to use Vitria as their EAI vendor. So then the customer has a problem - do they commit to supporting multiple EAI products; do they actually need to use EAI to connect one EAI solution to another? That kind of scenario gets a little out of hand.

So even though there's a drive for unification - and I think we will see more integration from the vendors - no matter how far the promise of integration goes, that last mile is the hardest. No matter how close you get, there's always another little push where you need more integration, and the more complex the business processes you are implementing, the more complex the solution is. It's interesting work.


 

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 JonERP.com 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 -

JonERP.com Site Feedback

"I can't imagine any SAP professional who is serious about their career not utilizing the JonERP.com 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 JonERP.com 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

JonERP.com Reader Feedback

"I've kept up with your JonERP.com site for a long time and your articles via SearchSAP.com 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 -