Creating a new portal

Part 6. Administering and maintaining the portal

Portals require care and feeding at least as much as other applications do


Content series:

This content is part # of # in the series: Creating a new portal

Stay tuned for additional content in this series.

This content is part of the series:Creating a new portal

Stay tuned for additional content in this series.

Why do you need to think about portal governance? Governance is a growing topic across the enterprise and a portal is just one silo in an organization. So, the real question might be: What is special about governing a portal environment? In this article we provide you with some common sense guidelines for setting your own portal governance strategy.

Portals bring together information, applications, and people in ways that cross new boundaries within organizations. Applications, which were previously developed and managed in separate single silos, are now being integrated into portals; they have to "play nicely" with other applications in the enterprise. This is why executive level sponsorship is so important for governance models; you need support from your leaders to ensure that disparate applications work in concert within the portal environment

You could spend days on the Internet finding volumes of information on IT governance and quickly realize how draining such an exercise is. Your head would soon be swimming in a sea of endless questions such as:

  • Which type of governance is adequate for my portal project?
  • How does privacy regulation affect our plans for user’s self-registration?
  • What is Sarbanes-Oxley, and how does it affect our policies on backups and offsite storage?
  • How is content access related to personalization, and how security affects the placing of portlets?
  • How many people are needed to release and maintain our portal?

These are valid questions, all of which need to be addressed in the way you build the framework for defining and managing the delivery and future lifecycle of your portal. This is exactly what portal governance will help you achieve. We consider this framework to be similar to any technical framework; that is, it is a set of broadly defined topics where you can plug in your own rules and processes for managing your specific portal environment.

This article outlines some of the processes and procedures to examine right before your portal goes into production, recognizing that, ideally, you are thinking about these topics long before your portal goes live. It also covers some of the on-going procedures that are needed for good operations and governance of your portal environment after it is in production. As you have seen in the other parts of this series, the technical aspects of building a portal are only part of the full effort of making your project a success. Just as important are some of the non-technical processes, such as planning, running the project, and managing a live portal environment. In addition to governance concerns, this part discusses staffing and portal operations. Finally, it explores aspects of security, monitoring, and metrics of your portal.

Why consider portal governance?

The reason for implementing a portal in the first place is to provide the enterprise with the tools to achieve its goals. And the way an enterprise realizes these goals is through people. Yes, people! It is people who run portals. It is people who use portals. It is people connecting with one another and collaborating through a portal that helps make the enterprise run. So, you need a set of processes, policies, and people that constitute the framework for "playing nice in the portal world".

We can state this in another way; call it return on investment (ROI). A portal is such a large investment that it must be managed in order to get the maximum return on the value already invested.

What is portal governance?

A well-defined portal governance structure should, at a minimum, address:

  1. Business and organizational transformation
  2. Portal technology alignment with corporate objectives
  3. The oversight of the investment and the value that investment will deliver
  4. The structure of sponsorship and of ‘issue escalation & resolution’
  5. The ways to measure performance
  6. Management of cost and delivery

Business and organizational transformation is the goal of implementing technology to help transform the enterprise. Businesses want to achieve the goals of the enterprise; therefore, they implement IT projects with the goal of changing the way work is done. For example, by investing in portal technology businesses can improve worker productivity and help achieve the primary objectives of the organization, which is often related to improving the financial picture of the enterprise. In order to accomplish this effectively, management must ensure some degree of oversight to make sure that spending in technology delivers the promised value to the organization. This oversight must be structured to include clear lines of sponsorship, ownership, auditing & compliance, and well-defined processes for issue escalation and resolution.

At the end of the day governance is all about the control of resource, and minimizing risk on current investment to ensure value delivery as a return.

Therefore, a successful governance model should have the appropriate metrics to measure such an outcome. We will take a look such at a model that in the next section.

Defining a direction

