Expand +



Keep Your Portal Shipshape After Go-Live

by Rizwan Uqaili

August 11, 2009

One of the key elements in maintaining your portal is having the right people available in support positions. Find out who should comprise your steering committee and who should be part of your system support team. Also discover how much testing you need to perform and when.

Maintaining an enterprise portal after go-live is arguably more difficult than setting it up in the first place. As the portal becomes more complex, users need more support. Implementing the inevitable fixes requires planning to minimize downtime and ensure that the fixes work in your environment. The portal team must monitor back-end systems for availability (see "Avoid the 5 Pitfalls of Portal Administration" below).

Avoid the 5 Pitfalls of Portal Administration

  Pitfall   Description   Deterrent
Irrelevant portal content The content may have missed its target to begin with, or perhaps it has become cluttered with old content or wasn’t updated to meet changing user needs. You can gauge the popularity of the content with online portal-feedback forums, and you can measure traffic by monitoring portal components. Most important, you need to educate the help desk about the portal’s features and functionality so they can provide “live” help when it is needed. The help desk can also collect all the requests they receive for portal updates and accumulate them to present to the “steering committee” for consideration.
User frustration with portal speed The portal may have all the appropriate data and content integration, good navigation and layout, on-target role assignment, and adequate security, but if it takes 10 seconds for a page to appear, the users consider the portal to be junk and avoid using it. Plan ahead for this potential scenario. If you have an external-facing portal, make sure that even a dial-up connection delivers decent results. Custom Java iViews should strictly follow all performance-tuning guidelines. Forecast portal sizing accurately to account for peak times. They may last for only a brief while, so you can redistribute processor capacity and bring it online for the portal just for the peak period. For instance, in SAP Employee Self-Service (ESS), all employees sign in at about the same time for benefits enrollment. It’s not cost-effective to allot peak capacity all year, so you need to redistribute online capacity to the portal just for the period of peak usage. This provides adequate performance for peak usage periods and doesn’t waste resources for the rest of the year.
Portal components going down intermittently This problem can be very frustrating. Although the first two issues contribute just as much to the portal’s lack of success, unacceptable downtime gets the most attention. Components go down for lots of reasons: for example, a lack of coordination of service level agreements (SLAs), improper stress testing or network component testing, or simply inadequate regression and unit testing. A portal landscape has many moving parts, and each component needs to have an identified and agreed-upon SLA. It should include backup strategies and contingency plans in case of an outage. For example, you can install a portal server with active/active load balancing, but it’s expensive. If it’s too expensive for your budget, you can configure the portal so that if the production instance goes down, the quality assurance (QA) instance becomes the “live” version. You can also replicate the directory-server domain controller (DC) to provide redundancy in case the primary DC goes down.
Chaotic change management Over time, change management can become chaotic, usually due to a lack of clear lines of communication and ignoring the protocols established to update portal content. Invest time in developing governance standards as advised in the article and maintain a portal steering committee.
Lack of training for the portal administration team This is one of the portal maintenance pitfalls that is less commonly stressed. Unfortunately, this is a common cause and results from a lack of planning up-front. Identify support team ahead of implementation time and invest in both formal and informal training. Also ensure adequate time in the implementation project plan for knowledge transfer.

A strong governance model will help your portal team address these issues. Portal governance is a collection of policies and procedures for commonly used portal functions. It also defines who is responsible for each area. The policies and procedures should reflect whether a portal is standalone or federated and whether support is centralized or delegated across multiple teams. Portal functions that require documented procedures typically include content development, transport of new and existing content, and modification of the portal's layout and security infrastructure.

One more element is key to your portal governance model: a strong steering committee. I'll explain the purpose of the steering committee and the roles of its members.

The Steering Committee

Your steering committee should consist of issue champions and executives. The issue champions bring forth proposals with supported testimony from subject-matter experts. The executives review and approve the proposals and decide who should take action before scheduling the item for follow-up. The portal champions then follow up by coordinating with the portal and source-system support teams to make the approved proposals happen. The steering committee should meet regularly both during implementation and after go-live.

