IBM BS029ML Self Help Guide - Page 66

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