Jon Reed Interviews Pat McCarthy, NetWeaver Portals Expert

An Historical View of SAP Enterprise Portals:
Jon Reed Looks Back on His Interview with Portals Expert Pat McCarthy

Jon Reed's Introduction, January 2008: In September of 2002, I sat down with Pat McCarthy, Enterprise Portals expert, about the emergence of the SAP Enterprise Portals project. The interview was very popular with mySAPcareers readers, and I'm pleased to be able to offer it in its entirety for members.

The Portals market has obviously changed considerably since Pat's last update to this interview series in 2004. Hopefully soon we can have Pat on our web site for his take on how the Portals market has evolved since 2004, and the direction he has pursued in his own SAP career. Pat has always stayed one step ahead of the market, so we'll do our best to provide updates on his whereabouts going forward.

As you read through the installments in this interview, you'll get a sense of why I enjoy Pat's take on the SAP market so much. He is great about combining a grasp of the nuts and bolts of SAP with a straightforward and sometimes humorous take on the strange paths SAP can take us down. Talking with Pat about SAP is like taking a look under the hood of a car and getting a review of the insides from a real pro.

A couple things I really enjoy about this piece looking back: towards the end, Pat answers a reader's question about Enterprise Portals consulting, and his advice on how to approach an SAP consulting career and stay on top of new skills is timeless. And the final update, in 2004, shows Pat talking about some of the early components that would become part of NetWeaver, such as the Web Application Server, now known as the NetWeaver Application Server.

I have said many times that successful SAP consultants always have an eye towards how the SAP product line is evolving. But as I add these classic articles to the site, I can now see that it's also important to understand the history of SAP and how the products we worked on today evolved. As we've heard before, history has a way of repeating itself. I hope you enjoy this interview, revived on our web site and reprinted in its entirety.

SAP's Enterprise Portal Strategy and its Impact on SAP Consultants:
An In-Depth Interview with Pat McCarthy, SAP Enterprise Portals and mySAP Consultant
Part One
September 1, 2002

We launched with the belief that the future of SAP consulting is in the mySAP technology platform for e-business. In the last year and half, over the course of interviews with experts like BW consultant Naeem Hashmi and SAP-EAI specialist Dave Bernard, we've tried to flesh out SAP's e-business direction and identify the consulting opportunities that are opening up along the way. But up until this point, we haven't been able to call attention to a specific product that truly makes SAP's new direction a reality. 

That is, until now. From the looks of it, SAP's Enterprise Portals and Web Application Server infrastructure has truly arrived, bringing with it an ease of use and "out of the box" integration capability unheard of in the ERP world of the ‘90s. Needless to say, these new products also mark a fundamental shift in SAP's technical philosophy - from the proprietary "bread-and-butter" of ABAP and Basis to the "open" technologies of Java, XML, and J2EE. Clearly, these shifts in technology and presentation will eventually impact all SAP consultants, whether they are functional or technical in focus. Although the sluggish economy dictates that any new IT product can only have gradual success, as it turns out, the SAP Enterprise Portals value proposition makes it possible for clients to minimize spending through an incremental approach - or even better, by simply "turning the lights on" and leveraging existing functionality that was not yet in use.

What better time to sit down with an experienced Portals consultant and pick his brain about the product and the consulting opportunities he sees down the line? Pat McCarthy is a platinum-level SAP consultant with ten years of techno-functional SAP experience. He's been involved with cutting edge SAP products like BW and APO from their earliest releases, and more recently, he's gained project experience in EBP and SEM. But Pat's main area of expertise centers around the mySAP solution, specifically SAP Enterprise Portals (formerly Workplace) and the Web Application Server (formerly the Internet Transaction Server). He's followed these products from their early releases, and most importantly, he's seen the latest versions at work on client sites. In this interview, Pat tells us what works and what doesn't, and why he sees so much potential in the SAP Enterprise Portals market.

Of course, no interview on SAP's future direction would be credible without an honest appraisal of the current situation. Through the course of our discussion, we made sure to consider the market conditions we're all dealing with now. We asked Pat to explain why he can feel good about SAP's future when SAP's current sales figures are under expectations. From his own project searches, Pat knows full well that the bright future of SAP has not yet arrived. He's not about to suggest that we should drop what we're doing now and head over to Portals, especially during a time when that market is still in its "painful infancy." But his perspective on how this technology is delivering on the vision of the information-driven enterprise is compelling, and is food for thought for any SAP consultant in transition.

During the course of this interview, we cover a wide range of topics pertaining to SAP Enterprise Portals. In addition to making his case for "Why Portals and Why Now," Pat explains the different pieces of the Portals solution. He explains how third party apps are integrated with SAP and how the system gives ease of use to the end-user by hiding back-end complexity. Since we all want to know how you get there from here, we asked Pat to elaborate on how today's SAP consultants could get more involved in Portals work and position themselves for the emergence of SAP as a true e-business player.

He has advice for Basis and ABAP folks on how to be ready for an Internet-driven technology and development platform. Pat's comments on functional opportunities bring us back to BW, which, through the Portals architecture, seems to be changing from "enhanced reporting tool" to "essential business intelligence engine," as Naeem Hashmi predicted in our interview with him a year ago. And for all of us who were scratching our heads on this, we also got Pat's take on what happened to SAP Markets. Towards the end of the interview, Pat tells us why "componentizing" SAP's application suite is a revolutionary development with promising implications for small to mid-market sales. There's a lot of ground to cover here, and we think you'll find Pat's comments entertaining and thought-provoking.

In part one of the interview, Pat tells us how enterprise portal technology has moved into the "generation two" era. And he explains how SAP's Enterprise Portals are central to SAP's move from proprietary, ABAP-based systems, to "open systems," based on Java and XML. Pat explains why this technology shift also represents a dramatic "mindset" change in terms of how SAP treats its customers, from "one size fits all" and "rip and replace" to componentized, "drag and drop" solutions that integrate existing applications on the user's desktop.

Jon Reed: Pat, you're seeing a lot of potential for the future of enterprise portals. Why is that?

Pat McCarthy:
First of all, enterprise portals have evolved. The new ones they're coming out with now are what we call "generation two portals." When the first generation of portals came out, anything you could possibly use the word "browser" with was considered a portal. Generation two, though, is pretty much taking the Corporation Information Factory (my kudos to Bill Inmon for that phrase) and making it accessible to everyone in a form they understand - and people understand the browser. From SAP's point of view, a portal is the methodology they're using to bring together all the data in the enterprise, to take it and make it available for people to use. And now this data can either be SAP or non-SAP data. It really is something different for SAP. It wasn't that long ago where if it wasn't developed in Walldorf, then you could forget it! Even if it was done somewhere else in Germany, it didn't count if it wasn't done in Walldorf.

At the time, SAP seemed very close-minded about everything. So for SAP, this is a true paradigm shift, where they truly accept the fact that they are just one of the sources of information the enterprise needs. Not only that, SAP has taken it upon themselves to develop business connectors or translation tools - "messaging interfaces" more accurately describes what they actually do - in order to communicate seamlessly with other systems and platforms. On top of that, SAP is also taking into consideration their IS or industry solutions endeavors and integrating them into the portal infrastructure as well.

So not only will you have this portal tailored so that it will read SAP out of the box, but now you can pop in anything from Oracle Financials to Siebel. There are actually three or four other major third party applications being supported now, and don't forget this is a continuing and ongoing process. SAP hopes to bring in the different ERP enterprise data systems, supply chain systems, CRM apps, and also product lifecycle management. At any rate, SAP decided to make all those diverse applications available through SAP Enterprise Portals. In doing so, they have had to leave behind what had been their basic bread and butter - ABAP-coded applications. Quite honestly, I don't ever see ABAP really going away, but SAP's technology is changing. With Portals, if you're trying to integrate a product from somebody else - something like Oracle Financials or Siebel - then ABAP isn't going to do you any good. So SAP's decided that J2EE is the methodology that they will use and support. They have joined the standards committees on Java, XML, SOAP; and now that Microsoft finally seems to be getting something marketable under the .NET platform, SAP's going to bring them into the portal fold too.

Reed: Pat, that's a major shift in SAP's enterprise approach.

McCarthy: That's right. Just three years ago, SAP was basically saying, "If it's not SAP, it's not worth talking about." Now they're saying, "Hey, we're just one of the kids in the family, but we're the big brother, so we'll help you talk to the little kids if you're having trouble." And that's what SAP Enterprise Portals is all about. Portals is essentially a methodology of bringing diverse data from different data sources to the end-user, in a format that is easily usable by that end-user. So what we're talking about here are web pages, spreadsheets, small desktop-type database systems - you never know where the data might come from. It might even come from your PIM. Portals brings together the information from wherever you need it. For example, Act 3 may be providing you with the customer's name and address, but the whole business account - what the customer owes you, what his payment terms are, what his credit level is - might be in your SAP system. And if you want to assess the kinds of products the customer is currently buying, you might get some of your details from your CRM system.

