Jon Reed Interviews Dave Bernard, SAP EAI Expert

An Historical View of SAP EAI Trends:
Jon Reed Looks Back on His Interview with SAP EAI Expert Dave Bernard

Jon Reed's Introduction, February 2008: Looking back on my interview with Dave Bernard on SAP EAI technologies, I am struck by how today's EAI market is both fundamentally similar and fundamentally different. As I share these classic pieces with JonERP.com readers, my goal is to help frame today's market by understanding the history of particular SAP technologies and how they evolved. But there's more to these articles than history - there are skills lessons that can be applied today.

When you consider the EAI market, we're inclined to say that this market has gone away because companies no longer want the challenge of integrating ERP systems with third party vendor products like those of WebMethods or Tibco. It's true that some of these projects arefading in prominence, but a search of Dice.com just yielded more than 250 active jobs that involve integrating SAP with either Tibco or WebMethods. So, those EAI markets are hardly dead.

However, we can state with some certainty that companies are starting to focus more of their integration budget on SOA-driven integration projects. The obvious appeal of SOA is that it has the potential to deliver the payoffs of third party integration without having to build and keep up with vendor-based interfaces. SOA's universal web standards and re-usability hardly negate the EAI market, rather, they are the next realization of the powerful impact of EAI, especially when it comes to "opening up" internal ERP systems to customers and suppliers. (for more on the potential of SOA, and SAP's own Enteprise SOA product, check out my "SAP for CIOs" section).

 

In the following interview with Dave, SAP's Enterprise SOA product does not yet exist. But what we can trace in this interview is the roots of the evolution of ERP from a closed, internal system to an open, web-enabled, and customer-driven "intelligent network." Perhaps a bit of the excitement of that initial product shift can be detected in this interview.

The real payoff, looking back, is that as you read through Dave Bernard's market perspective, you get a sense of an approach to navigating an SAP career that is timeless. Dave has always been one step ahead of the market, and I'm convinced that his depth of understanding of the SAP product line, and his commitment to staying on top of SAP's technical changes, is what has kept him one step ahead. Reading back over his thoughts, you can get a clear sense of Dave's career methodology, and I heartily recommend using it.

The last time I heard from Dave, he was still up to his old tricks. He had managed to move into project roles as an IS-Retail Architect, one of SAP's hottest verticals. He was also serving as a NetWeaver integration Solution Architect, helping SAP customers with, you guessed it, their eSOA roadmaps. Dave never misses where the market is going. Oh, and he had two ECC 6.0 installs under his belt and was also about to get PI 7.1 exposure. Perhaps we can have Dave share an update with JonERP.com readers soon and get his latest take on where the market is headed. Until then, enjoy this classic interview.

 

Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP EAI Consultant, Part One
May 13, 2002

Getting stuck in outdated technologies is a consultant's worst nightmare. But how do you avoid that fate? Who could have predicted that we'd see a consulting market quite like this one, where the demand for mainframe skills is on the rise, but you couldn't find a Commerce One job if your life depended on it? Two years ago, nobody would have second-guessed a consultant who left SAP in search of greener pastures in CRM or B2B. Now, many of those same consultants are trying to find their way back into SAP. Meanwhile, back in the SAP marketplace, even highly skilled SAP consultants are finding that their core skills are not as marketable and, in many cases, rates are dropping dramatically.

More than ever before, it's clear that choosing the right projects and developing the right skills is critical to remaining a successful SAP consultant. It's also clear that the SAP consultant of the future needs to be fully aware of what SAP is doing to extend its functionality via web-driven Enterprise Application Integration (EAI). SAP is no longer just the "back office" - it's the "integration hub" of the future enterprise, with extensions into a range of SAP and non-SAP systems and data sources. SAP consultants who understand the business logic and data models that are driving SAP's mySAP solution and EAI efforts are going to be in a better position to capitalize on their SAP backgrounds.

Given the importance of selecting the right projects and developing EAI know-how, we couldn't have found a more appropriate SAP consultant to interview than Dave Bernard. Ever since he left SAP America in 1996 to become an independent consultant, Dave has had a knack for finding the right projects and acquiring cutting edge skills. At the same time, he also avoided the temptation to abandon SAP in search of the Internet gold rush. Instead, Dave found ways of keeping one foot in SAP while getting another foothold in new integration technologies.

Dave was one of the first seasoned ALE-EDI consultants to come our way in the mid-1990s. Even then, he seemed to sense the significance of the limited integration capabilities that SAP was offering in early versions of ALE-supported R/3. But unlike some ALE consultants, Dave didn't just tie his fate to ALE; he continued to move forward into uncharted technical areas. Dave was one of the first consultants we spoke with who had managed to obtain skills integrating SAP with outside "best-of-breed" systems such as i2, Siebel, and Ariba. In the process, he developed expertise using EAI toolkits from vendors such as webMethods, CrossWorlds and Tibco.

Dave broke into XML on a pilot project, where he helped to develop an XML interface to an external procurement card processor. On another project, he helped to design an external interface linking the FI and MM modules to an external travel and entertainment card service provider, via an EAI solution from CrossWorlds/WebSphere. He has also been heavily involved in Java customizations to EAI adapters for SAP systems.

