Top 10 tips to ensure a successful deployment of WebSphere Commerce
- The top 10 tips are based on lessons learned from deploying WebSphere Commerce-based solutions
- The top 10 tips are meant to be thought and discussion provoking
The must-avoid scenario
It is the night before your expected launch date and you discover an issue that prevents you from launching on time
- but your TV and radio ads are already scheduled to run
- and your targeted e-mail campaign has already been sent out
- and your in-store signage has already been set up promoting cross-channel offers!
How to improve your odds of a successful WebSphere Commerce deployment
- Start with a solution outline that maps requirements to out-of-the-box features.
- Ensure that the business and technical teams are involved from the beginning and communicate along the way.
- When designing the site, storyboard and mock up the business flows.
- Plan the business flows with caching in mind.
- Develop well-tuned SQL queries and table indices from the start.
- Understand expected performance characteristics and ensure the system can meet them.
- Validate the production environment early in the project lifecycle.
- Understand how to monitor and ensure the deployment is successful.
- Ensure change control procedures are established and utilized.
- If you need help, ask for it.
Start with a solution outline that maps requirements to out-of-the-box features
WebSphere Commerce has a lot of out-of-the-box features and best practices. Where requirements and features are close, consider changing your processes and adopting new best practices.
- The first step in implementing WebSphere Commerce should be to determine which business model best fits the organization's business plans. Consumer Direct, Business-to-Business, Extended Sites, Partner Relationship Management, Supply Chain, Demand Chain.
- The second step should be to examine the starter store associated with the chosen business model and determine what features can be used, what needs to be removed, and what needs to be added. It is much easier and cheaper to start from one of the starter stores as opposed to starting from scratch. The starter stores have been built as a starting point to accelerate Time-to-Value.
- The third step should be to look at the data load or mapping early in the project. That is, what out-of-the-box tables will be used, what new tables will be created? How will the tables be loaded initially and then incrementally over time? What is the source of the catalog data and is it appropriate for display to customers, or does it need some cleansing or transforming first?
Ensure that the business and technical teams are involved from the beginning and communicate along the way
It is imperative that both the business and technical teams agree on the approach, implementation, schedule, and deployment strategy.
Technology is simply a means to achieve business results. Both technical and business people should actively participate in the design of the site. With both parties represented, the technical folks can understand the business drivers and desired results, and the business folks can understand the technical limitations and costs.
When designing the site, storyboard and mock up the business flows
- A picture is worth a thousand words.
- Reduce ambiguity and increase understanding by using the documented business process flows and building HTML mock-ups
It is difficult to explain in words how a store page will look and how it will be used by shoppers or buyers. Often times, the person who describes the page, the person who implements the page, and the person who builds the test plan around the page can interpret the written words differently. Screen mock-ups and business process flows can significantly reduce ambiguity and ensure a common understanding.
Plan the business flows with caching in mind
- Caching should not be an afterthought.
- Caching should be part of the initial site design.
A Web site can draw millions of visitors per hour. Each visitor can view tens of pages during their visit. If each page is dynamically generated and accesses the database for information, then the load on the database server can be very significant.
Web surfers are turned off by slow performing sites. When designing the features of the site and its implementation, one should consider the desired throughput and response rate. A "cool" feature that takes too long to load will not be used by its intended audience.
WebSphere Application Server comes with a Dynamic Cache (Dynacache) that can cache whole pages or parts (fragments) of a page. When storyboarding the site, one should indicate which parts will be cached and which parts will not.
Develop well-tuned SQL queries and table indices from the start
- Incorporate performance considerations upfront when building SQL queries and new database tables.
- Do not leave performance tuning as an afterthought.
WAS applications typically use a database to store and persist data. SQL queries are used to retrieve information from the database that is used as input to decisions, and then displayed to the Web surfer. These SQL queries should be reviewed up front for performance. Based on expert review, the query may be rewritten, new indices may be added to the database, or the original table may need to be modified in order to increase performance. Performance should be designed into an application, not added as a result of bad performance test results.
Understand expected performance characteristics and ensure the system can meet them
Performance characteristics should be established at the beginning of the project for example, throughput and response time.
Before the site is launched, test to make sure the site performs as expected
For a WebSphere Commerce site,
- In how many clicks does a prospective shopper want to be able to find their desired product?
- In how many seconds or minutes does a prospective shopper want to be able to start and complete a transaction?
- In how many clicks and seconds does a shopper want to be able to find the status of their order?
Often times, an organization needs to determine their expected performance from that of their competition. For example, Company A needs to provide an experience that is just as fast as their competitor, Company B.
Validate the production environment early in the project lifecycle
Do not leave the planning of the production environment until the last minute. Also, make sure the production environment infrastructure is working well before needing it for test so that it does not hold up the test effort.
Often times, the development environment is not the same as the environment that will be used for production. It is highly recommended that the test environment duplicate the production environment as much as possible, so that as many defects and problems can be found by testers before customers find them.
Since production environments tend to be at least slightly different from test environments, it is imperative that production environments not be left to the last minute to be designed and readied for launch. For example, the production environment may use different machine types with different amounts of memory, which means the machine and operating system needs to be configured differently. Also, horizontal and vertical cloning may be used in production, but not in test so adequate time needs to be put into the schedule to work through any issues that may arise.
Understand how to monitor and ensure the deployment is successful
- Make sure site administrators know what logs, monitors, and reports to look at
- Make sure business managers will receive the reports they need to understand revenue, profits, and results
Before deploying the WAS application, the administrators of the site need to make sure they know how to determine if the system is running well or if there are problems. The administrators then need to know what to do if issues arise.
Once the implementation has been deployed, the business folks will be anxious to see how the site is performing from a sales and revenue point of view. Business reports that highlight sales per hour or per day,
Orders or products on backorder, impact of marketing campaigns, and so on should be ready to be delivered to business
users immediately after the site is launched.
Ensure change control procedures are established and utilized
Ensure that all change requests are approved by affected parties. Change is not limited to "scope creep", but includes changes to hardware, software versions, schedules, processes, and so on. A totally sound and risk-managed project can be derailed by the best of intentions. Even when an excellent job has been done of requirements gathering and design and architecture of the site, new ideas and perspectives can be found during the project. In the attempt to overachieve, the entire project can be put at risk. A cutoff date for design change requests should be established and adhered to. Additional changes and new features can be scheduled for the next update of the site.
If you need help, ask for it
- IBM services teams can help to mentor and implement solutions. IBM Business Partners are also able to assist.
- Leverage expert skills for a design workshop, implementation assistance, migration assistance, performance tuning, and so on.
No one wants to launch a site only to discover that it underperforms, has application problems, or does not meet customer expectations.
IBMs Business Consulting Services, Software Services, or Business Partners are ready to assist. With respect to WebSphere Commerce, typical service engagements include Solution Design Workshops, Migration Workshops, Implementation Services, and Performance Tuning.
The IBM WebSphere Commerce development group also has an Advanced Technical Services team that can be engaged through IBM Software Services for WebSphere. The ATS team can provide guidance with configuring complex environments, capacity planning, and performance tuning.
(C) Copyright IBM Corporation 1996, 2006. All Rights Reserved.