Table of Contents
Advertisement
project. For a complete listing of available patterns, consult the IBM Patterns for e-business
Web site at:
http://www.ibm.com/developerworks/patterns
Adopt the Portal Build & Validate Methodology
In establishing a Portal Build & Validate Methodology, we acknowledge that there are key
milestones associated with any Portal deployment. Adopting such a methodology thus
reduces the likelihood that an incorrectly installed component will go undetected, until such a
time that a significant Portal failure results. Our experience tells that among the most common
causes of Portal deployment failures is the adoption of a big-bang approach. By contrast, the
Portal Build & Validate Methodology breaks down the Portal deployment into discrete steps,
each requiring validation. Failure to do so often results in ripping apart the solution, in an
attempt to eliminate the various components of the architecture until the culprit is found.
Distinguish between COTS packages and proprietary code
With the availability of Commercially-Off-The-Shelf (COTS) packages, such as WebSphere
Portal Server and Portlet applications that deliver specific functionality, the duration of a Portal
implementation has been greatly reduced. However, it is important to recognize when custom
development is needed, as in our experience Project Managers have not always been able to
distinguish between COTS and custom developed applications.
Address performance as early as possible
Performance should be addressed as early on in a project as possible and then as an
ongoing concern. All too often performance is disregarded until the performance tuning phase
of a project, resulting in a critical situation. Consider performance testing those back-end
systems prior to starting WebSphere Portal Server performance testing, as it is
acknowledged that WebSphere Portal Server can never improve on the performance of any
back-end system. Due to the iterative nature of performance tuning, no less than one month
should be set aside for this important phase of any project.
Important: Performance testing requires dedicated hardware and software. The
expectation that performance testing can be performed using employee mobile computers
or desktops is a serious misjudgment.
Include provisions for when things go wrong
On a regular basis, project teams neglect to make any provision for when things go wrong. A
well thought out project plan includes such a provision. After all, it is far better to complete a
deployment before the target date than to keep shifting the go-live target date. Plan on
increasing any time set aside for this important facet of any project, when the level of
complexity and the number of integrated systems increases.
Adopt a proper build mechanism
During the course of an implementation, there will be many versions of the components
developed and deployed. As such, versioning is required when code and artifacts are
promoted between the various environments of an implementation. For those deployments
implementing a dual clustered architecture, with "Two Lines of Production", it is especially
important to have a proper build and deployment mechanism in place. This is to ensure that
each line of production is identical, albeit when both lines of production are operational and
not undergoing any incremental upgrade.
52
IBM WebSphere Portal V6 Self Help Guide
Advertisement
Table of Contents
Troubleshooting