Given the range of Dave's SAP-EAI experience, we asked him to sit down with us and give us some insights into how he has seen EAI technologies evolve on R/3 projects. More importantly, we were hoping to pick his brain and get some insight into how he chooses projects and how he manages to get his hands dirty with cutting edge tools again and again. We were also hoping to find out his take on the current market conditions and where he saw SAP going from here.

In this in-depth interview, we covered all of that and more. In the coming weeks, we'll share Dave's insights into project selection with you. We'll also get his definition of "SAP++," and we'll find out if he really thinks EAI is worthy of all the hype. We'll also take a harder look at e-business buzzwords like "web services," "XML," and "CRM," and see what relevance they really have in the SAP-EAI world. In this wide-ranging interview, Dave gives us a real sense of his commitment to furthering his own professional growth.

Perhaps his appetite for knowledge is the real key to his success - we certainly get a taste of Dave's approach later on in the interview, when he turns the tables on Jon and asks him to assess the SAP marketplace. The result is a lively discussion which proves that neither Dave nor Jon has all the answers. At the same time, it's clear that the best way to navigate this challenging market is by having these kinds of conversations with the most experienced SAP consultants. We hope you'll enjoy the interview and we look forward to your comments.

In the first installment of our interview, Dave tells us the meaning of what he calls "SAP++," and how SAP consultants can stay marketable by keeping their skills "in demand" and watching out for skill areas that are becoming too generic. Dave has always tracked where SAP is going next, and in this first interview segment we start to get a feel for how Dave sees SAP evolving and how he keeps his own skills sharp and finds the right project opportunities.

Jon Reed: Dave, it seems like you've always tried to stay on top of SAP technology over the years. You coined the term "SAP++" to describe the "extended" SAP work you've been involved with. At what point did you become aware of the new directions SAP was going in? Did you stumble onto it, or did you intentionally seek it out?

Dave Bernard: If you go back to the real heyday of SAP back in ‘94/'95, when R/3 first started picking up steam, a major concern of customers was a lack of talent, a lack of available R/3 skills. So their only real option was to bring in SAP consultants from Europe or anyplace in the world where consultants might have actually worked on SAP projects. That scarcity was really a problem at that time, but what SAP customers were told, at least in the U.S., was: "Don't worry, the market will seek its own level, things will even out and soon there will be enough consultants to meet the demand." It's just Economics 101, a matter of the supply catching up with the demand.

Reed: Dave, how have you seen the demand for independent SAP consultants change over the years?

Bernard: When you talk about independent consulting, scarcity can translate into both higher rates and also fewer projects where your specialized skills are needed. Sometimes things come together and you get a lot of projects with high rates, like in the early days of SAP, but that doesn't always work out. But from the customer's standpoint, scarcity and high rates for SAP consultants was a reality that needed to change, or their projects just weren't going to be viable. And from SAP's perspective, they knew these days couldn't last forever - the explosive sales of integrated ERP apps couldn't be on that growth curve forever. There's only a finite amount of Fortune 500 companies, and before too long they were either on SAP or some other ERP system.

Reed: So how did you shift your skills to stay in step with the SAP market?

Bernard: Well, I realized that SAP had to either differentiate its products or come up with new products to anticipate the market. So I just tried to do the same thing as a consultant. I did this by looking ahead a year or two, just like SAP was doing, and trying to gauge where the demand would be. It may be more of a personality thing - there's nothing wrong with doing ABAP or FI, that kind of thing is bread-and-butter and it keeps cookies on the shelf, but I like the stimulus of pursuing new technologies, and when you get on that merry-go-round there's always something new to learn.

Reed: What resources do you use on to stay on top of SAP?

Bernard: You're always trying to read the journals, trying to figure out what that next thing will be beyond pure enterprise applications. A good way to do that is to track SAP through the trade journals and conferences - keep an eye on what the topics are, what the speakers are talking about, and what new books are coming out. The books that are available can tell you a lot. Once we saw several books on ABAP coming out by the summer of 1996, we knew ABAP wasn't going to be a little niche anymore, right? I ask myself, "What is there beyond SAP? What do customers need that SAP and the big consulting firms find hard to satisfy?" Maybe they haven't created a specific practice targeting that area yet. In a way, we're all in the same boat the Big Five are in - looking for the next source of revenue and project opportunities.

Reed: What do you mean when you say "SAP++"?

Bernard: It's a pun on the origin of C++, which was an extension of the basic C programming language. So the "++" are the best-of-breed possibilities that SAP might have originally missed. A good example is "supply chain management," which became popular in the mid-to-late 1990s. SAP noted its lack of a real robust offering in that space, so it formed partnerships with Manugistics and i2. But even though SAP forged partnerships with supply chain vendors, you just knew that for the long term SAP wasn't going to let all that business go to outsiders, so they had to come out with their own answer to supply chain management. You always know that sooner or later, SAP will come out with a successful product, extending themselves from SAP to "SAP++."

