Expand +



Ensure Your Portal's Staying Power

by Rizwan Uqaili

August 11, 2009

Thoughtful planning is essential for achieving and maintaining a strategic, cost-effective portal landscape. Use this portal implementation guide not just for your initial landscape but on an ongoing basis to manage your landscape design. You'll save time, money, and effort by anticipating future needs.

My experience in designing landscapes for SAP Enterprise Portal (SAP EP) implementations has taught me an important rule of portal landscape design: The best way to keep pace with unavoidable, exponential portal growth without significant cost, rework, and production interruptions is to base your landscape design on a deliberate growth strategy. To succeed at that, you need to analyze and anticipate your needs, understand your options and their potential effects, and design a strategic landscape that will keep pace with your growth and expanding requirements. In this article, I show you how to identify your requirements, and I present options to consider as you design your portal landscape. This kind of thoughtful planning is essential for achieving and maintaining a strategic, cost-effective landscape for today and tomorrow.

If your company is like most companies, you are feeling pressure to get your portal up and running quickly. Resist that pressure! Excessive speed will yield a short-term landscape design that you'll outgrow in six to 12 months. For example, one team I worked with initially optimized the landscape's network placement for use by only a few departments. Within six months, however, the landscape had to be redesigned to accommodate enterprise-wide access. Another team's initial portal landscape was designed only for internal employee access, which resulted in significant changes and increased costs when they needed to push content out over the Internet to customers.

Nail Down Your Portal Landscape Requirements

Determining the most strategic initial landscape can be tricky because there are many requirements to keep track of, most of which can have a significant effect on the "best" design for your implementation. Fortunately, I've found a three-step process that simplifies the task. You can use this three-step process on an ongoing basis to manage your landscape design, not just for your initial landscape.

First, estimate your current requirements, and then estimate what they will be at six-month intervals for up to two to three years from now. This process is illustrated as steps 1.0 – 1.4 in the portal implementation guide shown below. The key options for each of steps 1.0 – 1.4 are shown below.

The goal is to capture independent requirement sets at staggered points in time that clearly show how your portal would be enhanced over time. This could be done by listing all potential portal requirements, prioritizing them, and then breaking them up into manageable implementation phases.

Next, design a strategic landscape for each set of requirements (steps 2.0 – 2.2 in the portal implementation guide). (Note that the remaining steps (3.0 – 4.4) are included in the guide for your reference; those implementation details, however, are outside the scope of this article, which focuses on the planning process.) Finally, determine the least costly (and least painful) path that connects them (see "Which Way to Face" ).

As illustrated, the goal is to minimize the overall upgrade cost, impact, and effort estimates. Essentially, you're balancing the costs of meeting future requirements today (and the risk that your requirements might change before you reach this future need) with the cost, rework, and delays associated with implementing them later.

Portal implementation guide for SAP EP

The Important Questions

While this approach will take more time, designing iteratively with a realistic plan for the future will yield sustained success that bypasses many of the growing pains (and redesign costs) experienced by IT teams that design based purely on today's requirements. With this in mind, let's discuss each requirement area in more detail. There are five questions you should ask yourself. (These questions map to steps 1.0 – 1.4; the key options for each step are labeled 1 through 5 in the diagram of critical requirement options shown below.)

1. What types of applications and content will your portal offer?

While you need not (and most likely cannot) predict all of the applications your portal will host, it's important to identify the types of applications you'll run in order to effectively plan your infrastructure.

Column 1 lists several common application types. Ask your functional team members to assemble some rough functional phase-in plans, and take a preliminary look at such components as Knowledge Management, Collaboration, and Unification. As you'll learn, the design and cost of your SAP EP infrastructure - more so than with any other SAP system - will be heavily driven by these requirements, so identifying your team's current requirements and anticipating future needs are arguably your most important steps.

2. What technical requirements will the applications in the portal have?

You need to ascertain the underlying software components, hardware, and network bandwidth the applications in the portal will require. Be sure to document requirements for each of the items in column 2 for each set of applications you want to run on your portal.

Five critical requirement areas to consider for your landscape design

3. From where will users need to access the portal?

Will end users need to access the portal from the company intranet only or from the Internet as well? From which locations, domains, and network segments? Do you need to change your network layout or place extra portal servers in different geographic locations or network segments? As you might imagine, end-user access is a critical driver of your overall portal topology (and its cost!).