Leaving behind the customer data for a minute, you might also need to access your own benefits data through a PeopleSoft HR package. All of the data you need to access throughout your workday is now visible through the SAP Enterprise Portals desktop. So the data in Portals comes from a vast array of different applications, but SAP has even taken it one step further. They've stepped up to the plate and said, "Hey look, up until now, everyone has been pointing their fingers and saying, ‘It's the other guy's fault.' But if you put in our Portal and give us a shot at it, we'll take all the complaints - it's our fault, period. Just put it in the Portal, tell us what you need, and if we don't have it, we'll get it."

Reed: That's pretty amazing for a company that wasn't always thrilled about helping a customer modify their SAP infrastructure with data from other applications.

McCarthy: SAP has been very pro-active about that. If a customer calls SAP and says, "Hey, I've got such and such a program, and it's Cobol, and it was written in 1972 and it does just exactly what we want it to," instead of sending a salesman out there to talk the customer into dumping their Cobol program, ripping out everything else, and replacing it all with SAP, now they can say, "Hang on a sec, let me put you over to development." Then you get a systems analyst from SAP on the phone who says, "Hi, what does this program look like and where do you want it to go?" Bingo, Business Connector starts to form and that's where SAP sees a lot of their new business going. That in turn picks up and sparks the services end of their business, which has not always been the big moneymaker for SAP in the past. Now they're recognizing their own services division. They are also bringing in their strategic partners and saying, "You know, there are only so many things in the world we can do, and then we just run out of bandwidth. Even us." Which must have been hard for those guys in Walldorf to own up to. :) But it is what it is, and so they have a lot of different partners who can help them.

So not everything that SAP comes out with will be developed by SAP. A lot of times, they'll be developed by other people who SAP takes and rewards in other ways for allowing them to take it and add it in. So that's the basic idea of what an SAP Enterprise Portal is. An SAP Enterprise Portal is a second-generation portal that pulls in the data from across the whole enterprise. Now, I know that the marketing folks at SAP will tell you that you don't need to have SAP installed to use SAP Enterprise Portals. That is a very, very true statement. But as for the likelihood of that happening, I just don't know. It would seem strange that you'd be talking to an SAP salesman to buy an Portal if you weren't running SAP inside your company at one place or another. However, with all of their worldwide installations, SAP has a real big market in their own install base, and many of these companies are open to this Portal solution. Even if they're not able to sell Portals to non-SAP customers, I think it's going to work out well for them.

Reed: So what are the other factors that are fueling the Portal market?

McCarthy: The second item to "Why Portals, and Why Now?" has to do with the business atmosphere. Portals ships with the licenses. So it's not like you have to buy any new software to install it. When you buy a license, you get SAP Enterprise Portals, and SAP Web Application Server - you get your new plug-ins discs, and you're ready to go. SAP upgrades this stuff quarterly, and all those elements are upgraded, so it's not like you're buying anything new if you want those upgrades. So when you install Portals, you're basically taking what you're already paying your licensing fees for and utilizing it more fully. That is what sells in today's business market. The classic sales tactic of "Buy new, rip out and replace" - this isn't the right time in the business cycle for that approach.

However, making the best use of what you have - now you're talking about something that people will spend some money on. People will pay for technical expertise to make use of things they have already purchased. Especially because Portals is not a back-end service; more than just IT departments are going to see it. In fact, the main people who are going to see it and use it are the end-users. And from my experience, when they see it, they say, "Ohhhh....." Portals gets their attention, it's easy to use and you catch on very quickly. Of course, the next thing they usually say is "By the way, I'd really like to..." which I know is every programmer's worst phrase - but it leads to more engaged end-users and better utilization of the tools that the SAP customer has purchased. People have bought them, and they need to put them to use.

As an industry, we are going through a paradigm shift. It used to be that sales were the center of everybody's universe, or ERP was. Right now, it's the information itself, and that means databases... it's a great time to be a DBA. The information that a company has is now a tactical weapon they use to make and generate revenue. People are looking at it more and more that way, and IT is coming through for sales, for manufacturing and for accounting - for everybody, with products that actually work. These products can give the user a means to differentiate themselves from their competitors through information technology. So that's where the whole industry's going. SAP and Hasso, thank you very much, I appreciate it... I really didn't want to learn another new IT environment. :) But they've recognized this trend, and they're taking SAP in that direction. They've come to a point now where they're not just taking that direction, they're leading the way. So the king of "Do it my way, or forget it," is now the king of the open standard. 
SAP's Enterprise Portal Strategy and its Impact on SAP Consultants
Part Two
September 15, 2002

In part two of the interview, we pick up where we left off with our discussion of how SAP's technology is evolving. In his comments, Pat starts to address the issue of how "traditional" SAP consultants will fare as SAP becomes an "Internet company." Pat also gives us some specific examples of how SAP Portals is enabling greater productivity. He also explains just how SAP Portals and Web Application Server fit into the current R/3 release schedule. Perhaps the most fascinating aspect of this week's discussion is Pat's description of how third party applications like Oracle and Siebel can be seamlessly accessed on the Portals desktop.

Jon Reed: SAP has reclaimed the mindshare lead in their space.

Pat McCarthy:
They really have.

When you think about it, for a number of years, SAP was really in more of a reactive mode.

Yes they were. Right after Y2K, a lot of people were writing SAP off. Being an independent consultant, I was kind of worried about that. I was wondering: "Where are they going from here, and where should I start jumping into next?" As an independent, I worry, "Is SAP going to maintain," but also I say, "OK, they're going to maintain, but where should I be going with my skills, so I can make the optimum amount of dollars and have the most project opportunities?" People who do SD, MM, FI, CO, and ABAP will always have a job. But they will not be the highest paid consultants any longer. Folks that can take and handle the new mySAP applications - "New Dimensions" they were first called, now we think of them as mySAP - that's where SAP is going. All these new integration products with a small "i" in front of it and SAP at the end - that's what I'm keeping an eye on.

SAP is looking to turn itself into an Internet company, the kind that works - the kind that actually has a battle plan and legs to stand on. The legs are the financials, the customer relationships and enough money in the bank so that they don't worry about making Friday's payday - something which my SAP friends in San Jose are still worried about. I tell them, "Stick with SAP, dudes, and you'll still work out ok" - that's just the way this whole industry is going. People want answers, and they want them now. I go to my clients with a SONY sub-notebook, those little thin ones, and when I carry it in, people look at me like I'm becoming a dinosaur. We now have Palms and Windows CE systems, and as much as they may look like they come from the Toys ‘R Us Adult Division, these are powerful tools. Recently, I was in a car with an SAP salesman on the way to a client site, and he had one of those little CEs. The information he was able to get off of that CE about the client we were heading to see was astounding.

When you mentioned a few minutes ago of how information can impact revenue, now you're adding some teeth to that. Your CE story is a crystal clear example of how that's happening. There you are on your way to your client, and some guy in your car has a little hand-held thing that looks like a little toy, and yet he's able to look up valuable client information that's going to help you sell the appropriate service to that client.

McCarthy: This was not a demo unit; this was what every single SAP salesperson had. I was impressed. For someone who has been doing this for thirty-some odd years, it takes a bit to impress me. So that's the idea behind SAP Enterprise Portals. As in all things SAP, it's not just the software. It's also a business process re-engineering effort. So the new business methodologies need to go in. With ERP, SAP was dictating to the company what the new business methodology would be. With mySAP, the companies are dictating to SAP what they want to see, and SAP is saying, "Gotcha! Let us make it come together for you." And they're making it happen. And it's not just SAP's data. It's everybody's. SAP has a good sense of both the short and the mid-term of this particular industry. Long term - five to ten years out, I don't know. I have yet to really see anybody take their Palm Pilots to Jupiter or Europa and plug into one of the microbes down there, but as fast as this world has changed in the last ten years - and change has been exponential - who knows what it's going to be like ten years from now.

Reed: Have you had the opportunity to see Enterprise Portals at work? As you know, you get all this very impressive literature from SAP, but people really want to see this stuff in action - and so do I. The more companies understand that this technology is not just marketing, but really delivers some immediate benefit, the more momentum the market is going to gain. Tell us what you've actually seen out there as far as Enterprise Portals is concerned.

McCarthy: Enterprise Portals, SEM, and Web Application Server is where I've devoted most of my energies the last eighteen months or so. I started out with one of SAP's main consulting partners, and we did a proof of concept on Portals, Business Warehouse, and other objects. My particular specialty was SAP Enterprise Portals, Web Application Server, and SEM, and the EAI technology behind that. I happen to really enjoy EAI and connecting the data from different back end systems. What I have seen is this: number one, SAP Enterprise Portals is an adjunct to your current SAP solution. It's not like you have to stop doing what you're doing, you just have to add it on top. There's not a big bang rollout of this stuff.

Reed: Now do you have to be running on a current version of SAP to take advantage of SAP Enterprise Portals - say version 4.0 or higher?

McCarthy: To take real advantage of Portals, you need to be on at least 4.6B or greater, with the 4.6D kernel installed. The truth of the matter is that you won't get full use of your portals until you bring in Web Application Server 6.2. Once you get into the 6.x series, Web Application Server and Portals were meant to work together as a singular engine.

Reed: And that, essentially, replaces your core R/3 technology engine.