Reed: So what kinds of opportunities have you seen for consultants to capitalize on the emerging areas of "SAP++"?

Bernard: Early on, as I said, SAP/supply chain management was a possible niche to move into. If a consultant had managed to stay in the SAP world while looking at that gap in the functionality, hopefully they could have moved from one supply chain application to another, or even to SAP's APO or SCM products and become familiar with them. Another notable example of a new area a consultant could have anticipated is CRM, where initially SAP was caught short, but now, due to SAP's marketing presence and the CRM market shakeout, SAP is a real factor in the CRM market, and as a result, many consulting opportunities are bound to emerge in that space.. What I'm saying is no secret, the big consultancies formed practices along these areas - it's really just a matter of trying to figure out what's new and what's next.

The difficulty for an independent consultant is to try to get engaged on a project where some of that new technology is going to come into play. That's the advantage of getting in quickly - if there's not a lot of projects, then there's not a lot of openings to be had. If you get in after the consulting supply has been built up, then a client will demand a year or two of heavy experience implementing Siebel, for example. So in the case of Siebel, it's now a little bit late to jump into that area, just like it's a little bit late to jump in and become an ABAP programmer now. So to get an advantage early in an emerging market like CRM, you want to pick one or two CRM vendors you'd like to work with, and somehow try to get exposed to that. Which means, as you're interviewing, you want to ask the client what other projects they have underway, and at least learn what their plans are and perhaps express some interest in getting involved in that new area.

Reed: But one of your key points is that you once you get onto the project, you keep pushing to move into new areas as best you can.

Bernard: That's right. After you land the project, you keep up the effort to break in. You talk to your colleagues and the other project teams that may be involved in those target areas, and, if nothing else, at least keep up your research in those new areas. If you do go to trade shows now and then, attend a track on the area you're trying to break into - you'll pick up knowledge that will come in handy later on. In one way or another, if you're willing enough or lucky enough, you'll get involved on a track that will take you there. The real key is identifying it early, and there are a lot of risks there. It may be that what you see as the next big thing turns out to be nothing. We've seen a lot of that lately, for example, in online purchasing or e-procurement. There were a whole string of vendors popping up in that area, and of course, some of them are still plugging along.

When the e-procurement hype was at its highest, consultancies formed practices directed at the Aribas and the Commerce Ones of the world. But if you look closely at the product offerings, online procurement really isn't that rich and deep. Online procurement is a very contained subject and application area - it does not extend across a number of functional areas. Instead, it covers only a narrow application focus, and by itself, e-procurement does not provide an opportunity for its vendors to easily expand their software offerings. The question is, what's the natural market extension for indirect purchasing? Direct purchasing, maybe, but where do you go from there? Certainly not out into the enterprise as a whole.

So e-procurement can't really be extended that much as an offering. Which is why those vendors, I think, quickly saw that their revenue streams based on pure e-procurement packages weren't going to be there, and they quickly moved into trading exchanges and e-marketplaces. I don't want to say they gave away their e-procurement software, but they really saw their biggest revenue stream come from operating exchanges. Of course, that didn't pan out either.

Now SAP is in the e-procurement market in a big way with the EBP product, and it's almost as though that whole e-procurement offering is going to become pretty standard. But I don't see a big growth area there. We've all known consultants who looked at e-procurement and saw it as a longstanding, big thing, but it really hasn't turned out to be that big or that longstanding. You never know. So there is a certain amount of risk, because it takes effort to train yourself and get involved in this or that project. There's also the opportunity cost of what you're not doing. So getting back to what I would call "SAP++" - it's all about trying to stay one step ahead of the market, trying to anticipate what will the market be - knowing in the back of your mind that every time you find a niche, SAP and the other big software vendors are going to be there sooner or later.

Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP EAI Consultant, Part Two

May 27, 2002

In part two of our interview, we trace Dave's SAP career back to his days at SAP America, and we learn how he first got into independent SAP consulting. From there, we take a closer look at Dave's earlier career moves, and we begin to get a sense of how he has anticipated trends in EAI and B2B without leaving the core SAP platform.

Jon Reed: Dave, more than ever, SAP consultants with basic functional and technical skills are having a hard time finding projects. The core markets for generalist SAP skills that used to be so robust have really gone soft. What independent SAP consultants seem to be looking for, and what you seem to be developing, is really a methodology for keeping your skills on the cutting edge without having to take a perm position. Of course, it's not an easy methodology to define - anticipating the next thing, making sure it's the "right call," getting the training/skills in that area, and then getting that all-important, hands-on project work - that's all easier said than done. It's really an art form that seems to come more naturally to you then it does for a lot of people.

So we're hoping that by taking a closer look at your SAP career and the choices you made, we can get some insights into staying on the cutting edge of SAP. In your own career, you had a major transition in 1996. At that time, you were a salaried SAP consultant with SAP America. But after a few years with the mothership, you struck out on your own.

When you first decided to "go independent," you had accumulated a range of skills in the "internal SAP integration" toolkit of that time period - in areas like ABAP, technical architecture/business framework design, Workflow, ALE, EDI. At some point, did you have a moment of truth where you realized it was time to capitalize on the skills you had developed, or did you just realize that an independent consulting lifestyle was going to be a better working arrangement for you? What happened in 1996 that made you decide to move out on your own?

