Expand +



Don’t Fall Prey to a Poor Portal Strategy

by Patrick Dixon

August 11, 2009

The aim of a portal strategy is to put the correct structures and procedures into place to create new portal applications and support existing ones. The author has compiled a skeleton portal strategy based on practical project experience. Discover how to save time and money, and avoid portal problems that might arise later.

The portal is becoming a key component of the SAP infrastructure, but there is no “off-the-shelf” strategy document to help with the portal’s implementation and enhancement. Without a strategy, organizations run the risks of development being difficult to coordinate and increased duplication of resources and tasks — leading overall to cost overruns and failed projects.

A sound portal strategy puts the structures and procedures into place to enable the creation of new portal applications and the support of existing ones. Strategies will vary according to the size of the organization and the scope of the portal. For example, an international corporation must plan for different languages, integrate different cultures, and may have a greater need to leverage collaboration tools such as virtual project rooms to coordinate team activities and the communication of project standards, project documentation, work plans, and discussion groups. A manufacturing company may have users who aren’t used to complex interfaces. They might need a portal that provides a simple and intuitive interface, focused on minimal menus and fields. A dashboard for a CEO might present key financial data in a highly visual format so that any variances could be quickly highlighted. Here, the portal strategy would plan the data and its presentation in parallel.

I have compiled a skeleton portal strategy based on my practical project experience on many different portal projects. This strategy provides a framework for both existing and new portal projects. (I focus on iViews because, as the user interface, they are perhaps the most important component of the portal.)

You need a portal strategy in four basic areas — development, security, testing, and administration. Each of these areas is broken down into three phases:

1. Foundation: setting up the organization and procedures

2. Delivery: managing the project

3. Support: enhancing the system

Let’s look at these phases one at a time.


Before you begin portal development, you need to answer some questions:

  • What does the project hope to accomplish?

  • What reporting structures will it need?

  • Is there a project plan?

The following processes will ensure that the aims of the project are clarified, reporting structures are clearly defined, and team members understand what they need to do for project success.

The goal here is to determine the overall purpose and use of the portal. This is a high-level look at the implications of including the portal in your business. It means asking:

  • Is this portal the single point of access for all systems? A single point of access implies high availability, single sign-on (SSO) to other applications, and security (i.e., easy to get into but secure enough to prevent unauthorized access).

  • Does the portal distinguish between different organizational areas? Different areas have distinct requirements for the portal. For example, marketing requires a high level of graphics, development needs a rapid response, and finance must have data security.

  • Is personalization the reason for the portal, or is it data integration? Do you need to activate the personalization option or event-driven navigation, or concentrate on SSO?

  • Should systems in the portal be Internet-enabled?

These questions prod you into thinking about the areas on which the portal should concentrate.

Portals are involved in a wide range of situations, applications, and uses, and you need to determine how you are going to use yours. The following four topics cover the primary areas.

High-level project plan: Detail the main tasks involved in the portal project; for example, setting up the project team, developing sign-off procedures, establishing documentation templates (e.g., functional specs, technical specs). Include the main functional deliverables, branding, back-end systems to integrate, any SSO requirements, and so on.

Sample high-level project plan

Organization chart: Generate a pictorial representation of the portal team’s reporting structure so team members know where to go for specific information such as security standards, change-control sign-off, and so forth. The organization chart should enable team members to quickly determine information such as job role, reporting structure, and contract details.

Sample organization chart

Standards: Create name standards for portal objects, such as iViews, connectors, and roles. These standards are important because they help to organize data logically, enabling related objects to be located quickly. For example, all custom iViews and pages related to a particular project should go in the project folder. Develop code-migration standards, presentation standards, and code-development standards in conjunction with the appropriate team leaders.

Development methodology: Develop iView functional specifications, worksets (or navigation groupings), and role definitions with a bottom-up design methodology. Most Web sites are rigid in design. However, iViews give a portal a flexible interface because they can be rearranged quickly to change navigation and location.

A functional spec includes a flowchart that illustrates the function the iView performs. Include the operation of the iView, and any related iViews, in the flowchart. For example, an input form that creates a sales order should show both operations on the flowchart. The functional specification also contains a screen mock-up, so the user can see how the final iView should look. In general, I create one function spec per iView, but there are exceptions. You can also include batch processes and high-level database design in the functional spec.

Workset construction requires grouping iViews together logically. For example, it may make sense to group all training iViews together in one workset. Role-building is based on individual jobs. It’s a bottom-up/top-down process. Identify the discrete job roles of the people using the portal and cross-reference them with the worksets.


For the delivery phase of portal strategy, you create technical specifications and a detailed project plan, make personnel-management decisions, and develop the portal.

Technical specifications: Add technical details to the functional spec, enabling the detailed project plan to be constructed. Include security access, defining back-end connectors, and so on.

Detailed project plan: Allocate time and resources to the tasks in the technical spec.