The steering committee should meet regularly both during implementation and after go-live in order to make timely decisions on portal policies and modifications.

The steering committee should include individuals who champion the following areas of portal enhancement:

  • Content: Advocates the addition of new content and identifying opportunities.

  • Anti-clutter: Champions making the portal clean of unnecessary content.

  • Development: Identifies opportunities for the development of new content using one of the various tools available.

  • Security: Recognizes security risks introduced with any change and gives corrective advice.

  • Testing: Ensures that continual testing in the relevant areas is taking place to remove any potential vulnerability (see “Testing... Testing...” below).
The portal support team makes the technical changes determined by the steering committee, and performs various maintenance functions on the portal.

Once a particular item is scheduled for follow-up, the steering committee hands it off to the portal support team for implementation. Your portal support team needs to include individuals responsible for the following five roles.

System support: This role is in charge of the portal’s overall technical viability. He or she:

  • Applies service pack upgrades and hot fixes.

  • Retains time-stamped backups or “ghost images” for possible retrieval.

  • Ensures compatibility with various operating-system-level patches and browser versions.

  • Monitors the various logs for ongoing performance.

  • Maintains the right level of database partitioning and monitors overall database-usage trends.

In some high-usage portal scenarios, system support may be the responsibility of more than one person. Typically, this responsibility falls into the database administrator (DBA) role, which may be performed by existing database-support personnel or by a new dedicated DBA. A Basis expert may perform the rest of system support, or perhaps it will become the responsibility of the Internet or intranet maintenance group.

End-user support: This role is critically important in determining how relevant the portal is to its user population. Depending on the portal’s scope, the number of roles, and the rate at which the content is evolving, end-user support may require one or more full-time individuals. Since the portal has no built-in tools for this, end-user support may need to maintain the Microsoft Excel spreadsheets that map users to roles, users to groups, and roles to groups, as well as mapping all roles to their accessible content. The challenges of end-user support are:

  • Keeping all this information in sync and accurate

  • Managing changes

Security support: This role is responsible for all the portal’s security-related issues. Depending on the company’s organizational culture, this role varies in significance. Its tasks include ensuring that the following aspects of security are adequate and continue to function:

  • Communication protocols for traffic both inside and outside the firewall

  • Encryption of all data, where required

  • Anonymous logon functionality

  • Single sign-on enablement, where applicable

Security support often works closely with system support to cover overlapping tasks.

Knowledge Management (KM) support: A description of KM itself is outside the scope of this article. However, if KM is installed with some of its optional components, such as Collaboration and TREX, it requires dedicated support to function smoothly. The responsibilities of this role include document publishing, adjusting KM repository features, applying classification rules, and more.

Super administrator: This role is assigned to a limited group of highly trusted individuals within the organization. The super administrator manages and controls all the other support roles and accesses, and determines the rules for the portal’s delegated administration features.

In addition to the various support roles, it is critical to have:

  • A clearly identified role structure and dedicated personnel, wherever possible

  • Executive level support on the steering committee to ensure that key decisions on support issues have a turnaround time of no more than two to four days

  • Identified “portal champions” in each department (i.e., business unit) to involve the end users at regular points in the process

  • An overall environment that supports and encourages continuous improvement

With an appropriate focus on change management and end-user training, supporting the portal becomes less of a chore. Instead, portal support becomes more about enhancing the end-user experience.

Champions Matter

Portal maintenance is arguably harder than the initial implementation, but with the right governing boards and policies in place, you can keep it under control. The steering committee is a more important part of your overall portal’s success than you may have thought.

The champions of the various areas of portal enhancement focus on different aspects of portal governance. This balance is a key element of a well-functioning portal. And the structure of the portal support team helps to maintain that balance. Planning ahead and establishing the appropriate policies and procedures can make your portal implementation a success.