Dave Bernard: I was really happy at SAP at the time, I really was, it was just about the best place I had ever worked. Especially at that time, it was almost like a startup; it was very entrepreneurial, you could create your own roles. But like many people, in the back of my mind, was the idea of going out on my own and seeing what would happen. I really wasn't making a big plan to leave SAP, but I suddenly got offered a contract in a city I didn't mind living in for six months, and so everything just came together. So my family and I discussed it and we went for it. After that, it became a challenge and a way of life.

There's a lot to contracting beyond the possibility of enhanced revenue which may or may not translate into reality at the end of the day... :) But beyond that, there's just a sense that you're doing what you want to do, that you're taking the direction you want to take.

I'm not saying every project is perfect, or every client is perfect. But it's that overall sense of freedom that you get day-to-day as an independent contractor. A person with the right personality will be happier in what they do, uninvolved in office politics, being a project-oriented person.

When I talk about personalities, I think what it really comes down to is having a project-based orientation: everything is organized around a start date, an implementation, and an end date. As a consultant and software engineer, I always had a project orientation anyway. The other aspect you need as an independent is just the willingness to please your client. You're right, I had been at SAP for a while, but I had also worked for other companies before that. I had a pretty good technical base, and things just came together at the right time. I'm not saying I would never work for anyone again, but this suits me for now.
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.
Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP EAI Consultant, Part Four
June 30, 2002

In part four of our interview, we ask Dave to give us his take on the "hot" emerging technologies of XML and Web Services. Dave breaks down the mystique behind web services and explains its potential. Then, Dave turns the tables on Jon and asks him for his take on where enterprise technology is going. Jon's response highlights the significance of EAI, "componentization of ERP apps," and the importance of delivering small, specific "wins" to justify enterprise software investments.

Jon Reed: Did you reach a point on these projects where you really saw the benefits of EAI firsthand, for example, a scenario where a company was able to integrate some supply chain planning information from i2 into their SAP system and it had a real impact on them? Have you seen a company that was able to get beyond the EAI hype and actually get EAI actually working for them?

Dave Bernard: Yes I have. I've seen examples of more tight control over everything from connectivity to external partners, which is a big thing. Whether you're sharing information with banks, freight service providers, or payroll service providers, using EAI rather than file transfer makes things more efficient. It also makes the data recoverability and the determination of what didn't work much easier. From a pure connectivity standpoint, the ability was always there with custom programming, but EAI at least narrows down what has to be custom-programmed.

EAI makes the easy stuff easier, and it makes the data mapping stuff easier too. But the difficult stuff is still difficult and it really doesn't solve that problem. At this point, nothing does. But the benefits are there. I can't really give you numbers, but from my own experience, I've been through a period where first thought EAI was really neat, and then I questioned it, and now, after I've seen it live, I'm more convinced than ever that it is pretty neat functionality.

Reed: One of the most significant changes in the B2B world that is changing the EAI-B2B landscape is the onset of XML, and the impact that XML has had on the classic EDI approach. The option of collaborating via XML over the Internet has obviously opened things up in a variety of ways. Can you talk about these developments from your perspective? When did you first start to see the impact of XML, and how you see XML changing a customer's options in terms of B2B approaches?

Bernard: I think XML is in one of those great market positions - it's both oversold and it's also really good. It really will change things. I first became aware of XML in the marketing press roughly about three years ago. And so when one of the XML-based vendors like webMethods would hold a half-day sales seminar, I would sign up for that, and I'd go and learn about their case histories and how it was used. I basically read everything I could about XML. If you want to stay ahead of the trends, you have to not only read journals but also order those overpriced books from Amazon...

Reed: The ones where they glue a CD-rom to the back cover and jump up the price thirty bucks?

Bernard: Exactly...but the books are good, and besides, you're flying to a client site and what else are you going to do on the airplane? So that's how you become aware of a new technology, and like I mentioned before, if there's ever an opportunity to use it on the project, then you go for it. I'd been reading about XML for a year, year and a half, and lo and behold, I learned that my client was going to be putting in a trial implementation of SAP's Business Connector, which is of course SAP's repackaged webMethods B2B server and SAP adapters. And so I talked to the EDI people; I talked to the B2B people. I basically volunteered and pushed myself in and let it be known that I was interested. I got to the point where I was able to install it on my own system, play around with it, and learn what the Business Connector was all about. So I talked with SAP to make sure the system configuration was okay, and to see what parameters we should use.

I started playing a pick up game of basketball with some of the other guys on the project that were hanging around. I started to pick up a little bit like that, and I was open to it. XML is a whole new world for SAP folks who are used to dealing with IDOCs. IDOCs have the advantage that at least two SAP systems know what they are and understand them the same way. With XML, there's always the danger that two different business partners define how a purchase order looks in completely different ways, and XML isn't going to help, unless they both agree on the format beforehand. Once they agree on the format, then they can either develop or link up applications that they want to communicate with via XML.