In general, your access requirements are not a matter of choice but of business necessity, i.e., what you can afford. From a cost and complexity standpoint, you have three categories of access options: inward-facing portals, outward-facing portals, and dual-facing portals. See "Which Way to Face?" (below) for a discussion of each category.

4. What level of availability will your users need or expect?

While your initial set of users may be able to handle downtime for upgrades or maintenance at night or on weekends, sooner or later you'll probably have to support 24/7 availability. Some organizations need to support users in disparate time zones; each may allow downtime "at night," but one user's night is another's day. For others, 24/7 support becomes relevant when the portal gains enough popularity and trust to deploy mission-critical applications. Those who use the portal only as a point solution, however - to give a handful of vendors access to an ERP report or to let employees enter travel expenses, for example - may not need to invest time and resources in high availability.

Your goal is to identify the risks, impacts, and costs and to balance the cost of failure with the cost of prevention. A good way to create this balance is to develop service-level targets for each component or feature of your portal landscape and align them with their business impact.

Determine the most strategic initial landscape through upgrade estimates

5. What will your approach to security be?

You need to make decisions about security in four major areas:

  • Authenticating users
  • Allowing users to self-register
  • Securing system-to-system communications
  • Implementing single sign-on

With the exception of self-registration, changing your security approach after going live can be extremely costly. You must make your decisions carefully and be prepared to live with your choices for several years.

Additional Landscape Design Requirements

Other important questions to ask yourself when considering your portal design requirements include the following:

  • What will your custom development strategy be? Willyou develop custom portal iViews as ABAP transactions, JavaServer Pages (JSPs), or Web Dynpro for Java, for example? Will you migrate your existing J2EE and .NET/ASP applications to run on your new portal infrastructure? (.NET/ASP applications can be hosted on your portal server only if it is running on Microsoft Windows and has Microsoft IIS running in parallel to the portal Web server.) Also, will you try to minimize custom development, or will you encourage the specialization of applications for use in the portal? SAP EP offers a specialized, J2EE-based runtime capable of running "portal components" written in Java using either the Portal Development Kit (PDK) in SAP EP 5.0 - 6.0 SP2 or in SAP NetWeaver Developer Studio as of SAP EP 6.0 SP3. Both development tools are available at Your decision to use ABAP, Java, or .NET will depend in large part on your in-house skills and administration experience.
  • What is your administration strategy? Will you provide delegated administration? SAP EP 6.0 offers several ways to set up the portal maintenance structure for post–go-live support. For example, you can define separate administrators for your internal and external portals. Maximum flexibility in terms of accessing the Portal Content Catalog is also possible by using the Access Control Lists that can define who has what level of access to what content in the portal. What this means is that the SAP EP folder structure can accurately reflect the organizational structure it is meant to support.
  • What languages does your system need to support? You may need to install additional plug-ins on yourback-end systems to support extra languages through your portal. Consult your system vendor for morespecific requirements.
  • What will be your promote-to-production strategy? The SAP EP portal administration tool provides technical tools for importing and exporting portal content. You will have to set up some internal structures and processes, however, to ensure that the transports are completed and tracked without confusion or overlap (e.g., hand-off procedures, an end-to-end transport guideline document).
  • How will you upgrade, patch, and scale your system without affecting existing users? SAP is constantly working on its products, so updates will become available at regular intervals. How will you evaluate, test, and install these updates without negatively affecting production users? This requires a multi-system landscape, typically with development, QA, and production instances with clearly defined transport procedures. How will you advise users of new functionality or fixes? This is typically done via a prompt on the users' home page. Will your plan include the ability to restore your portal, unification, and Knowledge Management systems to an earlier state using a backup? This requires establishing a backup strategy for the SAP EP landscape or using an existing backup strategy. Establishing appropriate patching, upgrade, and recovery processes early and identifying the tools you'll need to support them will help you avoid costly mistakes made by those who don't. Remember, all of these issues are a matter of paying a little now or paying a whole lot more later!

The Future Is Now

SAP EP is becoming a critical piece of an SAP technology landscape, and portals will soon become as ubiquitous and indispensable as email. Thus, it's essential that portal implementation teams design their initial portal landscape for rapid, unexpected growth, even if their initial plans include only a single division running a single application.

Another reason for a carefully considered initial implementation is that portal landscape design involves several decisions that can be costly to change after going live. For example, if you change your mind about where to store user authentication information (e.g., from LDAP to a database), it may require significant rework to change that approach after the fact.

