Microsoft recently revealed to us details of its SAP R/3 implementation, showing one extreme in the approach to Microsoft-SAP interoperability. Other recent conversations with SAP and Microsoft customers have shown us the other extreme. Most companies will find the best approach lies somewhere between.
The Bottom Line: For companies with strategic investments in SAP and Microsoft, choosing a portal framework will be less a question of which, and more about which role each plays, where to draw boundaries between them, and how they work together to improve enterprise performance.
The Microsoft-centric portal
Like more than a few SAP customers, Microsoft didn't find SAP's interfaces usable for its broader masses of users, so it employed its own applications and technologies. It used SharePoint Products and Technologies and Office as the primary interface, as well as the office productivity and collaboration platforms, and used Web Parts to offer more personalized access for the masses of SAP users.
While roughly 2,000 hardcore R/3 users use the SAP Graphical User Interface (GUI), those that interact with SAP applications less frequently have simple, contextual views into the system through SharePoint Portal Server (SPS). Microsoft has essentially made SAP invisible to most of its employees.
Of course, Microsoft is a special case as an SAP customer. Obviously it's going to focus on .NET, capitalizing on its own expertise, and emphasizing the role of its own products over others. But the example is still instructive for two reasons:
- It shows us one extreme of a combined Microsoft-SAP portal framework. In this case, SPS carries the role of portal as much as possible in conjunction with other Microsoft servers used as the framework to access and work with the SAP information.
- It tells us a little more about the background of joint efforts between Microsoft and SAP. This stuff has been developed at Microsoft and at SAP with their own massive implementations. They've recognized and acted upon their own need for crucial systems to work together, and they've started to package their experience in Project Mendocino, a portal Software Development Kit (SDK), and similar initiatives.
The SAP-centric portal
Conversely to the Microsoft example, many companies have placed the stronger emphasis on SAP Enterprise Portal. SAP acts as the primary portal infrastructure—as a kind of Über-portal that accesses or aggregates SharePoint team sites and Microsoft collaboration and Office tools within the framework.
A few companies even use the SAP's portal in general purpose office productivity and collaboration roles—Microsoft's typical sweet spot. We spoke recently with Nordzucker, the 1.3B euro sugar producer based in Germany, which has embraced SAP Enterprise Portal's document management, collaboration, and search capabilities to improve employee productivity. Nordzucker has found SAP Enterprise Portal 6.0 is well up to this task and has drawn the line with Microsoft at Office and Outlook/Exchange.
Find the SAP-Microsoft balance
Most SAP-Microsoft customers we talk to are choosing a path midway between the Microsoft and Nordzucker examples. Most want to employ SPS as the general-purpose portal, allowing people to work with the less structured content and the less formalized or automated processes, while SAP manages and delivers the more structured information and the more automated processes, often in the context of business applications.
Microsoft tends to operate in a distributed fashion, while SAP is usually highly centralized. Ultimately they must complement each other, not compete for attention.
Understand how their core competencies support yours
At a recent AMR Research SAP Best Practices Forum event, when an open discussion on unified portal frameworks became preoccupied with Microsoft and SAP, I asked the group of 40 IT executives if any other vendor mattered to them in this space. Heads shook across the room.
For their parts, Microsoft and SAP have acknowledged each other's presence, no longer insisting on absolute rule in places where they're mutually present and irreplaceable. Acknowledging each other is working greatly in their favor, in effect locking other vendors out and adding to their mutual business opportunities.
Mendocino and the Portal SDK are ways to ease the integration between NetWeaver and .NET—from a developer and end-user point of view—in the portal interface. While these joint efforts will offer relief, companies still have higher level architectural and business questions to ponder:
- Does Microsoft become the general-purpose platform, while you limit the need for more specialized SAP development expertise? On the other hand, will you adopt NetWeaver as the primary infrastructure for your business as a means of extending and controlling core business processes?
- Like businesses all over, despite their breadth and aspirations to grow their already massive businesses, Microsoft and SAP must pursue strategies rooted in core competency. How are they likely to move forward to support your strategy?
- How will impending developments from both companies affect your architectural and business decisions today? For example, Microsoft's Longhorn will make some aspects of knowledge management part of every users' working environment. As a result, companies all over the world will be compelled to revisit investments they're making now.
All materials copyright © 2004 of the AMR Research Inc.
AMR Research, Inc. is a source of analysis and advice for executives responsible for delivering performance enhancement and cost savings aided by technology. AMR Research aggregates best practices from leading global companies and provides tailored, actionable advice and research reports to every client. More information is available at www.amrresearch.com.