When you're talking about building connections between two different business partners, XML is not as big a deal, because you always had the ability to connect two companies anyway. But XML really comes into its own when you look at online communities and trading exchanges. Among a community, where not everybody can agree on standards, you can really see the power of XML at work. We see communities like RosettaNet are starting to define not just an XML format, but also the whole business process and how the exchange will take place, and that's really the bigger part of XML. Beyond pure XML, which is almost old hat in the trade press by now, everyone is talking about "web services."

Web services is really just a fancy way of relegating XML back to just a data format, which it rightly is, and putting up these other services which will help a business community come together over a trading exchange using universally-accepted protocols, which everyone is trying to develop. Everybody is getting into the web services space - SAP is, every other major vendor is, and independent vendors are moving in as well. I guess it remains to be seen how that's really going to play out. It's too early to tell if web services is going to be the "next big thing."

As I mentioned before, there's always an element of risk with these new buzzwords. Just because it's this quarter's magazine article of choice doesn't mean it's going to have staying power in the market. I think it's too early to tell, but web services has a lot of potential. If it does come to be, then web services is going to be infrastructure anyway - it's enabling technology, it's not glamorous in itself, it's a utility.

Reed: Although people are describing web services with a lot of glamour these days. :)

Bernard: Well, there's nothing else going on Jon, I think that's what it is. Since everything else seems to be on hold, web services has come to the forefront as the technology that will enable everything else. And maybe that's a good starting point, I don't know. But I don't think that web services is something that an application-level person would get involved with. It's hard to say.

Reed: So taking all these new technologies into account, what types of projects are you targeting next? Where do you want to take your skills from here?

Bernard: For the next year or so, I don't see any need to leave the EAI world. I think it's important to understand EAI, and to get a good understanding of Java, because all the web-driven EAI products are written in Java. Every IT person coming out of college knows Java, so all the veterans might as well know it also. But for the first time, I'm not seeing anything big on the horizon...how about you?

Reed: No, nothing really explosive on the horizon. As a general trend, it seems that what is compelling to companies now is to find ways of taking their investment in their ERP back-end, and extend that into what you might call specific "wins" or victories in smaller, specific project areas. In the past, companies have been hindered by the sense that you couldn't have a win in one area without upgrading and rehashing everything. And so what SAP is trying to do with the Enterprise Edition of R/3 is to make it more feasible for companies to focus on specific areas where they can have some success stories, without having to overhaul everything.

Bernard: How do you see that working?

Reed: To me, that's where SAP-EAI might come into play. A company could say, "Well, we're finally happy with how our internal system is running, but we'd like to extend this product/delivery information to our suppliers. We'd like to be able to collaborate on certain design issues, and do a better job of monitoring exceptions or handling errors in the requisition of materials from our suppliers. And whether or not we decide to use SAP's tools for this new project, our core enterprise system is SAP, so we're going to talk to SAP about what to do about this. Maybe we'll end up using SAP's products, or maybe we'll use somebody else's." So what sounds hot looking ahead is still that "extending the enterprise" e-business theme.

But what's changed is that the vision is becoming less grandiose. Companies are no longer saying, "Oh, let's bring everybody in our industry together into some big exchange and let's level our biggest competitor." Now their goals are more modest and realistic. They want to use technology for clear, specific purposes.

Instead of just launching a huge CRM project because everybody else is doing it, companies are asking themselves, "How can we tackle these specific objectives in CRM, supply chain, etc., that are particularly relevant to our needs?" And that's the kind of investments they're willing to make.

On the other side, I think the vendors are still trying to figure out how to give companies what they're asking for, because these kinds of integration projects still aren't all that seamless, and more importantly, most of the vendors still want to make big sales, not small wins. With a tight economy and pressure from their shareholders, the vendors want big revenue spikes, not small, incremental project sales. So there is an impasse of sorts, and in the end, companies, a/k/a. "the customers," are going to get what they're asking for.

I think companies are seeing that you really can get a better return on your ERP investment by making use of all the transactional information you have captured - but never really leveraged - in an internal "closed loop." And the vendors like SAP have gotten the message loud and clear: as you said, they've started to build the kinds of EAI tools, business connectors, and adaptors that make these integration projects more viable. Without better integration, it's hard to truly leverage your ERP system. But it's getting more and more feasible to integrate ERP with enterprise-wide supply chain, CRM, and business intelligence initiatives. Ease-of-integration is a real key here. And if you can take away, as you put it, some of the hard work involved in the "here's our APIs, good luck" approach to integration that the vendors have previously taken, you're going to see more and more companies take on some of these focused projects and initiatives.

And more and more, at least within the ERP space, you see vendors like SAP and Oracle finally offering more robust supply chain and CRM applications, where they can truly sell the "ease of integration" to companies, without forcing them to sacrifice too much functionality by going with a more specialized vendor. For example, SAP is really selling its ability to integrate CRM information with supply chain management inside of one total system, where you can actually have your sales and marketing people affecting inventory and product development/order processing decisions in "real time." However, as I said, companies are looking for ways to start small with this stuff, and that remains one of the biggest obstacles.