It replaces Basis, yes. In R/3 Enterprise, which is what the core Financials are now being called, the FI and other core modules come as PIs, or plug ins, and they're stand-alone plug-ins.

Reed: That's revolutionary.

McCarthy: It is. The base engine used to be FI/CO. If you were going to put in any of R/3, you had to at least put in FI/CO and then go from there. Now the base engine is the Enterprise Portal. However, after they put the Portal up, one of the first things you're going to find people doing is putting in BW. BW is the backbone engine that will define the Portal and pull the data for what it's doing. So it's come around in a circle. It now appears that the primary application is going to turn out to be web-centric and OLAP-based. So here we go - we're going to have a lot of fun when we're doing it! Like I said, the core financials are plug-ins, and as long as your financials are poured on 4.6B with a D kernel or higher, you can put in Web Application Server 6.2 along with the SAP Enterprise Portal , and the data just melds right into it. It just lays right over the top. Web Application Server 6.1 had a few problems. I am so thrilled to say that I have tested 6.2, and I have yet to find a problem in 6.1 they didn't find and fix. It now lives up to what it's supposed to be doing. Before, this, SAP Enterprise Portals was Workplace 2.11C, running on Basis technology. Workplace no longer exists - your single-sign-in, your security kernels, all of that is now part of your SAP Enterprise Portal.

Reed: How do you see SAP Basis folks faring with all this new mySAP technology?

For you Basis folks out there, your direction in life is pretty well set. You better start looking into Enterprise Portals, get your feet wet on network programming, and start learning about messaging. And when I say "messaging," I don't mean emails. I mean MQ Series, Tibco, iWay, Vitria - there's a whole bunch of them out there. SAP being SAP, they support all of them, so what else is new? For Basis people, that's where the biggest change is going to be. Anytime you move beyond 4.6C, Basis as we know it, sort of goes away - at that point, it's the Portal that supports the database. So your database layer, the DBSL, still exists, it's just part of the SAP Web Application Server and Portal infrastructure.

It's interesting to note that on the functional side, HR people are probably the furthest ahead. They started out with Employee Self-Service. That particular area, right now, with 6.2 and the SAP Enterprise Portal, is totally integrated into the Internet from start to finish. Even you're the accounting people no longer need the SAP Windows GUI. In terms of SAP's industry solutions, the energy and utilities solutions like CCS and IS-Oil are probably the most integrated into mySAP at this point, but the rest of them are coming on pretty fast. Just yesterday I got a bunch of new CDs from SAP, and it looks like Retail is the next industry area that SAP is going to go for as a "total Portal rollout."

You can see how the whole SAP world is just kind of shifting. People want the answers while they're on the road. People don't always work nine to five anymore. As far as offices go, it's becoming less and less that your salespeople actually visit the office more than several times a year - usually they just check in to pick up supplies. Otherwise, they're out there working. HR departments have cut way back on the number of head counts they need. Your supervisor takes and approves the hours you need on ESS, and it goes from there to the accountants. Remember all those payroll clerks you used to have? You don't use them anymore. They're mostly being automated into something else. This is what we always wanted the systems to be, where one computer talks to the other computer. That is what Portals is all about - having one computer talk to another computer, and having the end result go to the people.

Reed: And we're talking about Enterprise Portal version 5.0, the one that's available now, which is a replacement for mySAP Workplace 2.11.

McCarthy: That's correct.

And it terms of Enterprise Portal 5.0, have you seen that these so-called "plug and play" connectors with third party systems from other vendors actually work as advertised?

McCarthy: Yes they do, although in the Portals world, they call it "drag and drop."

And you can do it "out of the box," without a bunch of ABAP guys doing custom programming in the back room?

McCarthy: Yep.

That must be incredible to see.

It is. With Portals, people actually can take and create their own reports with their own data sets. The end-user probably isn't going to know where the data is stored and they really don't care. They shouldn't have to care. I have seen Portals work with Siebel firsthand, because my friend Dion, who's a lead technical guy from Siebel, came over and we just tacked it on to see how well Portals worked using Siebel data. And it's just perfect. It's easier to work with SAP and Siebel via the Portal than it is to work with SAP's own CRM program without the Portal.

Reed: Wow.

One of the third party applications that SAP is touting right now, in terms of its close integration with Portals, is Oracle Financials. I've seen it with my own two eyes, and I can tell you that SAP Enterprise Portals uses Oracle Financials just like it was SAP. A lot of us in SAP are very prejudiced against Oracle Financials, because we've been around it since it first started and they've yet to get a bug-free version of it out there, but no matter, SAP literally takes an Oracle Financials setup and treats it just like it was an SAP setup. It is that easy to do and that easy to read. All the business connectors, everything you think you might need, it's already done.

Reed: That's so cool!

McCarthy: Now remember, over time, many more business connectors are coming. The last two we just talked about - Siebel and Oracle - are already here. They're available on SAP's web site for download - you just download them and go. There's very little custom programming that needs to be done. Most of the custom programming that needs to be done has to do with formatting, things like changing the header page so its says "my business" instead of SAP AG in the title of the headers. Or you may need to do a bit of formatting if you want to have a Microsoft PowerPoint presentation instead of a spreadsheet. Whatever you have in mind, you can have. The second-to-last job I finished was for a very large film company. This company is just now getting ready to go live, so they're going to hold of on the Web Application Server and Portals for a little while. They've made a commitment to stay with SAP 4.6 until after the "go live," because this new stuff came out while they were in the middle of implementing, and they just need to get a system going first. That makes a lot of sense to me.

But the reason I'm bringing it up is because the interconnectivity issues can create an EAI nightmare that Portals can really help you with. This client used to have 147 different accounting resource packages. They now have 39, 38 of which are not SAP. From my point of view, this situation has more to do with corporate politics than it does with actual functionality. But they're stuck with those 38 for now, and that's a lot of corporate data. Well, between MQ Series, Tibco and iWay, they had a 15 person programming staff that spent six months doing the messaging interfacing, just so that all of those systems could talk with SAP and they could send all the data back. With SAP Enterprise Portals, and the business connectors that come with it, all you'd need would be two or three people spending maybe three to six months on the project.

Just think about it: the next move up in SAP is going to take you from 15 people for six months to two to three people working three months. That is some serious money, because these EAI people do not come cheap. I just happened to be in the right place at the right time to be able to get that kind of firsthand knowledge. One of this company's competitors decided to go the Web Application Server route instead, and I also worked with them, and that's why I know it takes two to three people about three months to do it. And that company was up and live within that timeframe, and what's more, they had a lot of fun doing it.
SAP's Enterprise Portal Strategy and its Impact on SAP Consultants
Part Three
September 29, 2002

In part three of the interview, we begin by asking Pat to describe the different "legs" of the Portal infrastructure in detail. Pat explains how Portals integrates both structured and unstructured data, and he tells us how SAP's Knowledge Warehouse fit into the Portals picture. In the last part of this section, we discuss how Basis and ABAP skills fit into a Portals implementation.

Jon Reed:
Let's give people a sense of the different kinds of information Enterprise Portals brings together for you. The way I understand it, SAP talks about four different "legs" of information. So Portals is not only about integrating all the third party applications that you and I talked about. SAP describes the four legs in this manner: the first leg is the application integration leg we've been talking about, and the second is structured data integration, what they call Business Intelligence, which to my understanding is primarily BW-based information. The third leg is unstructured data integration, drawn from the SAP Knowledge Warehouse knowledge management solution, and the fourth leg is integrated Internet-based content from Yahoo and other outside business partners, which provides users with access to real-time industry news and information. Is that all correct?

Pat McCarthy: Absolutely. We call that last "leg" the Extranet. To take a closer look at each, you have to start by asking, "What makes a portal a portal?" What you were talking about is exactly what makes SAP Enterprise Portals what it is right now. First of all, each SAP Enterprise Portal takes structured data. Structured data doesn't have to be SAP. It can be anything out there - Oracle Applications is structured data. But "structured data" means it's database driven data. SAP Enterprise Portals can also take unstructured data. Unstructured data can be a wide variety of things. Quite often, what I see in unstructured data are blueprints, drawings, engineering specs - these types of files. These are files that exist alone on the system as a file. They are not imported into the database as a blob, they just exist.

The next thing that SAP brings in are third party applications - we've already talked that one to death. The last thing that SAP can bring in is other Intranet and Extranet data - and the Extranet is the important part - it's not just Yahoo. Let's say I'm in a hardware retail store business. I would also be going out to Warehouser, which supplies my wood, and other relevant Internet sites for my industry. Through the Portal, you can access those external sites and bring all that information together. And here's where we have true collaboration, it's called CDO, or Collaboration Data Objects. The CDOs pull information from your suppliers and the people you supply into the Portal.