I've outlined for you the most important requirements you need to define: identifying the applications you'll run and their underlying requirements and user accessibility and availability needs. I've also highlighted some important considerations such as development, administration, and promote-to-production strategies. The most important point for you to remember, however, is that it's never too late to follow these guidelines.

Which Way to Face?

Inward-facing portals are the least costly and require the least hardware and know-how, primarily because fewer precautions have to be taken from a security perspective. Most companies start with this type of portal to gain experience managing portal landscapes and creating and managing content. Inward-facing portals are easy to outgrow, however, and companies that take this approach should have a quick and cost-effective plan for moving to portal access over the Internet. If you have mobile or remote employees with dedicated computers, or employees who work from home and need portal access, providing access to your portal via a virtual private network (VPN) over the Internet is by far the cheapest, simplest, and safest solution. Plus, a VPN facilitates user access to other systems such as file and print servers natively, as if they were in the office, so it is a much more flexible solution than selectively Internet-enabling individual applications.

Outward-facing portals are the next most costly since they involve setting up a permanent public link between the Internet and your internal landscape. They remain relatively simple in that they don't need to be accessed simultaneously by internal users. Companies that need to quickly push out reports or other content to customers or vendors often choose this type of access as their starting point, usually to catch up to competitors that already offer an extranet of some type. Where you place your servers in this scenario can have a big impact on your long-term cost.

Dual-facing portals are the most complex and costly landscapes to set up and support.

A dual-facing portal is your only option, however, if you need to permit access by both internal employees and external individuals for whom you do not want to have VPN access to your internal network, such as customers, vendors, or retired employees who need to update their address information or benefits enrollment options, for example. It's also your only option if you have users who may need to access enterprise data from PCs on which a VPN client can't be permanently installed - e.g., a mobile salesperson using a customer's onsite PC to quickly pull up a sales report. He or she may need the report but not be able to access the Internet or VPN from behind the customer's firewall.

More Tips for Portal Projects

Keep these additional recommendations in mind when planning and implementing your portal:

Set specific goals for your portal implementation as well as concrete success factors that you can measure. Measure adoption rates, gather feedback, and provide incentives for your users to visit your portal often. One company added the daily cafeteria lunch menu on the portal home page to drive traffic. In this case, the lunch menu iView was situated right next to some critical KPI alerts being generated by SAP Business Information Warehouse (SAP BW). Other incentives I've seen to drive traffic include iViews that query SAP BW for reports on the quarterly bonus structure for employees and the monthly commissions for the sales staff

.Avoid initiating a portal project without executive-level sponsorship. A portal can potentially touch numerous points in your IT ecosystem from SAP HR to SAP SCM to SAP CRM. Without executive-level sponsorship, organizational roadblocks can easily stall your portal project.

Keep your portal as politically neutral as possible. Keep your options open by publicizing your portal as an "enterprise portal" rather than as an "HR portal," "CRM portal," or "intranet portal." Also, assign ownership to a dedicated, cross-functional portal team. Letting any one functional group "own" your portal is asking for trouble because the portal will inevitably integrate other functional areas in the future.

Resist the temptation to get your portal up and running as fast as possible. Portal implementations involve much more than just an installation of the software! The power of an enterprise portal is that it becomes the single destination for all your enterprise's applications. Just as the MSN and Yahoo! portals keep you up-to-date with your areas of interest, your enterprise portal needs to keep you up-to-date with information about your organization. Accomplishing this task requires careful and deliberate evaluation and a clear strategy for reaching your goal.

Beware of promising too much from your initial portal implementation. The key is to strike a balance between integrating enough content to provide a reasonable ROI and achieving a quick win. In my experience, the best approach is to prioritize your content so that the initial implementation phase contains something intriguing to drive traffic and establish a framework for growth. Subsequent implementation phases can add content to keep the portal fresh.

Without relevant content, your portal is just a fancy Web page. As with any solution, the technology should not be implemented for technology's sake. A delay is better than a failure. A failed portal implementation is a lost opportunity, and an unsatisfactory experience can possibly turn off your users from future use.

No single technology is a silver bullet for all your problems. As with your other SAP implementations, set reasonable expectations - and then exceed them!

Rizwan Uqaili is an engagement manager with business intelligence services at Rapidigm. He also manages enterprise portal services at Rapidigm and has assisted numerous clients with their strategic SAP Business Intelligence and SAP Enterprise Portal initiatives and implementations. Rizwan is a speaker at ASUG conferences and SAP NetWeaver/BW and Portals conferences. You can reach Rizwan at

An email has been sent to:

More from SAPinsider


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!