But it will make a big difference to know that you can upgrade and web-enable your HR module without being forced to upgrade your entire R/3 system and redo any custom modifications you had previously done to other modules. And supposedly that will be possible with the Enterprise edition of R/3 which is shipping a bit later on this year.

Overall, I've been surprised that we haven't seen more action in this "incremental EAI" area, but it may have something to do with the fact that these core ERP packages are still a little bit monolithic. Once your R/3 modules are truly separate, integrated components, then you can do all kinds of sexy things. For example, a company could look at upgrading the FI/CO module in order to put SAP's latest Strategic Enterprise Management (SEM) release on top of it, without having to worry about upgrading their HR module, which may still be running on version 4.0 and doing everything they want it to do without an upgrade.


Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP EAI Consultant, Part Five
July 15, 2002

In part five of our interview, we continue with Dave Bernard's "table turning" of the interview back onto Jon Reed. Jon continues to outline his take on SAP's positioning in the current market, and how the trend towards "componentization" and "incremental IT investments" could play to SAP's strength. Towards the end of this part of our discussion, we return our focus to how Dave's skills have evolved and how he sees his SAP and EAI work coming together. This sets the stage for part six, the concluding portion of our interview, where we'll get to the heart of Dave's strategy for skills enhancement.

Dave Bernard: So "componentizing" the enterprise apps is going to have an impact?

Jon Reed: I think so. "Componentizing" pretty much everything, for lack of a better way of putting it, is a major trend. Another key shift is seeing the major vendors like SAP take more responsibility for the integration burden to try to make it easier for companies to pull the trigger. That's a big change from the attitude of just forcing companies to pick and choose and try to stitch it all together themselves, which I think has really slowed these new initiatives down. Also, with this new "we'll help you put it all together" approach, where SAP is happy just providing the overall architecture and individual workplace portals for their clients, SAP doesn't have to do a hard sell for each new product extension. If their client wants to use SAP's supply chain solution, great. If not, they still have a sales "win" by serving as the technical umbrella and helping the client to integrate the different pieces together with the web-enabled SAP back-end.

And so next year, when it's time for a wireless CRM project, SAP is back in the running again for the next piece of implementation and integration work. And by that time, they've accumulated so much goodwill with the customer by helping them to integrate the last piece, that they are even more on the inside track for future business.

So it does seem like the deep-pocketed ERP vendors are the big winners in this scenario, especially SAP, which is one reason why, Dave, that I think your project choices have worked out so well. At the same time that you were getting into SAP-EAI work, a lot of SAP consultants were clearing out of SAP and moving into Siebel or i2 or Ariba, to name the three most popular defections. Now these same consultants want to get back into SAP, because the best-of-breed vendors have really struggled - even Siebel has its work cut out going forward. There's this sense in the e-business market that if you control the ERP back-end of an enterprise, that going forward you'll have first dibs on a lot of this future work, or at least you'll be the first vendor they turn to. The catch is that you have to be willing to assume a little more responsibility for the overall enterprise, even if it's running heterogeneous applications.
Bernard: That sounds like an interesting area that you'd think you'd see the Big Five targeting and specializing in. They're not going to get these full-blown 300 or 400 person implementations anymore, so maybe narrowing in on something like that could be fruitful, where as you say, there's a focused win that everyone can look at and be proud of. If you want to leverage off that, you can; and if not, well, you've got this piece in.

Reed: I think that's really what's necessary. Even when you talk about CRM, it's just not enough to just run the buzzwords by the right people and get a major project off the ground. CRM continues to benefit from the notion that in an economic downturn, the one thing a company needs to invest in is building and managing their customer base. But in the industry press, CRM has really taken a beating in the last year. Gartner came out with a study saying upwards of 60 percent of all CRM implementations have failed, and it's going to get worse before it gets better.

That may be why, when you talk about CRM, companies are not saying "We need to spend a lot of money on a state-of-the-art CRM system." Instead, they're putting the brakes on and asking focused questions. They're saying: "Wait a minute. What are our specific objectives here; what's the biggest thing we're lacking now? Is it an issue where we are unable to properly identify and target our most profitable customers? Or is it a more basic problem with our call center?" It's a matter of targeting some specific issues, and selecting vendors who can come forward with some specific solutions.

In that kind of market, I'd rather be SAP, Oracle, or PeopleSoft than a best-of-breed vendor trying to come in. Because if you're a big ERP vendor, you can sit down with your current customer and say, "Look, our CRM product can do this, and you're going to have full integration with your existing platform." And since SAP can pick up these little incremental sales in multiple areas with multiple customers, not just in CRM, but also in supply chain, data warehousing/business intelligence, e-procurement, partner relationship management - you name it, they have a solution they can offer - each sale can be a lot smaller and SAP is still making a lot of money at the end of the day. I think that's going to carry a lot of weight.

Obviously, some companies are going to say, "Look, we want this specific niche product that is the best in the world at handling this issue for our industry." SAP wants to be able to say, "Sure, no problem. Your users can access it through mySAP Portals, so they'll have it right on their desktop or laptop via a browser interface - you don't even have to install it on every computer because it's a thin client scenario, and it will be integrated seamlessly through our next-generation business connectors/adapters." So SAP wants to take responsibility for that.

