How to reduce your odds of a successful WebSphere Commerce deployment

  1. Use technology for technology sake.
  2. Leave integration out of the original architecture design and handle it later
  3. Write a lot of code that sits outside of the customizable and flexible development framework
  4. Overuse personalization
  5. Access the database directly from JSP pages
  6. Leave unnecessary and unwanted information in the Commerce database
  7. Deploy on an unsupported software stack
  8. Deploy without using any caching
  9. Allow unnecessary or risky scope creep
  10. Reduce the amount of testing in order to contain the project launch date

 

Use technology for technology sake

Do not get over-enamored with technology. Technology is a means to an end. Use whatever technology is appropriate that matches your needs for capabilities, development time, and support and maintenance costs. Remember that customers on the Web are inherently fickle and will not tolerate slow response times or broken functionality.

Leave integration out of the original architecture design and handle it later

Commerce sites cannot operate as an island. Commerce sites should be integrated with Customer Relationship Management (CRM), Supply Chain Management (SCM), and Enterprise Resource Planning (ERP) systems. This is directly in line with the horizontal integration thought as part of being an On Demand business. When looking at integration, there are several options and alternatives and they must be weighed with respect to availability of data, response times, and performance. Because of these options and impacts, integration must be handled at the design and architecture phase.

Write a lot of code that sits outside of the customizable and flexible development framework

WebSphere Commerce is a J2EE-architected application and provides a Model-View-Controller programming model. WebSphere Commerce comes with many capabilities to help accelerate Time-to-Value: a database schema that includes customers, catalog, orders, inventory, and so on; a set of controller commands and task commands that implement business logic; a set of integration and exit points that can be used for connecting to ISV or legacy systems.

Leveraging the out-of-the-box functionality and extending and overriding Commerce capability will allow the organization to reduce the amount of time and money needed to launch the site. Total Cost of Ownership (TCO) is also lowered because the out-of-the-box code is supported by IBM where as customized code needs to be supported by the organization. And in the future, the out-of-the-box code may be improved and extended and received as a benefit of maintenance subscription, where as more money would need to be spent internally to improve and extend the customized code.

Overuse personalization

Greeting a shopper by name after logging in. Suggesting products that match a customer's buying profile. Personalization can help deliver a more intimate shopping experience that results in a greater conversion rate. Performance and response time must be considered when designing a personalized site.

That is not to say that a highly personalized site cannot perform; it just takes planning, proper configuration, and appropriate use of technologies and tools. For example, use Dynacache and its ability to cache JSP fragments, use of Edge Server technologies, and providing enough resource (CPU, RAM, fast hard drives) to handle the load

Access the database directly from JSP pages

WebSphere Commerce uses Enterprise Java Beans (EJBs) for data persistence and data beans for data retrieval. The WebSphere Commerce runtime manages transactions and whether to commit them or roll them back. If you update the database from within a JSP page using JDBC, then you are circumventing WebSphere Commerce's programming model and could cause deadlocks or data inconsistencies.

Leave unnecessary and unwanted information in the Commerce database

You can publish a WebSphere Commerce starter store with a sample catalog or without a catalog at all. When publishing a starter store to look at the out-of-the-box features, it is a good idea to publish one of the sample catalogs to see how the pages display and handle the data. When building the actual store that will go live, it is highly recommended to publish the starter store without a catalog. We have seen some of our customers who have either published sample data or created test data of their own and forgot to remove them from the catalog before the official launch. And sometimes, you cannot see the catalog data when navigating through the category-hierarchy, but sometimes they can be found when doing a keyword search. If the database is clean on the day it is launched, then running Database Cleanup utility periodically should not require a lot of time or system resource. Database Cleanup utility should be used regularly to remove guest customers and their abandoned shopping carts and to remove marked-for-delete items from the database.

After running Database Cleanup utility, the database statistics should be updated so that the query optimizer can efficiently optimize SQL queries based on correct information about the amount of data in each database table.

Deploy on an unsupported software stack

A solution based on WebSphere Commerce can contain many individual software applications: WebSphere Application Server, a database, an HTTP Server, an LDAP Server, Lotus QuickPlace, Lotus SameTime, Lotus Domino, IBM Content Manager and so on. It is very important to make sure that the combination of software applications has been tested and is fully supported by IBM. If there is any doubt or question about whether a certain combination is supported, contact IBM support.

Deploy without using any caching

Again with the caching. This is the last reminder to use caching where possible. Through our internal tests between a starter store that is not using Dynacache and the same one that is, we have been able to double throughput and to cut response times by 50%. Of course this assumes, that an appropriate amount of memory is available for caching and that no other part of the system becomes the bottleneck (such as the database) as throughput doubles.

Allow unnecessary or risky scope creep

Without good project management skills and a project change request (PCRs) process that can be implemented and followed, scope creep is inevitable. But Commerce site should not be seen as a one-time activity to launch the site. Web sites are constantly being updated to react to competition, to make the site more compelling, and to implement suggestions from customer feedback. New ideas that arise during the project can be held over to a future update of the site. And one should look at incremental roll-outs of small bits of functionality that can be done during regular maintenance windows. A site can evolve over time, it does not need to change in large heralded steps.

Reduce the amount of testing in order to contain the project launch date

Remember that you only have one chance to make a first impression. Launch dates are important as they are normally tied to marketing and sales activities. Equally important is to launch a site that will perform as expected by both customers and the developers.

We have seen too many customers who have compromised their test plans in order to contain a launch date. In some cases, the launch date should have been moved. In other cases, the project plan should have had a larger buffer due to the risks involved.

The System Integration Test ensures that the entire solution from start to finish works together as expected. Can data be loaded into the system, customers see the data and make a purchase, and orders be fulfilled and shipped to the customer?

The Stress Test ensures that the site can handle the expected number of customers performing the expected customer scenarios. As customer traffic increases, do you know what part of your system will be maxed out first and be the limiting factor in your deployed solution?

Related reference

(C) Copyright IBM Corporation 1996, 2006. All Rights Reserved.