It is important to define early on where you are going with your portal in terms of enterprise and organizational objectives, as well as your technology roadmap. We talked a lot about this in Part 1. Getting started. For example, will your portal bring under one umbrella a full host of applications across the full spectrum of the enterprise such as ERP Systems, accounting, HR, Business Intelligence, and so on? Or will your portal focus on a particular business unit, integrating only a few systems such as Content Management and business process workflows? This is not to say that you shouldn't be flexible in changing to respond to market conditions; in fact, portals are designed to assist in this type of flexability. But aggressiveness of your initial plan and strategy can be largely dictated by the budget and technology constraints of your organization.

There are at least three determining factors that will dictate the complexity of your governance structure and the direction you take with portal governance. There could be more factors in a very complex organization but, for simplicity sake, we have narrowed down to a few key considerations. You will see that all three of these factors tie together very closely in helping to define a strategy. These factors are:

  1. The size of your enterprise.
  2. The scope of integration into the portal.
  3. The maturity level of your organization.

Size of your enterprise

One-size-fits-all solutions are a ticking bomb for a portal project! Unfortunately, we have seen them go off in some projects. Large enterprises have a level of complexity that can be exponentially larger than smaller organizations. Larger organizations tend to be more structured; they usually have more oversight and they might worry more about regulation and compliance. Deploying or maintaining a portal is a bit more difficult for the team because it means more red tape and stricter procedures to achieve similar goals (compared to a smaller team with a less complex installation).

When defining your portal governance direction, be realistic in your expectations. Do not expect to get something in place within a few days or weeks, when you know it might take months to get agreement from all parties involved in some processes.

For with organizations that do not have a lot of structure in place, the first step more likely should be a small one; start the process of adding some formality to your organization.

Scope of the portal

When your portal integrates multiple disparate systems such as ERPs, accounting, human resources, and content management systems (CMS), the tendency is to enable every single user within your organization to interface some how with your portal. This adds a level of complexity much gerater than when if you created a single tenant type of portal focused only on CMS integration. More systems translate into more owners looking for control of the process. This complexity ultimately affects your policies for publishing and updating content; placing portlets and defining navigation; and maintenance and bug fixing release management.

Organizational maturity

The level of maturity in your organization will drastically affect the type of goals you can set and how you can achieve them. If your organization is in an early stage of maturity regarding the way it can deliver, assimilate, and maintain portal technology and its supplements, it will take a greater effort to achieve lofty goals with your portal project.

At the end of the 1980's, the Software Engineering Institute (SEI) at Carnegie Mellon University developed the Capability Maturity Model (CMM) as a tool to help organizations assess and develop the organization’s ability to deliver software projects. This model consists of five levels of maturity that describe the state of an organization related to its capability for delivering software. The five levels are:

  • Level 1: Initial
  • Level 2: Repeatable
  • Level 3: Defined
  • Level 4: Managed
  • Level 5: Optimizing

According to SEI, "A maturity level represents a new level of organizational capability created by the transformation of one or more domains of an organization's processes." Therefore, to move from one maturity level to another, an organization must change in defined process area. Consequently, a higher maturity can help you with the rate of technology adoption of your organization. More recently the CMM model has been adopted in many industries; for example, it has been adopted by the IT Governance Institute and its well defined COBIT (Control Objectives for information and related Technology) framework.

Most people in the IT industry have at least heard of CMM or COBIT. We are not trying to push either of these models. Instead, we want to illustrate the idea of organizational maturity; however you measure it, is an important element that needs to be considered when outlining your strategy. CMM, with all of its key processes areas, is one tool that can help you know where your organization stands in the organizational maturity roadmap. The tools and processes you use to measure maturity it is ultimately up to your organization.

Assessing enterprise readiness