So this gives us a framework which allows us to use Portals from the start of the manufacturing process when the raw material comes out of the ground, and we're able to track that process all the way up to the time it becomes the fender that goes onto the car that's going to the car dealership that someone's going to buy it from. From there, we can still track that car through all of its servicing visits, inspections and such, through a third party program. This is where it will wind up with SAP Enterprise Portals. Are we there yet? Not quite. Are we making strides? We sure are. That's the whole idea behind what we're doing here. ‘Product Lifecycle Management (PLM) is not just the stuff that you happen to have on hand in the warehouse, or something that a manufacturer happens to manufacture. It is the complete history from birth to actual death, until they finally melt that car down to scrap and it's indistinguishable from all the rest of the tin cans and they make something else out of it. So this is a full methodology we can use to track the entire product lifecycle.

Reed: You have mentioned that HR is one department that can truly benefit from Portals.

McCarthy: When it comes to people, HR is now able to track all of their people through SAP Enterprise Portals. To be honest with you, HR always was able to do that. But now people are able to see what HR is tracking. HR always wanted them to know, it just wasn't very easy. You had to go to a seminar or something and ask your HR rep, "Now, what is this benefit all about, and what is that benefit?" Now, you go home, you bring up your browser, you click on your company's Intranet, and they're offering you a smorgasbord type benefit package where you pick out what you want, and you can select one of three different employee retirement programs - all from home. If you need more details before you make your choice, all you have to do is just click and call up your online HR training. It takes you straight into the course to teach you what it's all about. This can be handled on a person's own level on their own time.

We're picking on HR quite a bit, but I do know that in my family, when we talk about things like benefits, it's not just me that decides what's going to happen - there's my wife and a number of others who are also looking at the benefits. I also know what she gets, and we want to maximize the amount of benefits that the family gets without too much overlap. So this Portals technology makes it easier for the ordinary working person to get a handle on their benefits, to pick and choose, and to do it right.

Reed: Tell us more about Knowledge Warehouse and unstructured data.

McCarthy: The Knowledge Warehouse that goes with this whole area is not just SAP's KW solution. These days, SAP's Knowledge Warehouse is the database that brings together historical knowledge - we call it ‘tribal knowledge' in the development world. Basically, it's everything that's known within the enterprise, all brought together in one place. Some of it will be SAP-related, you can get those on DVDs and it's called content, but other content will come from other areas. We're not talking about sitting through a six hour course to get down to the five minutes of what you wanted to know anymore. We're talking about being able to go into the Knowledge Warehouse, blow off the stuff you don't want, and get what you need from the comfort of your own home, making the best decisions for your family. So we're getting to a point now where we are empowering the actual end-user with information technology. That's the big thing that SAP wants to stress, that they are empowering the end-user to use data. Not just the elite, or the accounts receivable department, or business managers. We're driving this down to the person who takes and works the night shift on the assembly line.

Reed: That's a powerful step if SAP can fulfill it. Before we move on, can you summarize what we have in our Portals system?

McCarthy: Here's what we've got: we've got document repositories, or unstructured data, and we have SAP applications - and that's both mySAP and SAP. As you add new SAP apps, they will automatically interface into the Portal because part of the "plug in" is the Portal interface. You don't have to worry about it. You don't have to rewrite anything, and it won't bother anything else. You can bring these apps up a piece at a time, as you get to them. There's no big rush to Big Bang it anymore. Then there are third party applications. And the fourth is Web Service - your Extranet of suppliers, your competitors maybe, who knows? Today's competitor is tomorrow's strategic partner. And then you have what I like to call the public knowledge providers, folks like Yahoo. I know that Yahoo is one that SAP promotes a lot, but it really doesn't matter who it is. Basically, it's whoever has the information that you want. You're just bringing it into the Portal from a resource that's publicly available without having to go and dig it out.

So those are the five areas that the Portal is based on supplying. You usually see SAP listing them as four legs, because they take web services, which would be the Extranet Portals to other companies, and they take the publicly available information, and just group those two categories into one, because you access it the same way. I make the distinction between the two because some of the Extranet data is not available to everybody in the company. For example, when you're talking about having access to your suppliers, there has to be some security on there. I contrast that with information that is publicly available to anybody - in other words, anyone who has an Internet browser and can go find it on the Internet someplace. Even though it's the same type of data, the security on it would be rather different.

Reed: So when we talk about SAP Enterprise Portals consulting opportunities and how SAP technology is changing, it's pretty clear what's in store for Basis folks. Many Basis people will find themselves on customer sites where they're transitioning this technology, and if all goes well, they'll be able to make that technology transition with their customer. But on the ABAP side, it gets a little more interesting. Would you recommend that ABAP programmers look to acquire new skills such as Java and XML in order to be more effective on these new mySAP and Portals installations?

McCarthy: The answer to that is yes, and now I want to spell it out a little bit. First of all, I know there are a lot of people out there who are very good at FI/CO, and very good at MM and other functional areas. Those skills will always be needed. But anyone who has worked with SAP knows that the one thing you can count on in business is change. Things change. And SAP itself is now changing. Take the Web Application Server - one of its primary functionalities is to take ABAP-written objects and turn them into net data, so it can be used by the Portal. In that sense, ABAP programmers will always be useful. However, SAP itself is branching out from just ERP. ERP and ABAP are hand-in-glove. If you're going to follow SAP into the new frontier, you're going to need something else besides ABAP.

I have the good fortune of being part of Tom Schluser's testing and evaluation team for the "JCo" connector that SAP now takes and remarkets from Arasoft. In the process, I've gotten a bird's eye view of the EAI technology SAP is adopting. If you're a classic ABAPer, Java, XML, and SOAP are good places to start. I would look at those three areas very quickly, and I would start getting skills in those technologies. You're going to find out that this new stuff is not all that different than ABAP. The terminology might mean something slightly different, but in terms of the way things actually work, ABAP isn't a language that was created twenty years ago and died. ABAP is continually evolving, and you're going to find that a lot of what's been going on in the rest of the world has already been incorporated into ABAP. So as you go to learn Java or XML, you're going to find that it's not that hard to learn.

Reed: Because ABAP has already gone through a lot of object-oriented enhancements already.

McCarthy: That's right. ABAP programmers are going to go to Java training and say, "Oh, I see, I just have to take this block of code and reformat it slightly differently, and use the Java compiler, and I get it!" and the answer is "Yes, you sure did."

Reed: So as someone who has seen mySAP implementations in action, your recommendation to ABAP programmers is to take a pro-active step to learn some of these new web development methodologies, in order to strengthen their ability to contribute on these new mySAP projects and make the transition.

McCarthy: Correct. Your marketability goes way up. And this isn't just SAP going one way by itself - this is the entire industry going this way. "Dotcom" was an industry direction. The Internet bubble burst, but it doesn't mean the industry stopped going in that direction. The dotcom folks got us onto the Internet. Most of the dotcoms didn't work out too well, but it doesn't mean the industry isn't going that way. If you're going be a consultant, you better know this stuff. If you're going to be a team lead in your corporation, now is this time to start learning.

You don't want to be caught by surprise when the sales guys in your division asks IT, "Hey guys, I just saw this wireless CRM app that one of my competitors was using, and I could really use something like that. Can we have this yesterday?" That is not the time to learn a new programming language. Being pro-active is always the right idea. With SAP people, it's usually not that hard because we're kind of used to it. When SAP first came out and most of us joined, it wasn't a legacy system, and for many of us, that meant a big change to client-server. We're used to change, and that's the way it goes.

SAP's Enterprise Portal Strategy and its Impact on SAP Consultants
Part Four
October 13, 2002

In part four of the interview, we get into the nitty gritty of the functional work involved in Enterprise Portals projects. Pat tells us why he sees Portals as primarily a functional undertaking, and he gives us a specific view of how functional and technical skills fit into the Portals landscape. Pat also explains the significance of BW skills, functional and technical, to Portals implementations. We end this section of the interview with thoughts on how BW and Portals is fulfilling the vision of the "corporate information factory."

Jon Reed: Do you see functional roles for people on Portal projects, or is it primarily a technical undertaking?

Pat McCarthy: Actually, I see it primarily as a functional undertaking. I know that sounds crazy, but remember, once you get off the four pillars we talked about, then you get into three main repository areas. First is the Unification Server. "Unification" is where all of the functionality that was SAP and whatever programs you were running before - they're now all part of the unification aspect of this program. In other words, you're taking all the data from Oracle, the data from MM, the data from your Project Management app, the data from FI/CO. This all goes into the Unification Server, because remember, the end-user is drag and drop. He just takes a token and drops it on a blank piece of paper where he wants the results to show up.

So you're really talking about leveraging a lot of functional information here - that's why I don't see Enterprise Portals as primarily technical. Another example of the functional side of Portals is all the knowledge management data we talked about. Everything that your industry knows about itself, everything that your corporation knows about itself - that's all part of the knowledge management services. Well, that's not going to change. Yes, we're putting on a new Portals front end so that everybody could get to access to it, but we still had to have a knowledge management system.

To take another example, the people who were writing all the help desk screens and everything else for SD were SD people. Well, I've got news for you: Basis guys aren't going to take over and start doing that. And think about BW. Business Intelligence services is the third main repository. This is where all the data from within your business gets stored permanently. And all the functional BW people are already involved in this work. So I see Portals as a functionally-driven area, because your Portal users are going to say "Can you do this for me?" and it's going to be a function, it's going to be something they want done. Basis people are going to be moving from strictly Basis and DBA work into setting up the Portals and doing the interconnects - the EAIs, the messaging systems, to get the data from other areas.