And since SAP has control of the overall environment, they're willing to give up a little more in terms of losing some sales in best-of-breed areas. In the meantime, they're becoming much more competitive across the board, because in a down market, there's all this time for the tecchies in Germany to pound away at these products. And so, when you talk about versions 3.0 of APO, BW, and CRM - these are much stronger releases than version 1.2 or what have you.

So I think these enhanced products are going to create some serious work, but people have to get away from that "Big Bang" mentality, because I don't think that's what customers are asking for. Even when the economy improves, it's going to be a much more accountable process as far as approving project budgets.

And that may reflect some of what we see consultants experiencing these days, where they feel like they have a lot of irons in the fire, but actual job offers don't come together nearly as quickly or as frequently. So as a consultant, you may still get lots of phone calls, and you're talking with companies who are still thinking about hiring you, but they're taking a much more cautious approach which dramatically effects the amount of formal offers that are made. Whereas in the past a company's executives would have pulled the trigger so they could pat each other on the back and say, "We're doing the biggest CRM rollout in our industry," Now they're thinking, "We don't want to be the next Global Crossing, we have to justify this based on the bottom line."

Bernard: I think you're right, and I think what we're seeing now is more "business as normal," and the last few years were more the aberration.

Reed: Yes, it's business-as-normal more than business-in-recession, but I still think things are going to pick up in the months to come. There is a dynamic that Brian Trout has pointed out which is: when your competitors are moving slowly on their e-business infrastructure issues, then you feel justified in doing nothing because your competitors aren't doing anything either. But if the market picks up just a little bit, and some companies start to move ahead with e-business projects, then that can create a little bit of paranoia that can be good for those of us in the SAP consulting business. When a company launches a visible project, then it forces their competitors to ask themselves, "Hey, are we missing the boat?" and that's something that puts a little heat on the market.

Bernard: That's a real good point. Many times, when companies choose to make these kinds of investments, it's not so much that they really need to do it - it's that they can't afford not to do it, because other companies in their industry are getting the media attention for being "innovators."

Reed: I think that's true. Another key point that Brian has made is that a lot of companies haven't clearly defined what their overall e-business architecture is going to look like, and which vendors are going to play key roles, and that's part of the holdup too. If companies don't have a well-developed strategy, it's hard for them to move ahead on e-business projects, because they're not sure how it's going to plug into an architecture they haven't really defined yet. And they don't want to commit prematurely to the wrong solutions from the wrong vendors.

But once again, I think that's a product of a lazy market where you can afford to say, "Well, we're not doing the latest e-business things, but neither are our competitors. We're all running 3.1, we're happy with it, so we'll just lay low for a while." Unfortunately, SAP will be supporting 3.1 for a while longer, so the market boost of "enforced upgrades" is still out there quite a ways. As far as I can tell, that seems like the market we're looking at. And obviously that creates challenges for every vendor in the market. As for your own situation, do you feel tied to the fate of any particular EAI vendor, or do you feel like you could go in a lot of directions? I know you've been exposed to a few of the cutting edge EAI players...

Bernard: Most deeply webMethods and Crossworlds. At this point, it would be hard for me to come out and say, "I'm a pure EAI guy." It's not like the early days, where you could say you had EAI exposure with one vendor, and a client would say, "Well, fine, you can learn the other one we're using." I think the knowledge is readily transportable, because the different tools do pretty much the same thing, but there's that perception that when you start to become specialized with one vendor, it means you're unspecialized in the others. At this point, I couldn't see myself just coming into a Vitria shop and doing that work.

But if I had an opportunity, I wouldn't mind getting involved in a Tibco project. I've managed to leverage some of the Tibco functionality in the past, by integrating Ariba with an SAP system. At this point, I'd only want to focus on the top one, two, or three EAI vendors. I don't know where the other players are going to go. CrossWorlds is already rolled up into IBM's Websphere. So while they definitely have an install base with some large customers, I'm just not seeing a lot of new pure CrossWorlds gigs coming up. SeeBeyond is certainly out there, they recently got a new license and changed their name for some reason, and I know Vitria is still around. But the big two behind webMethods right now are probably Tibco and SeeBeyond, as far as market share and growth prospects.


Integrating a Career:
An In-Depth Interview with Dave Bernard, SAP-EAI Consultant, Part Six
July 15, 2002

In the concluding section of our interview, we get to the heart of Dave's strategy for skills enhancement. We start the discussion by asking Dave about how he goes about selecting projects and what his priorities are in terms of rate versus skills. Then, as Dave elaborates on his approach, he explains the importance of ongoing marketing - "marketing within the project." Finally, to conclude the interview we ask Dave about his short and long term career goals and how SAP (and independent consulting) fits into his plans.

Jon Reed: Let's take a closer look at your own skills strategy, and see if we can get a clearer sense of the methodology that you use in order to get your hands dirty in new areas. Does project selection play a crucial role? When you look at new projects, do you look hard at where they're going with their EAI initiatives, or are rate and location the biggest variables? What are your priorities when you look at new assignments?