So, before you can define a clear model for portal governance you need to know how to measure enterprise readiness within the organization. Readiness is "the state of having been made ready or prepared for use or action". (WordNet® 2.1. Princeton University. 10 Mar. 2007.

Readiness in this context includes the ability and willingness to deploy, maintain, and grow your portal. From the viewpoint of portal governance, understanding the readiness level means answering the questions of what the organization is ready to do with the portal, and how it will be used to service the objectives of the organization. However, in order to understand readiness, we first need to understand what makes up the enterprise and what elements are key to successfully delivering your portal project.

To assess readiness you need to evaluate:

  • Who needs to make decisions about what?
  • When can changes be made and by whom?
  • Who needs to be notified about changes and when?
  • Who has ownership of changes, who oversees that policies are being applied and followed and who reports to whom on status of change and deployment?

The responses to these questions will map a multidimensional state of your enterprise in terms of readiness. Below we explore this multidimensional model and how you construct it, in practical terms, with variables that are measurable and quantifiable.

Nine dimensions of enterprise readiness

When considering portal governance there are three common facets to any enterprise:

  • Organizational Structure. An organization needs structure to survive, and the level of structure it has is usually dictated by its size and how well it is doing in the industry.
  • Technology Roadmap. When an enterprise maps its path for using and bringing in newtechnology, it conducts a self-assessment to establish its current position, defines specific goals, and develops a plan to achieve those goals. This map can help the enterprise assess whether it is ready to deploy, maintain, and adequately support a portal project.
  • Performance. An enterprise needs a way to measure how it is achieving its objectives. For a portal project, these objectives are defined earlier on by the business team doing the feasibility study. To assess your enterprise's need for governance you need to know the expected performance levels expected of your portal organization.

Ideally you have some sort of organizational structure, a technology roadmap, and a certain level of desired performance that is usually measured in terms of sales or market share. To assess whether these facets are ready to deliver the objectives of the enterprise, organizations should measure the following three variables:

  • Capabilities. What are the capabilities within your organization, in your IT infrastructure and in measuring the performance goals stated by your management team?
  • Processes. What are the processes in place to deploy projects, to manage change, to provide support and maintenance to your portal project?
  • Tools. What are the tools in place that your organization can use to execute the plan? Are the members of your organization trained and ready to use those tools to achieve their organizational goals?

If you combine the three common facets with the three variables listed above you get nine dimensions as listed below in REF _Ref35357170 \h.

Table 1: The nine dimensions of the enterprise used to measure organizational readiness

Organizational StructureTechnology RoadmapDesired Performance
Capabilities% (D1)% (D2)% (D3)
Processes% (D4)% (D5)% (D6)
Tools% (D7)% (D8)% (D9)

These nine dimensions can be mapped into a matrix form with percentages in a normalized scale, or as a normalized spider graph such as the one in Figure 1, which shows the multidimensional nature of the assessment. The spider graph is formed by linking the three intersections of each variable with the facets, forming a triangle for each variable. These triangular patterns show you the state of your environment.

The graph tells a story. Almost immediately you can see weaker areas within your organization or environment, indicated by those items with very low points in the table or graph. If any three corresponding points have very dissimilar sides, this would identify a potential problem area. Figure 1 shows a well rounded organization that is not overly strong or weak in any area.

This assessment is only a framework. The goal is to determine where work is needed within the organization to improve your organization models and team competencies.

Below we address those dimensions that we believe are most important to your success implementing a portal project. The better you assess the current state of your organization, the better your chances that you can make the hard decisions needed for the success of your project.

Figure 1: Assessing readiness in your enterprise
Figure 1: Assessing readiness in your enterprise
Figure 1: Assessing readiness in your enterprise

D1: Organizational Structure – Capabilities

Your capabilities in organizational structure include the way your teams are organized and how they interact to design, develop, deploy, train, and maintain your portal infrastructure. For example, how ready is your organization to create multiple teams to oversee the way web content is created, approved, distributed, and published? At a minimum, your organizational structure should at least have the following teams working towards governing your portal:

  • An executive sponsoring committee. Make sure that a "C level" executive is sponsoring the team to insure your portal achieves its enterprise-wide objectives. This team should be lead by your program champion; that is, the executive who will have the overall ownership of the portal project at the enterprise level.
  • A project office. Don’t kid yourself; you need people who understand organizational change to pull off a portal project. Let me make it clear: software developers won’t cut it for this, and neither will software development managers. You need a very specific type of person for this task-- the type that can get around oceans of people and meetings ad nauseam. Look into the ranks of the program and project managers or the change management consultants to staff the project office.
  • A compliance and audit team. This team will help keep the project honest and on track by holding you or the portal project team accountable to defined policies and procedures. Make sure that this team is not so inflexible that you feel they are trying to break your back every time someone publishes content. Governance, by its very nature, implies control. Make sure the scope of auditing is at a very high level, the level at which you want to be managed. Usually this would be by objectives and not by tasks or activities.
  • Development, Deployment, and Operations Teams. These are the people that get things done. If we were talking about a baseball team, we would have the regular folks that play in every game. You are probably one of them.

D2: Technology roadmap – Capabilities

Your technology roadmap should be designed in such a way that it enables the enterprise with the technologies and services to meet its necessary objectives. A technology roadmap can help you visualize the overall picture of an organization that is expecting to have a certain level of expertise in certain technologies. This is important because it is the internal pace to which the entire organization is marching regarding new and existing technology within the enterprise.

The roadmap should be driven by, and in alignment with, overall organization objectives. It can help you assess the level of maturity regarding specific technologies that the corporation will have at a given time in the future. With this information, you can more easily determine whether your project has a chance of being successfully deployed, maintained, and supported. So, your technology roadmap plays a key role in assessing the readiness of your organization for your portal project and the type of governance you can implement.

D4: Organizational structure – Processes

Processes allow us the luxury of repeatability, a luxury worth seeking in portal projects (and other projects in the IT and software world). An organization that has a defined set of processes is a mature organization that values repeatability and knows the importance of managing risk. In your assessment, look for processes with related stakeholder involvement at all levels. For example when changes are being made on the production system in your portal, you want to make sure that there is a change management process in place that involves all the right stakeholders such as system administrators, content creators, business unit managers, development managers, and so on. When a change is made, there are no surprises and every stakeholder has a chance to participate, and to see how the change will affect their interests.

Some processes relating to organizational structure include:

  1. Structure for Decision Making
  2. Issue escalation
  3. Compliance and control
  4. Change management
  5. Program management
  6. Compliance and monitoring

D9: Desired performance – Tools

Performance goals need to be defined early on to know when you have successfully reached your goals. Some of the performance tools you need to put in place for your portal governance include:

  • Ways to track your goals and objectives trough the organization
  • Policies and procedures to define the standards for measurement

Governance can be built around performance goals (primarily), but you need some level of infrastructure and tooling to measure performance. IT builds applications to help the business; your governance structure defines how those application are spread throughout the organization. But don’t get too carried away with technology. Policies and procedures are excellent tools to establish the foundation for how the usefulness of these applications should be measured and executed. Without the right policies and procedures in place, technology alone will leave your management team without a point of reference for measuring performance.

Another tool that your managers can use to set and measure performance goals is a technology adoption program. Because this type of program teaches users how to use and adapt technology to their work, adopting such a program should increase the chances that your teams and the overall organization will achieve the performance objectives.

Change management programs are also effective tools for helping to achieve your stated goals.

At the end of the day you need to make sure that you have an objective measurement of the way your enterprise will define, implement, and maintain the portal project being deployed in the organization.

Finally, it is important that the technology roadmap matches the resource allocation and the objectives defined for your organization by the business strategy.

The governance model

Applying common sense to business knowledge and knowing how teams deliver projects is just the right combination when it comes to approaching portal governance. There are no fancy formulas or complex diagrams that will be your silver bullet to success. It simply takes teamwork, sound management, and solid technical skills to deliver in such projects.

Figure 2: Portal Governance Model & Lifecycle
Figure 2: Portal Governance Model & Lifecycle
Figure 2: Portal Governance Model & Lifecycle

Many people approach governance from a viewpoint of organization diagrams. It takes more than org charts to instill a philosophy of ownership through the organization. The simplest of approaches is to use a common management lifecycle model, as shown in Figure 2. There is a not a lot of science behind these models other then taking an iterative approach; there is no beginning and no end.

This "deliver incrementally" lifecycle approach is the same principle used for software development that has grown in popularity over the last several years. This particular lifecycle consists of 5 phases:

  1. Define and Target. Set your objectives using the nine dimensions discussed earlier.
  2. Plan Accordingly. Craft a "how" plan to achieve your targets.
  3. Implement and Deliver. Build teams that sponsor, own, monitor, and audit the entire lifecycle of your projects.
  4. Measure Performance. Measure the right variables using the expectations set in the "Define and Target" phase.
  5. Optimize. Based on your measurements, make changes as needed, and then start all over again.

Portal project teamwork

Working on software projects is by nature a rather difficult task. The portal framework adds an additional dimension. Portals integrate many disparate systems into what appears as a single interface. This integration can make things difficult when trouble arises because there are so many sources to deal with, and the framework allows for distributed control. The quality of our lives is at stake when undertaking such large projects; some leveled approach is needed when working on these types of projects. Below are the principles that make up our philosophy when working on portal projects.

  • Constant team communication. It is fundamental that all members of a team be "on the same page"; that requires constant communication. It is not the amount of communication that counts; rather, it is what is communicated and the frequency of communication that counts. Teams go to extremes on communicating; they are either too shy or are overly eager in their communication for fear of either doing too much or too little. The rule of thumb should be that it's better to over-do communication than to under-do it. Maintaining constant team communication is essential to project success.
  • Pro-active issue and risk management and. Risk management is an obvious goal for every project. Build a risk management plan that includes plans for dealing with risks related to technical issues, schedule, and cost.
  • Keep stakeholders engaged. It is fundamental to keep all stakeholders informed and engaged for the duration of the project. This way you can help to manager their expectations and you can incorporate their input throughout the lifecycle of the project.
  • Always design simple solutions. Simpler is always better, and when it comes to large teams the norm should be to deliver simple designs to minimize project confusion and risk.
  • Manage Change. If one of the first theorems about business is that "change is the only constant", then a corollary is that "change must always be managed". Failure to manage change increases the risk of the change not happening as expected and it jeopardizes the success of the project.
  • Manage Quality. Quality doesn't come easily and it’s definitely not a random byproduct. It requires planning and discipline. Quality in software engineering is especially challenging because it is so difficult to measure
  • Deliver incrementally. There is wisdom in taking baby steps first. This article series has been devoted toward helping you understand the challenges and benefits of a portal environment. Go slow; learn what you don't know.
  • Have fun! Most people want to feel satisfied with their job and they want to enjoy what they do for more than forty hours a week. Take time with your team to do more than work together. After all, you are surrounded by people constantly; you may as well enjoy their company while it lasts.

Staffing a production environment

One question that is often asked is how to staff an ongoing portal environment. The answer to staffing needs can vary based on the size of your portal and the governance planning that you have put into place. Stronger governance tends to require more staffing, and to provide more control over the environment. Organizations that are a little looser with their planning will try to minimize their staffing needs, which can be ok, minimal staffing can also result in less control over activities in the environment.

Staffing depends on a few items that need to be decided as you are building your project plan. Specifically, it is important to understand how the environment will be managed during the on-going operations of the portal. Some questions to ask include:

  • How active will updates and on-going development be with the portal?
  • What is the size of the initial and planned portal environment?
  • What are the operations plans for managing updates and new applications within the portal environment?

One of the next steps is to understand the roles and responsibilities within the environment, and then to decide how many resources are needed within each role.

Portal roles and responsibilities

The size of your portal staff depends upon the type and size of the portal environment, and upon how much "care and feeding" the system needs on a daily or weekly basisWe won't cover every role here because many roles are organization specific, but the core roles are described below. These roles are listed in order according to the level of access they have to the system.

System Administrator

The System Administrator is one or more people who can access the portal application at the operating system (OS) level. This person (or persons) has access to install and remove applications, change OS permissions, and make changes to property and system configuration files.

WebSphere Administrator

The WebSphere Application Server (WAS) administrator has access to the WAS admin console. This console is separate from the portal administrative screens and allows the administrator to configure application server and portal JVM and other properties. This person(s) can create JDBC connections, and can modify system configuration, such as JVM heap size and web container threads, and many other system properties.

Portal Administrator

The Portal Administration is the wpsadmin user of the porta, although that specific username should probably not be used in a production system. (We discuss that later in this article.) The portal admin can log in to portal administration and install portlets, and create pages, URL mappings, and other portal artifacts, as needed. The Portal Administration can also manage the Access Control List (ACL) that determines role andpermission mappings for your portal.

Deployment Manager

The Deployment Manager is a catch-all role that can be used depending upon how your organization commonly manages the build and deployment process for an application. Even if you have a specific way that you put together your builds and deploy your applications, your approach will probably change when using a portal. This is partly because of portal requirements, and partly because of technology enhancements. When assigning someone to this role, ensure that he or she has the authority and personality to push back on other teams (such as development, infrastructure, and testing), when procedures are not followed correctly. This role is often stuck in the middle of several teams with different priorities; the Deployment Manager needs to be able to stand firm.

The Deployment Manager can be "hands-on", actually assisting with builds and helping to deploy assets to the portal. Alternatively, he or she can act as more of a coordinator to insure the right artifiacts are identified, compiled, and deployed on schedule. Taking this second approach would more of a Change Management Lead or Configuration Manager.

Development Team Lead

Someone should be assigned as the lead for the development team. This person is the single point of contact for development activities. He or she coordinates with the Deployment Manager and with the deployment, infrastructure, and testing teams, as needed. This role is a technical one. In many cases, this person assigned to this role is at least as technically competent as, or more technically competent than, the rest of the team members; he or she just has these additional coordination responsibilities added to his or her job.


Other related roles and teams that help make up the portal production team include:

  • Support personnel who field calls and call a system admin when a problem occurs.
  • Development teams working on the next release of the portal or new functionality.

Training and education

Assuming that not all members in the organization have all of the skills needed to jump right into one of the portal roles, some type of training will be needed; that training can be either on-the-job or classroom training. Members of the initial portal development team often move into operational roles after a portal goes live. Alternatively, in the cases where a dedicated team is maintained to work on new functionality, the operational environment can be managed by these team members as part of their ongoing responsibilities.

Do things in increments of X week cycles of training and skills building: For example, think about scheduling a deployment every 3 weeks. In cases where this is not possible, for example when a portal is developed by a third party or external development team, then ramping up internal staff to support the environment is critical. As part of the turnover there is often a period of training and support, perhaps 30 or 60 days, depending upon the relationship and cost. In other case, once staff is identified they can work with the original team for a period of time to absorb knowledge about the portal.

Get formal training for portal support roles: We strongly recommend that you get formal training for anyone who is going to be in a core portal support role, including the portal and system administrators. There is no substitute for a few days of learning some of the nuances of the system, and about all the features and functions that are available to the administrator and end user. See the Related topics section for a link to the IBM Global Training web site for information on available courses.

Keep teams members around for smoother transitions: It is a common practice (or should we say "mistake") to let people go at the end of one phase of the project and to bring in the next team for the beginning of the new phase. This is usually a financial decision that assumes the project cannot afford to have people hanging around, and not being productive in their core skills. This is often the case between the development and testing phase, or between requirements and design, and sometimes between design and development. This is generally a bad practice in any project (because of a lack of continuity), so we cannot say it is any worse in portal projects. What we can say is the portal knowledge is different than general Java project knowledge so this may factor into your decisions about letting people go too early in a project.

Fit the training to the role. IBM offers a variety of classes on WebSphere Portal that are designed for various skill levels and needs. Classroom training is essential, and it is only the start of someone’s skill development cycle. It is amazing what a few days of focused training can provide to someone new to WebSphere Portal. Classes that focus on portal administration often provide a base level of information that takes weeks for someone to learn on their own. Even if someone does not use all the functionality provided by the administration interface, it is important for administrations to understand what is available to them.

Portal auditing

Normally production environment teams maintain an audit log of the system and of changes are made by different users. However, seeing the changes that are made in the portal configuration has been difficult up until recently. Administration auditing was provided with WebSphere Portal V5.1. It enables the portal to log administration events as they occur. The information provided includes the action that was performed along with a timestamp, who performed the action, and some specifics about what the user did.

This functionality is turned on in the portal by activating the auditing service that is included with the portal framework. See the WebSphere Portal Infocenter for details on how to enable this service and how to turn on some of the individual tasks that can be audited. For example, the tasks you can audit include:

  • Creating, modifying and deleting users and groups
  • Creating, modifying and deleting portlet applications by using the portal user interface
  • Assigning and revoking roles to and from users
  • Modifying role blocks
  • Modifying resource ownership
  • Creating, modifying and deleting protected resources
  • Externalizing and internalizing resources
  • Installing and uninstalling Web modules
  • Creating and deleting application roles
  • Assigning and revoking application roles to and from users
  • Adding and deleting roles to application roles
  • Initializing a database domain

Of course, there are different schools of thought about the idea of auditing functionality within the portal. While this is a nice feature, some believe that strict governance would not allow users to perform these types of actions in a production portal anyway. In many cases, it is recommended that administration be disabled in a production environment. However, we realize that there are many different customer situations, and we need to be able to handle those effectively.

Monitoring you portal

Ongoing monitoring of the operations of your portal is one of the most important tasks after your portal goes live. There are a number of tools and services available to help you ensure that your portal is up and running at all times. There are two key features in many monitoring tools available on the market today.

  1. Continuous operations monitoring. This capability provides an up-to-date status to tell you if your system is up, and it provides some common metrics of the system at any given time. These metrics include:
  2. How active is the portal?
  3. What is the memory consumption?
  4. Is anything running slow? What is the response time?
  5. Is any aspect of the portal or one of my nodes not currently active?
  6. Problem troubleshooting. This feature is necessary when a problem occurs to help you diagnose what the problem might be with the system, and is especially important during performance testing or before a portal goes live. It can tell you:
  7. Where are things getting stuck in the request path?
  8. What is the delay for specific requests?
  9. Specifically where are the trouble spots or what are the system troubles?

Many tools provide one of these features of monitoring, but some tools provide assistance with both. IBM Tivoli Composite Application Monitor for WebSphere (ITCAM) is just such a tool that can provide comprehensive diagnostics for your portal for both troubleshooting and real time system monitoring. In Figure 3, ITCAM displays some statistics from a running portal instance.

Figure 3: Portal statistics in ITCAM
Figure 3: Portal statistics in ITCAM
Figure 3: Portal statistics in ITCAM

Monitoring using these types of tools is becoming increasingly more common and should be considered well before a system goes into production. Monitoring agents can impact a production environment anywhere from 3 to 5 percent depending upon the depth of the analysis they are performing. In debugging situations this impact can be much higher. Setting up these systems also requires some downtime or restarting of the servers, so you will want to plant for it well in advance.

Another aspect of monitoring is that over time the system administrators can start to understand the overall health and usage of the system. This can be correlated with the metrics discussed in the next section to help determine the overall growth trends of the portal. This will assist in understanding how new deployments may impact the overall environment, and knowing when new hardware might be necessary to keep up with growing demand on the system.

Tracking portal usage

While monitoring is the best way to see how the system is performing, reviewing user metrics is the best way to see what people are actually doing on your site. There are a number of different approaches to achieve this. Mostly for most web applications, not specific to portal, is the URL analysis that many tools perform on the Web Server logs. There are several vendors, such as Google Analytics and NetTrends, that provide this type of analysis; they provide a good start and should be considered for your portal. This is especially true if you already have the tools available within your organization and are performing this type of analysis on other web sites.

For a deeper level analysis, WebSphere Portal provides a set of site analysis logs that can provide more portal-specific information about usage. Originally these logs were built to be analyzed by the IBM Site Analyzer tool, which IBM no longer produces. However the logs, commonly called SA logs, are in a standard web log format, (NCSA Combined log format) and are easily readable by other major tools.

The SA logging function is configurable so you can tune your logging to the level you feel is necessary. The first gut approach is always to just turn everything on; instead, consider what you need so you reduce load on the portal and the size of the logs. The loggers available with this service include:

  • Session Logger - Tracks login and logout commands.
  • User Management Logger - Tracks management of users and groups.
  • Page Logger - Tracks management of pages. Create/Edit/Delete.
  • Portlet Logger - Tracks URLs that include /Portlet/.
  • Portlet Action Logger - Tracks the invocation of a portlet action.
  • Error Logger - Tracks redirection to error pages.
  • Application Action Logger - Tracks Application Actions.

Some of these actions may not be as meaningful as others, so consider the actions that truly happen in your specific portal environment when you enable this functionality.

Anew standard in user tracking is emerging that takes better advantage of web technology. Embedded links or JavaScript within the page can report to a central monitoring server on user activity within a web site or portal. Reporting can be done in real time or over a set period of activity.

Google offers one such service, however they are only one of many vendors that offer this type of monitoring to customers. Figure 4 shows a view of Google Analytics data from a running web site.

Figure 4: Google Analytics
Figure 4:  Google Analytics
Figure 4: Google Analytics

Portal security

We all know how important security is to your environment. Many of our customers take security very seriously; many take it to the point of making it almost impossible to install, configure, and tune the portal environment. It is sometimes easier to work with these types of customers than with those on the other extreme, because often they have defined processes for getting things accomplished, even if it does sometimes take a little longer to accomplish our goal.

Teams often focus on security in the early stages of a portal project. What does the LDAP schema look like? How is the directory information tree designed? You need this information to determine where the user ID and password information is going to come from, and how you are going to connect to those systems. Also, in an enterprise context, you might design the architecture around implementing an external security application, such as Tivoli Access Manager.

This type of security is well-understood and most projects will have these discussions with the part of the organization that owns these systems. Another aspect of security that is sometimes overlooked is the concept of hardening, or locking down, the system and the portal environment. This is not always the case; when a system goes into production the administrations will perform some hardening of the system such as removing any user access that was needed during installation or configuration. This is not always a comprehensive hardening of the system because system administrators are not always knowledgeable about applications such as a portal and where the security exposures might lie. At a minimum, you need to consider:

  • Changing admin passwords on the system, or even using non-default User ID’s such as wpsadmin.
  • Removing any passwords from scripts or configuration files.
  • Modifying permissions on the system to not allow just anyone to read/write system files.
  • Installing portal as non-root, to ensure that portal administrators do not have system root permissions.
  • Removing sample portlets or applications that you do not understand.
  • Cleaning up log files so that system or user information is not available in the logs.

Hardening is not a one time effort. As the system changes over time some level of security should keep up, and even improve if new security holes are discovered. The WebSphere Portal Security page and the WebSphere Portal InfoCenter provide detailed information on these types of security issues. See Resources for links to these pages.


We hope you have enjoyed reading this series, and that you have gained some insight that will help you build your next portal project. There is a lot more information that the authoring team would like to have provided, given endless resources and time. Our goal has been to find a middle ground and to try to reach as wide an audience as possible within the portal realm. By covering some of the basics and then adding in some detail in areas that we think add value; we hoped to improve many of the next generation projects using WebSphere Portal.

We have received lots of good feedback from many of the readers of this series over the last year or so that that it has been in progress. Our goal was not to write to any specific version of the products, but rather to focus more on the processes involved. We have enjoyed writing this series and embarking on the discussions that tend to come out of these things.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=WebSphere, Tivoli, Security, Tivoli (service management)
ArticleTitle=Creating a new portal: Part 6. Administering and maintaining the portal