Personnel management: Allocate and motivate your resources. Portal projects require people with diverse skills sets — from security mavens to Web designers — to enter or leave the project at different times. Delivery only succeeds if these resources are properly managed and motivated. The project’s weekly status report enables management to see what individual resources have produced and to take action when targets are not met, before they affect the project.

Development: Configure the portal and develop the iViews. Most development environments use a single development tool to minimize the cost of training and licensing. However, a portal is an integration platform, so often a variety of primary environments and development tools are used including ABAP, .NET, and Java. Depending on the type of development, developers may need access to portal operating systems, back-end systems, and workbenches such as SAP NetWeaver Developer Studio. Allocate and document these accesses. Update the technical spec for any undocumented program features; for example, if a program uses a third-party application to perform a credit-card check, makes any changes to database-design efficiency, and so forth, document it.


Support is the phase of the project after go-live. Put the following tasks in place to support the portal, ensure that changes are made in a coordinated manner, and make sure that the system is recoverable from unforeseen failures: change control, backup processes, and update procedures.

Change control: Changes or enhancements to portal functionality must be documented and approved: For a small project, the approval can come from the project coordinator; for a large project, a change-control board would be necessary with representatives from key areas such as development, security, and the end-user community.

A portal is a flexible environment, so it’s tempting to make “quick” changes such as adding an iView to a role. These changes can, however, have a negative impact on other users who may suddenly find that an iView they depended upon no longer exists. To avoid this situation, make sure all changes are signed off by the appropriate persons: The project coordinator/
change-control board should sign off on all program changes, while the portal administrator should sign off on all configuration changes, such as removing an iView.

Backups (system-level): Back up the system regularly. If the portal database is on the same server as the portal, a system-level backup ensures that the portal can be restored to that point if a failure occurs. If the portal server has a remote database, you must stop the portal server and back up both the portal server and the remote portal database.

Upgrades: You will get two types of upgrades for the portal: service packs and patches. Patches fix particular problems; service packs add functionality. I apply service packs two to three weeks after their release so any problems they have introduced have been identified. I apply patches only when a specific problem occurs that the patch fixes.

Future Strategy

It is tempting to think only of the immediate future, which, in portal terms, means the next few months. However, it’s also important to plan for the longer term — the next one or two years — because the decisions you make now can save time and money, and alleviate problems that might arise later.

A portal strategy should:

Plan ahead to allow for future growth for your hardware and software. There are several hardware elements you should take under advisement. Consider the number of CPUs you have, and buy spare slots. You need to be able to expand your computing power so you don’t have to do a major upgrade just to increase response speed. Also, make sure you have spare RAM slots available. Nothing is more frustrating than a system that grinds to a halt because you don’t have enough memory. Here, again, you need to be able to expand on an as-needed basis. Give yourself plenty of disk capacity, too. Make sure you have the required (and recommended) amount of free disk space available — another area that can freeze your system if you don’t think ahead.

On the software side, make sure your database is sized correctly; under-sizing the database can lead to performance problems due to fragmented tables. The operating system you use can also affect your system. For example, Unix requires that partitions be defined and once they are full, your system will fail even if you have spare disk space; Windows will just use the spare disk space.

You should stay within the SAP world when you have software requirements because SAP generally provides documented solutions. For example, SAP recommends using SAP NetWeaver Application Server (SAP NetWeaver AS) 6.40 for load-balancing; of course, there are other load-balancing solutions but SAP supports your efforts and provides you with guidance if you use their product.

Determine how you’re going to add new users. This method will be determined by how many new users you expect. A low volume of users can be entered manually into the user authentication system. A large number of users must be added via import routines. This mechanism needs to be understood ahead of time so that new users can be quickly incorporated into the portal.

User growth also affects portal performance. You should carry out load testing to determine if the current portal infrastructure will support new users without breaching the service-level agreement.

Plan, coordinate, and control your rollout process and strategy. Normally, a phased rollout is advisable for a portal project, as many of the technologies and processes involved are new to an organization. The phased approach lets you resolve problems and refine processes.

Determine which applications are to be rolled out so users can see the advantages of the portal in their own work environment. The first phase of the rollout is critical to the project because it will greatly influence the perception, both good and bad, of the project’s value.

Plan and deliver logistics, such as the building, network connections, and user training, before rolling out the portal. Often simple problems, such as browser versions, lack of Internet connections, and basic training, can result in severe rollout problems.

Patrick Dixon is a manager with Deloitte specializing in SAP NetWeaver Portal and SAP interface design and implementation. He has more than five years of experience Web-enabling and integrating SAP systems with SAP NetWeaver Portal, SAP Internet Transaction Server (ITS), SAP NetWeaver Exchange Infrastructure (SAP NetWeaver XI), and SAP NetWeaver. Dixon was a key speaker on portal implementation and content integration at the SAP NetWeaver BI and Portals 2006 Conference and other portal events.


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!