So you're bringing more system administration knowledge into Basis than we used to have before. But they won't be taking over those functional tasks by any stretch. They're going to have enough on their plates already - security and Basis is also going to become huge. I see security breaking out of being a function of Basis and becoming a major function all by itself. Finally, to make Portals work, there's a whole new group of people you need who I call the dotcommers - they're the people who know how to present all of this information in an Internet environment, using skills like Java, XML, and DHTML. That's where your ABAP programmers who are trying to reinvent themselves might get in. Anyway, that's how I look at it.

Reed: So you can't look at a Portals install as a purely technical endeavor. You're really drawing on a lot of classic business functional areas - you're just bringing them into one unified environment.

McCarthy: And we're adding a third element to this architecture - the web aspect - that usually wasn't part of an SAP project. It's not to say that it wasn't there all the time anyway, it just wasn't part of the SAP side.

Reed: But in terms of installing Portals itself, there isn't functional work along the lines of your classic configuration scenario like you have in the FI module, where you're actually going in and configuring tables. That's not really part of a Portals implementation per se.

McCarthy: No it's not, but that work still has to exist in all the areas you need to draw your data from.

Reed: It still has to happen in order for the Portal to function.

McCarthy: Correct.

Reed: So there are functional opportunities that play into virtually all the functional areas of SAP, because you're essentially supporting the Portal infrastructure no matter what you're doing at that point.

McCarthy: That's right. Now remember that the data we're getting from places other than SAP is going to wind up in BW, in the Business Warehouse. There are an awful lot of functional people, and also a lot of programmers, who are involved in Business Warehouse. That's not going to change.

Reed: So is BW integral to all Portals implementations in that sense?

McCarthy: Yes it is.

Reed: So you can't really talk about a successful Portal implementation that's not closely tied to BW.

McCarthy: It depends on how you want to define your Portal. Remember that I told you it's not a Big Bang approach anymore. Not all the Portal functionality has to go out all at once. Case in point: just a few days ago, I was on the phone with a previous client. They're bringing up the SAP Solution Manager, and they are also going to bring up Enterprise Portals and the Web Application Server to go with their Solution Manager. That's all they're doing right now. There's no BW in this; there's none of the other functionality of the Portals being used just yet. But it will be, eventually. For each company, there will be one driving reason they come up with that says, "For this, we need to have a Portal."

Reed: There will have to be a business reason, but once they go with Portals, they will be pulling data out of a BW system.

McCarthy: Yes, BW plays a role in all this. In particular, the ODS is going to be much more prominent than it has been in the past.

Reed: That's good news for BW people.

McCarthy: Yes it is, as a matter of fact.

Reed: It positions them well in the emerging enterprise of the future.

McCarthy: Like I said, this is a great time in life to be a DBA.

Reed: And since there's a lot of work on the functional side for people in BW, there's a clear role that functional people can play in the Portals rollout.

McCarthy: That's right. There are always InfoCubes. These InfoCubes have to be populated, and you have to populate them from MM, or FI, or any other area you can think of. Plus, now BW also involves all this stuff you would never have normally thought of, because that info is not part of SAP. BW will now handle the data from third party applications as well. This is where Business Warehouse itself is going to really come into its own. It really is going to be a repository for the tribal knowledge of the enterprise. And that's the whole idea behind the Corporate Information Factory.

Reed: When Bill Inmon, "the father of data warehousing," coined that term, would he have ever thought that SAP might someday be able to deliver on the Corporate Information Factory concept and make it a reality? Perhaps in a proprietary way, his original dream is coming true.

McCarthy: It is. It's been a long time coming, and it took a lot of things to get there from here. I started out this life as a programmer with Teradata, writing basic core primitive kernels for business warehouses. That is what we had in mind in the first place. But you sell people what they want to buy... it's finally gotten around to a point where this is what they want to buy.
SAP's Enterprise Portal Strategy and its Impact on SAP Consultants
Part Five
October 27, 2002

In part five of the interview, Pat clears up some of the misconceptions about the evolution of Enterprise Portals and tells us what happened to the SAP Markets/SAP Portals initiatives. Then, we ask Pat to explain why this new technology hasn't taken hold yet on project sites. This leads into a great discussion of Pat's own skills evolution as an SAP consultant and where he sees himself heading in the future.

Jon Reed: A lot has changed for Enterprise Portals in a short amount of time. As recently as January of this year, we had SAP Portals and SAP Markets functioning as two independent subsidiaries of SAP AG. And then, over the course of the spring, SAP Portals and SAP Markets combined forces, and later they were acquired by SAP, back into the parent company. I think we all understand how Portals is doing under the current configuration, but what happened to SAP Markets? What happened to that functionality?

Pat McCarthy: That functionality is now what's beginning to show up with Portals and Web Application Server 6.2. Remember how I told you that version 6.1 had a lot of problems? Well, when they combined the Markets people with the Portals people, then they had enough knowledge of the industry to tackle and resolve those problems. The reason both groups were put together is because Portals was going the same direction as Markets. The only difference is that SAP Markets was set up to create public marketplaces and exchanges, whereas Portals are private exchanges.

The concept of the public exchange didn't really come to fruition the way a lot of folks thought it was going to. But the idea of a private exchange, i.e. me and the other companies that I work with, has caught on. In Japan it's called a Kuritsu, but it's basically just a whole group of companies all working together with a common goal to produce a common thing. The automobile example is the best way to think about it, that's why I used it earlier. By the time you put that key into your new automobile and drive off, it's probably been worked on by several thousand people. Maybe, by almost that many companies. When it got right down to it, the technology to run either public or private marketplaces was basically the same.

But SAP Markets has expertise needed by the Portals group. Think about it - a public portal had to be able to draw information from sources outside of SAP. When Enterprise Portals first started out in generation one, all it could do was just draw SAP information data into itself and give a new user-friendly presentation. But by combining Markets and Portals, we now have the security of a private exchange with the robustness of a public data environment to draw from. So essentially they were both heading down the same path and almost all of the tools that they needed were redundant. The market itself decided which one was going to live and which one wasn't. Like I said before, "Thank you very much Hasso, you and the executive committee, I'm sure glad you got this one right, because I really wasn't looking forward to learning something else, at least not right now." :)

Reed: So you saw the impact of SAP Markets on the latest releases of the Web Application Server and Enterprise Portals?

McCarthy: Enterprise Portals was also part of the Web Application Server in 6.1, but it wasn't very well defined. When you go to 6.2 - why they called it 6.2 and not 7.0 I don't know - you see a massive change. And that's the impact of SAP Markets. In 6.1, the idea behind the application server was to build mostly first generation functionality, i.e. an ability to take ABAP code and publish it onto an HTML page. Generation Two is the ability to take data, information, and code from any place, and publish it in XML, DHTML, SOAP, .NET, etc. There's about a dozen different formats in all. But that is the difference between Generation One and Generation Two. By combining both Marketplace and Portals together into one, SAP found that they had the knowledge and the manpower to get a second generation portal to market in a very short time. And that's what happened.

Reed: So are we going to see customers jumping all over this?

McCarthy: I opened up DICE yesterday, went to their search page and put down "SAP Enterprise Portals," and found 67 different openings. It's just been the last few weeks or so that things have picked up like this. When you and I first talked, about six weeks ago, I went out on DICE and there were only two or three jobs. Then yesterday I thought to myself, "OK, I'll check it out again and see how bad things really are," but when I saw 67 jobs out there, I thought, "Oh man, things are really picking up." This is SAP's future. The future always starts slower and then builds up steam. The people who are in it now are in at the very beginning. A birth is a very traumatic thing to have to go through, so the people who are in it now are taking a lot of the battering that's going on, but they are also the ones who are in the best position when this really does take off.

Quite frankly, I think it's more of a matter of business climate than anything technology-wise. After all, people have to have money to buy things, and right about now, folks are just trying to hold on to their employees, and I don't fault them for that; it's a challenging time. However, for all of the SAP readers out there who have seen SAP's sales for the last two quarters, don't worry about it - all it means is that new stuff isn't being sold. There's still an awful lot of stuff people have already bought that needs to get implemented. Don't worry about the sales projection figures. It's rough on salesmen, but as far as the technical and functional people go, we shouldn't see a further letdown at this point - it should just be about the same as it is now.

Reed: And what's next for your skills? Where are you going from here? Are you going to position yourself with Portals and see where your skills evolve?

McCarthy: I'm looking to position myself with Enterprise Portals and two other high level areas in SAP, SEM and PLM. What I'm looking to do is to position myself for market research and strategic enterprise planning, and I'm looking to web-enable those areas. More and more of what we call "the web" is becoming part of a common business structure, just as much as your PBX machine is part of your telephone, and nobody would think about opening up a business without a telephone. Pretty soon, we'll all need to have an Internet/Extranet/Intranet setup, with appropriate security to protect its data - that's where I see this all going. Data is going to become a required "buy-in" for any start up of any business or business unit. All this knowledge is going in the same way - if you don't have a knowledge bank, you're not going to be in business, or even if you start, you won't be in the game for very long.