Testing … Testing …

Portal testing doesn’t stop when the portal goes live. In fact, continual testing is one of the most important tasks you have to perform after go-live. The activities of many different users consistently place unanticipated demands on the portal, which those users regularly use and abuse. Constant testing of the portal’s major components makes it less likely that you’ll run into one of the pitfalls (refer to the “Avoid the 5 Pitfalls of Portal Administration”). You need to schedule regular testing of the following three portal components to identify any potential issues:

  • System connectivity: A portal’s integration points are its most important assets. Your portal can be integrated with your SAP R/3, SAP Business Information Warehouse (SAP BW, now part of SAP NetWeaver Business Intelligence), and mySAP Customer Relationship Management (CRM) systems, and so on. Your portal can even be integrated with non-SAP systems, which are an important part of the landscape: for example, Microsoft Exchange Server, other ERP systems, homegrown applications, and more.

    Make sure you test all system connectivity, performance, and single sign-on (if applicable) with your integrated components. If a firewall exists in the communications path, make sure the appropriate ports are open. If communications are supposed to be secure, run a “sniffer” on the network to verify the encryption.

    Some connectivity can break due to seemingly unrelated actions, such as applying Windows patches. Having a consistent backup strategy, such as keeping “ghost images,” lets you revert back to an earlier instance of the landscape and identify the change that caused the breakage. Also, check any back-end systems. If an integrated system is down, the portal won’t provide any content, even with proper connectivity.

  • User management: User authentication may come from a variety of sources: for example, internal or external; Lightweight Directory Access Protocol (LDAP); a database; even an R/3 system. It’s important to verify regularly that authentication is — and remains — practical. Changes in your network configuration, a router upgrade, or firewall enhancements can all sever portal authentication connections in your system.

    When you test the authentication store and connectivity to it, also check security encryption, Microsoft Windows NT LAN Manager (NTLM) authentication, and single sign-on (if configured). If you implement user mapping for single sign-on, make sure that your users are sufficiently trained on it.

    With role-to-group assignments, some users may receive “dead links” in their portal role for certain content that they don’t have access to on the back-end system. If that happens, you should re-evaluate group assignments to make sure they still hold true.

    Some new portal users may see a blank screen when they first log on because they haven’t yet been assigned a specific role. Assign some generic content to the “everyone” group so that new users feel welcome until they are allowed more specific content.

  • Page-load performance: Testing for and detecting performance issues is critical for portal maintenance. For a list of performance issues to check, see “Seven Portal Performance Issues.” And for valuable advice on post go-live performance testing, check out the following SAP published document: How to Fine-Tune Performance of Enterprise Portal 6.0 (SAP EP 6.0 is now known as SAP NetWeaver Portal).


Seven Portal Performance Issues

Set up and run scripts for virtual user testing, and capture statistics on page-load times.
Run the single-user test with zero “think time” to benchmark performance, and ramp up to test variances.
If you have external users, test with a dial-up connection to ensure acceptable performance for even your most remote users.
Make sure your home page loads in less than three seconds over the internal network, and establish a maximum load time for the remaining pages.
Isolate processor-intensive iViews such as SAP NetWeaver BI queries on their own pages, and always provide users with “eye candy,” such as a progress bar, while they wait. It makes the time seem so much shorter.
If such SAP NetWeaver BI queries are constantly being added, cache the iViews at the rate of the data refresh in the queries to avoid unnecessary hits to the SAP NetWeaver BI server for every portal request.
Remember that geographic proximity also affects performance. If all else fails, consider placing the portal server in close proximity to the primary data source.

Rizwan Uqaili is a practice manager with the SAP NetWeaver Practice at Rapidigm and has assisted numerous clients with their strategic SAP NetWeaver implementations. He has been a key speaker at ASUG conferences and the SAP BW and Portals conferences. He graduated from the University of Texas at Austin and received his MBA from Clark University. Rizwan can be reached 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!