Dave Bernard: I think everything is a part of it. For shorter-term projects, if I'm trying to find something to tide me over, I'll do whatever I need to do. But if I'm thinking about a longer-term commitment, then the nature of the work, the realistic possibility for exposure to new technologies or new functional areas within SAP - all of that is of prime importance and would certainly factor into rate.

If I could get involved with a new technology that I think is going to go in a good direction, as well as get exposure to new SAP functionality at the same time, then I'm sure I'd sacrifice some current rate in order to be competitive and get in there. Over the longer term, it's an investment. It's a gamble too. Ideally, you won't have to make that tradeoff. But it's definitely something I would consider, because if you're going to be locked into a project for a year, the first thing you need to ask yourself is where you're going to be after that project is over.

Reed: The other thing that seems crucial to your strategy is that once you get on board a project, you seem to be pretty good at elbowing your way toward the functionality that's really exciting. Maybe that's the wrong phrase, "elbowing your way in," because it sounds as though you're really good at making friends on project sites; not necessarily elbowing your way in, but schmoozing your way in, via pick-up basketball or whatever. It seems like you've figured out how to grab onto technology once you're on the project site, and that seems like a key part of your approach.

Bernard: It's not just technology, it's also functional areas too, and that's one area where an independent has an advantage. You don't necessarily have to market yourself as this or that only. If I were being marketed by a consulting agency, they might say "I've got this ABAPer that knows IDOCs, or I've got this Basis guy." But I can market myself differently based on the perceived needs of a particular client. And once you're on the project, you just have to be persistent and hunt down the new technologies in play.

If you really take an interest in it, if you take it as far as you can and don't ask for help until you need to, if you really take it as a personal challenge, then you can get involved in a lot of different areas and make yourself more valuable and well-rounded. And the more you can do that on a project, the more the client is willing to let you do that, because their people are really busy. That's one freedom that you have as an independent that can be leveraged - you can always try to increase the breadth of the ways you can be of service to your client.

Reed: So a major key is to get yourself into the right place at the right time on the project. You might have been hired to do "Task A," but it just so happens that you've read up on "Task B," you've been to a two day training on "Task B," and lo and behold, the client pulls the trigger on "Task B." It turns out that their IT people are really busy, they don't have anyone to do it, and you say, "Look, I have this functional knowledge, I'm already on the project," and they say, "Yeah, great!" I guess you've probably seen that scenario play out a number of times.

Bernard: That's true.

Reed: Many contractors don't realize that this is the crucial way you get into new areas - it's not necessarily all about getting certified in something new. It's about project selection, and once you're on the project, you have to take it one step further. You have to master the art of getting into new areas once you're on project sites, based upon certain kinds of backgrounds you've developed. The common mistake is to try to get too much up front. For example, a contractor will say, "I'm an MM/PP guy, and I went out and got training in APO. I'm certified, and now I'm going to go out and get an APO project." But that approach doesn't work as well as you might think, especially in a tight market, because there are much more experienced folks out there who have already implemented what you're trying to break into.

The real art is to find ways to leverage the skills you do have to get yourself onto an attractive project, and then, once you're on the project, you try to get yourself into the most interesting areas you can find on that site. And that's when the trainings and the certifications and all the additional things you know start to come into play. Does that sound like a fair description?

Bernard: I think that's a real good way to put it. Once you're on the project, the marketing doesn't stop. You're constantly marketing yourself within the project. Whenever there's an opportunity to learn from the next guy, or the possibility of extending and getting into something new, you put yourself out there. There's just so much opportunity. That's the reason that I tend to target larger companies, because there seem to be more possibilities there.

Reed: "Constantly marketing yourself within the project" - that's got a real ring to it. Looking ahead in your own career, What are your future goals? You seem to really like the hands-on/team lead role. Looking ahead, do you aspire to the full-time project management/Big Five partner track, or do you want to stay closer to the technology?

Bernard: I definitely have my roots in technology. If I were to remain independent and aim for the higher end roles, I'd have to take a completely different approach. I'd have to get myself on the speaker agenda at trade shows, write books, articles, and things like that. I'd have to change tracks and become a full-blown independent management guy, and even at that point, I'd be up against all the big guys. So it becomes harder and harder to find projects, and your market becomes narrower and narrower. It's definitely a possibility, but for now I don't necessarily put myself in this or that niche, I just think of myself as a consultant.

Often, as you said, because clients have a very specific need, it's easiest to get in the door as the answer to a very specific need, so I'll come in for a specific technical area. But during the interview, I'll say, "By the way, I can also do this or that," and I'll ask them, "Are you going into this area? Maybe I can be of service there." Sooner or later, because you've been around the block a little bit, you start to become a go-to guy for this or that, and it plays itself into other responsibilities. I don't necessarily see myself changing because I'm having fun doing what I do now. Do I want to do this forever, travel and all? Probably not, but I'll look at that in a couple of years and start to figure that out.

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:

Successes:

(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.