Three months ago, it seemed like I was so far ahead of everybody. You couldn't find an SEM or a PLM or a Portals gig anywhere. But as I said, on DICE, there were now 67 of them. All of a sudden, I'm starting to see SEM and PLM show up too. The world is changing for those of us who are consultants and programmer/analysts and things like that. After reading through your articles at, I see that you're taking people and you're leading them into where SAP's new direction is going. But what's interesting is that this is the first time we've actually stopped at something that was an actual thing, a real working product, not just a direction. You were talking about EAI recently, and before that you were talking about BW with Naeem Hashmi. But reading Naeem, he wasn't telling you how to do it, as much as he was telling you how BW was evolving. Now this technology is really starting to deliver in a tangible way.

Reed: You got kind of involved in EBP for a while, have you moved on now?

McCarthy: EBP is part of supply chain management, an area where many seasoned consultants are moving. For me to keep the work coming as an independent, and to keep my rates up, I need to go into a field that is not overrun with a lot of technical experts. EBP, SCM, and CRM is what SAP is now pushing, and they're also becoming part of the mainstream. And anything mainstream means I'm out there competing with the big consulting firms and SAP itself - whereas if I go into Portals, SEM, and PLM, there's a much smaller pool of talent to tap into. It keeps me busy longer, and it keeps my rates up. But you have a copy of my resume, and you'll notice that lately I've been doing all kinds of strange stuff that isn't exactly in my focus area. Sometimes you just have to take a project just to make the mortgage payment.

We're at the very beginning of this era in SAP's evolution and this market is still new. When I said that sometimes birth can be a painful experience, it is. I'd love to be out there doing Portals work and nothing else, but there's not that much of it out there just yet. It's the future, it's the near-term future, but it's not quite there. For most consultants, my advice is: don't get caught doing what everybody else is doing. ABAP programmers, even before Y2K, were down to $60 an hour in some cases, and that wasn't very good. This stuff is bleeding edge, it's just starting, and that's why I'm moving in that direction. It doesn't mean I can't do EBP, it doesn't mean that I won't, but if I don't have to I won't.

Reed: You're just trying to stay one step ahead, and that makes a lot of sense.

McCarthy: For me, Basis lasted from 1993 almost to Y2K. After Y2K, BW and APO started to get hot and I got hot with them, but they already have more people in the market than the market wants right now in those areas. With Portals coming out, BW is making a dramatic change, so that area is now being reinvigorated. What I'm telling you is just my methodology of trying to stay ahead. Where's it going to next from here? I don't know. I know I'm not going to give up my subscription to SAP Insider or SAP Professional. :) I'm going to keep my ears to the wall at every event I go to.

SAP's Enterprise Portal Strategy and its Impact on SAP Consultants
Part Six
November 10, 2002

In part six, the final part of our interview, Pat gives us his take on SAP's small/mid-market strategy, and how Portals might provide a breakthrough and create some new consulting opportunities there. We wrap up the interview with a few more comments about the SAP consulting market in transition, and how Pat has kept his focus on mySAP despite the economic adversities SAP consultants are facing.

Jon Reed: Before our interview, you were telling me about how Portals might help SAP move into the smaller to mid-market. Tell our readers more about that.

Pat McCarthy: So far, SAP's penetration of the small and medium-sized business market has been minimal. But with Portals, you can now finally componentize all SAP modules. This has all happened pretty quickly. As recently as December 2001, if you bought mySAP you got all the modules. If you bought R/3, you got all of them. You may have only wanted FI/CO, but you still had to pay licenses for all of them. Pricing software can get pretty tricky. Software has an intrinsic price, mostly because once it's written, it's written. But here's the issue SAP has been facing: they can't take their $5 million dollar R/3 Enterprise Edition that they've been making and start selling it for $10,000, because all their Fortune 1000 clients are going to kill them. So componentizing the apps is a real smart methodology on their part. By breaking their stuff up, it's not nearly so noticeable that they're dropping prices dramatically in certain areas to go after different markets.

Reed: Because you only sold the company a piece of the puzzle, you avoid the pricing controversy. And now you can legitimately go after people outside your install base, and target companies that didn't want to buy the whole product suite and couldn't have afforded it at any rate. And that addresses one of the biggest concerns about SAP - winning new customers. They've weathered the storms pretty well, but primarily by selling new services and upgrades to their existing install base. At some point, you have to go out there, expand your market, and win new customers.

McCarthy: That's true, but remember now, SAP's current client base is all in the Fortune 1000 - they're the big boys. And they have a lot of smaller companies feeding them.

Reed: So then you go after the food chain.

McCarthy: That's right. I've been very active with Daimler-Chrysler. And Daimler-Chrysler is just pushing SAP on down, they're telling their suppliers, "Hey look, our software's SAP, we don't have time to integrate your data, you've got to get on an SAP system. Your machine's got to talk to our machine. You can either talk to SAP, or we'll find another supplier." And their downstream suppliers, the smaller companies who are making these little parts - they don't have ten million dollars to toss off on SAP right now because that's a whole year's earnings. That company needs to have a more affordable SAP product so he can feed that information back up. It might end up being repackaged with having a different name, but it will be SAP for the small people. And that way, you don't alienate your large customer base and you can go after your small customers.

Reed: As long as Microsoft doesn't get in the way with their Great Plains initiative.

McCarthy: Well, I have an idea that Billy G has every intention of doing exactly that.

Reed: It's funny this has come up, because recently someone was talking with me about breaking into SAP FI. I ended up answering their question in my Q&A column on Right before I talked with you, I was telling them, "If you want to get into financial applications consulting, don't limit yourself to SAP, where you'll be going up against a strong base of very seasoned consultants. SAP is still an option, but there are others options to consider - for example, Microsoft just acquired Great Plains, and there may be some very interesting opportunities there."

McCarthy: There will be some extreme opportunities, because remember, these large companies are going to push their suppliers on application integration, and the vendors are going to go after that business. Sooner or later, you're going to get down to the ten to twenty person organizations as you go down the food chain. There are an awful lot of small companies out there, so if you're going to really expand your market, then that's where SAP needs to go. This is one way of doing it. Componentize SAP, maybe give it a somewhat different name, and legitimize it in the marketplace.

Reed: We've always wondered if SAP could go that far down market. Pat, I think you're right, with the new componentization and web-enabled product line; we're finally going to find out. They'll finally have a product that can compete in the small to mid-markets. It's going to be a war, but it will be interesting.

McCarthy: It will be very interesting. The other nice part is that it's potentially a whole new career area for consultants. These smaller companies will not be able to afford their own full time SAP staff, and in most cases, they're not going to need it, because it won't require that much change. Consultants like us will go in, and in two or three months we'll have them all set up, and then we'll be moving on out. We'll go back and see them again in six months or a year when they bring in something else. I have clients like that right now. It's gonna be a whole lot different than what we're used to, but I think it's going to be a lot of fun. We'll have to wait and see. In the meantime, there are an awful lot of SAP people out there who are seriously lost. And I was even second-guessing myself until I ran across your web site. It's kind of nice to know you're not alone in your thinking about where SAP is going.

Reed: It's a pivotal time in the market. There are some SAP folks with their heads down, just scrambling for projects and making the best of the rates they can find. But then there are other people like yourself who are stepping back and saying, "I'm going to look at the reasons why things have been tight, figure out what's going to move us out of this phase, and aggressively pursue those skills." That's really what our web site is all about, because we feel like the mySAP product line, though it hasn't truly taken hold yet, is still the way forward.

McCarthy: That's why a lot of the functional people in FI/CO, MM, and some of the others are having trouble right now. A lot of the core modules are in place. Now companies are looking to leverage that. They're saying, "I already bought this, why didn't I ever put this together or try this functionality?" Then, all you have to do is pay someone like me to help you teach your staff how to put in what you're already paying these monster license fees for each year. This makes sense in two ways: companies are now getting more bang for their buck, and two, one of the biggest complaints about ERP is that it always costs so much, yet you tend to use so little of it. Well, now you're using more and more and more. And as that happens, the IT guy isn't under such a big shadow when he's out there fighting for his department budget, because he's not saying "I need to buy something new" anymore. He can now say, "We already bought it, we need this money to get it installed for you." And from what I can see, folks are willing to do that.

Reed: That's the beauty of SAP's current sales pitch. You're going back to companies that spent all this money on ERP. They're starting to think that they wasted all that money on ERP, or at best, overspent, but now you're saying, "Listen, you're in the perfect position to leverage the infrastructure you already put in, so let's go." It's a great pitch - it's the right pitch at the right time - now let's see some market activity!

McCarthy: Yes, that would be great. But remember, it doesn't all come down to SAP's sales. If more people just start putting in what they already own and paid for, the consulting market will get a boost.

Reed: Pat, thanks for the great view of where SAP is going and how consultants can move towards the Enterprise Portals area.

McCarthy: No problem, I enjoyed it very much.

Post-Interview Update: Pat McCarthy Checks in from Overseas
November 17, 2002

