How to increase the success with WebSphere Commerce deployment
Use best practices will increase the success with deploying WebSphere Commerce.
- Do not use technology for technology sake.
- Make integration part of the original architecture design
- Do not write a lot of code that sits outside of the customizable and flexible development framework
- Do not overuse personalization
- Do not access the database directly from JSP pages
- Do not leave unnecessary and unwanted information in the WebSphere Commerce database
- Do not deploy on an unsupported software stack
- Do not deploy without using any caching
- Do not allow unnecessary or risky scope creep
- Do not reduce testing to contain the project launch date
Do not use technology for technology sake
Keep the Web site simple.
Remember why the customers are coming to the site and ensure all technologies are being used to help strengthen that relationship For example, do you need streaming video, audio, flash, pop-ups, blogs and so on.
Do not get over-enamored with technology. Technology is a means to an end. Use whatever technology is appropriate that matches the 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.
Make integration part of the original architecture design
Integration options affect architecture, performance, and capability. Take integration considerations into account from the start of the project.
Commerce sites should be integrated with...
- Customer Relationship Management (CRM)
- Supply Chain Management (SCM)
- Enterprise Resource Planning (ERP)
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.
Do not write a lot of code that sits outside of the customizable and flexible development framework
WebSphere Commerce provides an approach to customize, extend, and replace key functionality.
Do not write code that works independently of, or against, WebSphere Commerce.
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. In the future, the out-of-the-box code can 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.
Do not overuse personalization
It is important to separate static as opposed to personalized content into different fragments so that different caching strategies can be used.
A balance needs to be struck between personalization and performance.
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
Do not access the database directly from JSP pages
All database access should use the Model-View-Controller implementation
Do not attempt to manage transactions and rollbacks within the 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.
Do not leave unnecessary and unwanted information in the WebSphere Commerce database
The Database Cleanup utility will take longer to run as it removes data that could have been removed before the launch
Customers can see some of this data
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.
Do not deploy on an unsupported software stack
Read and follow the pre-requisites and supported software configurations
The combination of Application Server, HTTP Server, LDAP Server, Database Server, Operating System is critical to get right
A solution based on WebSphere Commerce can contain many individual software applications: WebSphere Application Server, a database, an HTTP Server, an LDAP Server, 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.
Do not deploy without using any caching
WebSphere can cache dynamic full-page and fragment JSP pages. WebSphere Commerce can also work with Edge technologies.
Use of caching can increase throughput by 100% and cut response times by 50%.
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.
Do not allow unnecessary or risky scope creep
Commerce Web sites are not a one-shot deal.
Web sites should be under constant improvement as the business seeks to grow customer relationships and capture opportunities. Hold off late requirements until the next update of the site.
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.
Do not reduce testing to contain the project launch date
System Integration Test and Stress Test are the most important tests as they ensure you can handle expected customer traffic and behavior.
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 the system will be maxed out first and be the limiting factor in the deployed solution?
Related reference
Top 10 tips to ensure a successful deployment of WebSphere Commerce
WebSphere Commerce deployment checklist