Original editor's note: Since our Portals interview took place, Pat has continued to monitor the market and the themes he raised in the interview. Recently, we got an email from Pat, who is currently in Europe wrapping up another Portals project. Pat had a few promising thoughts on where SAP is headed that he wanted to pass along to us. When I told Pat that some readers might find his views a bit optimistic, given the nature of the SAP market in the states, Pat made an important point: the work is out there, but you have to be willing to go to where it is. So if Pat is optimistic, he is also realistic, and he's willing to travel far to keep his skills on the cutting edge. Nevertheless, even if SAP doesn't enter another "Golden Age," as Pat predicts, there's no question that he is pointing us to the major areas of technical innovation within SAP - areas that all SAP consultants should be keeping an eye on. - Jon Reed

Since the time you and I did this interview a few significant items in our field have come into play:

- Along with the ‘Componentizing' of SAP, MySAP and Enterprise R/3 Financials, SAP AG has purchased a viable SMB ERP vender "Business One" (see the end of my interview about ‘Componentizing SAP'), and is in the process of releasing it to the Middle Market (200-500 employee enterprises). They have put "Business Connectors" (hooks) into every level of Business One so that Business One and SAP work together in the same manner that one SAP organization would transfer data to another. I have not yet seen this in action, but have heard from many current SAP enterprise customers that SAP now has its feet firmly planted on the "Yellow Brick Road." One will have to contact SAP to get pricing, but the initial release is on a W2K or XP Platform with an MS SQL database back-end. How much of this code is really original Business One, and how much is really SAP R/3, I don't know, but I'm looking forward to getting involved on one of these projects and seeing how things really work out.

- SAP Portals has really taken off. I receive three to four inquiries a week on my availability to help put this in. My latest contract with SAP Portals and SEM is coming to an end (about mid December), and WAS 6.2 really lived up to all of its expectations, and in my opinion surpassed most. Now the monster: KW (Knowledge Warehouse) works as advertised, out of the box. I truly believe that the next ‘Golden Age' of SAP is upon us.

- Mr. Hasso Plattner has stated his intention to step down from active leadership at SAP, and his replacement, in fact the entire new SAP executive team, all appear to have grown up ‘NET. The next few years are going to be fun, challenging and fulfilling. Anyone out there ready for the next ‘Amusement Part' ride? Remember, ‘Please keep you arms and hands inside the vehicle and seat belts securely tightened at all times.'

See y'all down the road, and remember; "Don't stop reading and dreaming" or your journey is over.

Pat McCarthy Jr.

Should I Pursue Enterprise Portals?
A Reader (and ABAPer) Writes In
September 23, 2002

After the second installment of our interview with Pat McCarthy, we received an email from a reader regarding careers in Enterprise Portals (EP). Pat was kind enough to share a few thoughts about making the transition from ABAP work to EP consulting. They have both agreed to share this exchange with our readers. It is great to see so many consultants taking active steps to retool their skills for the SAP market of the future. - Jon Reed

Hello Pat,

Your interview with Jon on Enterprise Portals (EP) was simply superb. The information you provided was very informative.

My name is Siva, and I have been doing ABAP for the last 7 years. I've been involved on the integration side using BAPI, RFCs, CrossWorlds and Business Connector. But I do not have much exposure to the Java/JavaScript/.NET world. Now, I have the opportunity to retool myself either on SAP-SCM or the SAP-EP side. I am really excited about Enterprise Portals but I am bit worried about Internet programming skills using Java/JavaScript/.NET. Is it wise for a ABAP tools person to enter into EP? Would you please provide me the valuable advise on which way I should plan my career? Your help will be much appreciated.

Thank you, Siva

Dear Siva,

You've given me a few hints on your current background, but nothing really about what you LIKE doing. That said, let's look at your background. I'm going to make a few assumptions and I might be far off the mark, but you can always write me back with corrections and we can go still farther from there.

1) You have 7 years of SAP ABAP programming, hence, you're pretty well entrenched in SAP business processes and you understand fairly thoroughly what SAP is really all about.

2) You're not a typical ABAP "Report Generator," you've been involved on the integration side using BAPI, RFC's, CrossWorlds and Business Connector.

3) You have an opportunity coming up to retool, and get ahead of the market needs.

4) You are either working for someone who can afford (or at least you can afford) to invest some time and $$$ (we ARE talking about SAP here).

5) Your mind set is recognizing the need to ‘evolve' (latest I heard, general ABAP was headed down towards $30 an hour).

6) You view Supply Chain Management (SCM) and Enterprise Portals (EP) as two different tracks (not necessarily so).

7) Drawing from my background (DBA OLAP databases, teradata and networking), I kind of understand your dilemma.

OK, lets assume that I have all the pertinent data, and have properly understood it. No matter which of these two niches you decided upon (SCM or EP 5/6) your world is undergoing a dramatic change. To keep yourself competitive you have to change too (a great book on this is Who Moved My Cheese. Not long ago, I read it on a trip back to the East Coast). In terms of SAP-specific change issues, you should check out Brian Trout's overview of where SAP consultants go from here. The direct link is You might also want to check out Sue White's web site at HYPERLINK "" . Sue is an SAP project manager and executive coach who has some good ideas about managing change in an ERP setting.

Back to your email... you wrote that you've "...been involved in the integration side using BAPI, RFC's, CrossWorlds and Business Connector." That's a pretty clear statement that if you enjoy what you are doing, then EP is a natural avenue of evolution for you. The SAP WEB AS has two primary functions: the ability to publish ABAP coded programs into an Internet environment and the "Unification" of data from "SAP foreign" data sources (J2EE et al...). As far as the semantic differences between ABAP and J2EE are concerned, it is merely a matter of translating (mapping) your low-level analysis into another hi-level code base. The abilities, thought processes and functionality are the same, only the "terminology" has changed. Sooner or later, you will have to "follow your cheese," and get into J2EE, or MS Studio, or WebSphere et al.

Therefore, what really comes out of this is, "Do I like what I'm doing?" If the answer is YES, then you're a natural for EP. Visit the Serebra web site at, and for $39.00 (I think that program is still available), you get a four course interactive tutorial that takes includes "Enterprise Java Beans (course FC1011)," "Advanced Java Concepts" (FC1012)," "Networking with Java (FC1013)," and "Using Java Foundation Classes (FC 1013)." During your next "gig," you should run into enough "XML" to have a heads-up on where and how to use it (data mapping +...). XML and Java are two key skills that come into play on EP projects. Know this: very few (and I mean few) experts exist in EP, so the pressure may not be quite as intense as everyone learns together. Just remember to stay five minutes ahead of everyone else on your project, hence no pay-per-view in the hotel at night, time for "homework" to keep ahead.

If, on the other hand, your answer about what you're doing is, "I do it to pay the bills, but I would much rather....." then it's time for change and SCM is a lot different in approach to EP. In that case, you need to find a ‘guru' in that area and talk to them about what they perceive as the future in BW/APO/SCM, and how you might fit in there.

Good luck and stay in touch!

Pat McCarthy
Editor's note: Based on this information, Siva has indeed decided to pursue a skills transition into Enterprise Portals. We wish him luck and we'll keep you posted on how he fares.
How Portals is Changing the SAP Market:
An Update from Portals Expert Pat McCarthy
May 10, 2004

The Portals market is not for the slow-footed. Since our initial interview with Pat McCarthy, Portals consulting has evolved from niche area to a skill that touches on many different areas of the SAP product line. Since we last heard from him, Pat has put a number of additional Portals projects under his belt. When he saw our "Hot SAP Skills for 2004" feature, Pat was compelled to update our readers on how he sees Portals impacting SAP consultants, and the overall changes he sees in the SAP consulting market. As usual, Pat's advice comes with strong opinions and practical tips regarding the trends SAP consultants should keep an eye on. What follows is Pat's initial letter to Jon and our newsletter readers, followed by Jon's response to the points Pat raised in his letter. Taken together, this back-and-forth exchange gives a good sense of how Portals consulting has evolved, and what lies ahead for SAP consultants in terms of Portals skills and opportunities.

It's been a whole year since we last reviewed Portals possibilities. For me it was a good year. 2003 seemed to be the year of the "Pilot Projects" and sandboxes with EP5. I had four contracts - each about 90 days in length. These sandbox projects are a great way for Basis and ABAP'ers to break into SAP Portals. These projects are not long and the number of changes that SAP made during the year (from SP2 to SP6) was astounding in its increased range. Each of those Service Packs could have legitimately been its own release from any company other than SAP. There is still quite a bit of this going on, but the Portals emphasis is on EP6 now, which is a other "whole new product." It would not be my choice of where to break into SAP Portals. I advise aspiring Portals consultants to try to find some EP5 projects if they can, and get the look and feel of Portals there before pursuing EP6 opportunities.

I noticed that one of your regulars who wrote into is a bit like me - always pursuing the latest knowledge until my eyes glaze over for the night. Night time is the time I spend in my hotel room doing my own "test developing" and self-education to stay ahead of the curve. By bringing new insights into work each morning, I usually leave the client with a bit more than originally promised. This approach helps me stay ahead of the game, and it builds a solid network of people that are referenceable and even a few that have called back to see if I would lead the team as they go forward.

2004 appears to be the year of companies getting really serious about putting in Portals (mostly EP6 SP2 and SP3) corporate wide. These are six month plus contracts that typically have more than one Portals person on the team. The Portals niche has grown and it's no longer possible to have just one Portals consultant and 1-2 client personnel part time to have a successful project. It is also decision time for us Portals consultants: are you going to be - as SAP has labeled us - technical (which means installation, some JAVA, XML, JCo, and middleware, SAP Integration Server, etc.) or "functional" (which involves developing custom iViews, and typically requires strong ABAP with BW background, and the SAP R/3 knowledge to access the data sources and turn out custom BSPs. Pretty good Java is also needed for these "functional" Portals roles, though you can forget about .NET skills. SAP sure has.) From my perspective, just about every discipline in SAP is going to have to be Java savvy and Internet-knowledgeable. If that is not in your plans, I'd say do yourself a favor and get out of SAP. 

For those readers who are surprised by how I've defined "functional" and "technical" here, it's important to understand how SAP has defined Portals consulting roles. SAP has grouped SAP Portals people into two different groups. The technical group is what most people are familiar with in relation to Portals. These folks are typically ex-Basis and/or SAP DBA types, along with some adventurous ABAP'ers. These "technical" Portals people do the installations and set up the pre-configured BSPs supplied by SAP (very little custom programming is possible using these pre-configured models).

With the serious debut of WAS (especially WAS 6.40), the "functional" Portals role comes into play. These are Portals roles where business process and content knowledge in FI/CO, MM, APO, SEM, HR, etc. comes into play. For people in those current functional skills/disciplines, just knowing what you know now will not be enough to keep up with the new SAP. These traditionally functional disciplines are going to have to acquire "Internet skills," some Java and XML, as well as some basic programming expertise. Fairly soon, I see the architecture of CI App servers and dialog servers being supplanted by Web Application Servers. I know that this sounds like "Much ado about nothing" until you get into doing it. Then you find it's a whole new ballgame.

While I'm on the subject of rapidly changing SAP technology, the SAP ITS architecture also appears not long for this world. Most of the ITS functionality is already in WAS 6.40, and I expect that when we actually get to WAS 7.x, there will be no more ITS. Somewhere around this point, the "client/server" architecture in its truest sense will give way to an "Integrated Web Services" architecture. This has to happen to get SAP out of the CIO's department and into the entire company. One doesn't have to be a prophet to see this already happening. Look for this to happen everywhere, sooner much more likely than later.

Getting back to the opportunities in Portals consulting, make no mistake about it, the era of the One Person SAP Portal team is OVER!!! I don't know how I can emphasis this more. SAP sales just now seems to be catching on to the power of their product; as for the end-users, they have been their waiting for us to catch up. My advice for consultants is simple: if a project you are on or going to has anything to do with SAP Portals, get yourself involved! I don't know of any Portals consultants out there now that (1) wouldn't appreciate the help, and (2) aren't more than willing to teach anyone who is serious and who wants to learn.

The future I see is for Portals to permeate the whole SAP architecture so thoroughly that simply being an SAP Portals person is not going to be enough to get you hired to do anything. Find your niche in the Portals process and develop it. Do it sooner rather than later. Case in point: because I have Portals experience (especially EP6), my next project, which is 6 months long, will pay $36K more that it would have without the Portals experience. In a perfect world, where we all work 12 months every year, that is a $72K difference in billable rates.

Also, I refuse to take an "all in" contract where I am responsible for expenses. To my astonishment, that has not cost me a single opportunity - everyone agrees to my rate + expenses quote. (We still have to be reasonable here, my next contract is in EMEA at a place I've always wanted to visit. It's literally 24 hours in the air and airport time, but I still have to travel Economy class. And when I get there, they are going to put me up in my own apartment, but I have several choices and the final selection is mine.)

That brings up the last point: GO WHERE THE WORK IS... Don't wait for it to come to a neighborhood close to you, nothing new is coming that fast. I did have three choices this time around, two in the US and two with a Tier One consulting company. I did take the Tier One consulting company, but took their overseas one because I wanted a bit of a change of scenery (my wife plans to visit me instead of my coming home each month, so how much I might net on this contract depends on her I imagine).

Lastly, there is a "night and day" difference between EP5 and EP6. Truly that much. Jon, in the coming months, I look forward to sharing my thoughts with your readers as I compare a typical EP5 design and installation with the new EP6 project that I'm going on. I'm not one for SAP certifications being of much importance, but I did pop $3250.00 for the TZTEP6 course from SAP academy, and it was worth every penny. If you get a chance and you have EP5 experience (they won't take you if you don't - I had to provide references) this one is worth the $$$$. Beginning in September, they will have the EP 6 version 101 for clients and people new to SAP Portals, so keep in touch with Waltham for the time and places for the latest classes. Good luck out there everyone!

Very best regards:

Pat McCarthy Jr.


Dear Pat,

Thanks for that Portals update. You've done a great job forecasting the types of opportunities in the Portals consulting space. Not to mention your provocative comments about the future of functional SAP consulting!

I must say that I agree with quite a lot of what you have to say here. The only thing I would say is that not all SAP users seem to be on the same "fast track to EP6." Some SAP users seem like they're ready to pursue the transition from client-server to web server aggressively, and some seem more determined to get results from the current production environment and not change until they are darned good and ready.

Of course, the danger for consultants is that they can get lulled into a false sense of security by projects that pay well but don't advance their technical or functional skills. I know several consultants on long-term 4.1 and 4.5 projects. These projects pay well, but they're a one way ticket to skills obscurity. Consultants are well advised to heed your advice and seek out projects where new SAP releases and Internet-based initiatives are in full swing - even if it means taking a hit on rate, or, as you have pointed out, traveling far and wide to get to the right kind of work.

I'm not sure I totally agree that SAP functional folks are going to need to be programmers in order to survive. But I will meet you halfway, because I have heard from a number of insiders that functional SAP roles ARE becoming more technical and technical SAP roles are requiring more functional knowledge. Certainly, functional consultants who ignore all the architectural changes brought on by NetWeaver and Web Application Server are in for a rough ride. And your comments also hint at something I have noticed: when it comes to Portals consulting, I think we are seeing two separate things: First, distinct Portals consulting roles are emerging, with their own skills characteristics and attributes. Second, Portals work is becoming integrated into a range of functional areas across the SAP and mySAP product line. Kind of like BW.

Portals is becoming one of those SAP "mega-skills" that just about every consultant is going to need to be aware of, because sooner or later, their functional niche is going to be affected by Portals innovations. We have already seen Portals have a very strong impact on FI, SEM, HR, and CRM, to name just a few. Of course, this creates new skills challenges for functional consultants, but as you've pointed out, new technologies also create new opportunities.

Along those lines, one thing that surprised me was learning more about custom Portals development. You didn't mention this in your letter, but I've started to make contact with some consultants who are specializing NOT in installing the pre-configured Portals setup, but helping clients to customize their Portals environment. Our new Enterprise Portals editor at SAPtips ( is a good example of this new kind of Portals development. He is finding a niche helping SAP users develop their own Portals apps. For example, he recently helped a client develop a custom benefits program using EP5 (they didn't want to use SAP's standard Portals benefits app).

Evidently, this is very interesting work that involves the use of the PDK (Portals Development Kit), iViews, Java, and lots of J2EE-based and "open source" types of programming methodologies. These "custom Portals developers" seem to have strong ABAP and Java backgrounds, and are enjoying the chance to push their programming skills into the Internet age but stay inside of the SAP environment. Anyhow, you didn't really mention pure programming roles either in your initial Portals interview or in your follow-up, but it does seem that there may be some Portals opportunities for hardcore SAP developers that are ideally suited for them, that won't require competing with Basis and DBA folks for project roles that aren't as relevant to their backgrounds.

We'll have to keep on eye on these trends, but from where I can see, it seems like Portals is creating new consulting opportunities for almost every type of SAP consultant, and as you've rightly argued, the opportunities come with an edge: if you don't pursue them, you might find yourself out of work sooner rather than later. It's taken a lot longer than we thought, but the web-based and web-enabled applications are here to stay in corporate environments, and the Portal looks like the user interface of choice for all these next generation applications.

It looks to me like you've found (knock on wood) one of the "sweet spots" in SAP consulting for the next couple of years. Of course, you know all too well that you're only as good as your last project, and I have to take my hat off to you for your willingness to do "whatever it takes" to stay current, even if it means traveling to distant locations with huge SAP books packed into your carry-on. One thing you haven't shared with our readers is that you always try to keep a current development environment handy on your own computers. The story you told me about installing EP5 on your laptop was an adventure all in itself, and while I know that cost you some long nights, I hope readers understand that it's that kind of over-the-top effort that has kept you in the game and where you want to be.

Thanks as always for sharing your honest take on the market with the community.

Keep us posted as the market evolves!

Jon Reed

2008 update: We hope you enjoyed this look back at the evolution of the Enterprise Portals market. We'll continue to update readers on Portals consulting opportunities and how to position yourself for the NetWeaver Portals era.