How to increase your success with WebSphere Commerce deployment
Use these tips and best practices to help you successfully deploy WebSphere Commerce.
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
- Your targeted email campaign has already been sent out
- And your in-store signage has already been set up promoting cross-channel offers.
Use these tips to avoid this scenario.
- Ensure that the business and technical teams are involved from the beginning and that they communicate throughout the process
- Include integration in your original architecture design rather than waiting to address it later
- Do not use technology just for its own sake
- Start with a solution outline that maps requirements to the features provided with the WebSphere Commerce product
- Do not write much code that sits outside of the customizable and flexible development framework
- When you design the site, storyboard and mock up the business flows
- Do not overuse personalization
- Do not access the database directly from JSP pages
- Understand expected peak performance characteristics and ensure that the system can meet them
- Develop well-tuned SQL queries and table indexes from the start
- Do not leave caching as an afterthought; include it as part of your initial site design
- Ensure that you deploy on a supported, up-to-date software stack
- Validate the production environment early in the project lifecycle
- Remove unnecessary and unwanted information from the WebSphere Commerce database
- Do not allow unnecessary or risky scope creep
- Do not reduce testing to contain the project launch date
- Understand how to monitor deployment and ensure that it is successful
- Ensure that change control procedures are established and enforced
- If you need help, ask for it
Ensure that the business and technical teams are involved from the beginning and that they communicate throughout the process
The business and technical teams must agree on the approach, implementation, schedule, and deployment strategy. Encourage both teams to actively participate in the design of the site. With both parties represented, the technical team can understand the business drivers and goals, and the business team can understand the technical limitations and costs.
Include integration in your original architecture design rather than waiting to address it later
Integration options affect architecture, performance, and capability. Integration is a key component of the solution outline. Take integration considerations into account from the start of the project.
Commerce sites cannot operate in isolation. Commerce sites require integration with Customer Relationship Management (CRM), Supply Chain Management (SCM), and Enterprise Resource Planning (ERP) systems. These interactions correspond to the horizontal integration that is part of being an on-demand business. When you consider integration, examine your options to determine how they affect the availability of data, response times, and performance.
Do not use technology just for its own sake
Keep your website simple. Remember why your customers come to the site, and ensure that all the technologies you use help strengthen that relationship. For example, do you really need streaming video, audio, flash, pop-up windows, and blogs?
Technology is a means to an end. Use only the technologies that match your needs for capabilities, development time, and support and maintenance costs. Remember that customers on the Internet are inherently fickle; they do not tolerate slow response times or broken functionality.
Start with a solution outline that maps requirements to the features provided with the WebSphere Commerce product
WebSphere Commerce includes a many features and supports best practices. Where your requirements do not match the capabilities of features WebSphere Commerce provides, consider changing your processes and adopting new best practices that use these features. Follow these steps:
- Determine which business model best fits your organization's business plans: B2C, B2B, Extended Sites, Partner Relationship Management, Supply Chain, or Demand Chain.
- Examine the starter store that is associated with the chosen business model. Determine which of its features to use, which to remove, and which features you must add. It is easier and less expensive to start from one of the starter stores than to build a store from nothing. The starter stores are provided by WebSphere Commerce as a starting point to accelerate Time-to-Value.
- Consider data load or mapping early in the project. Which of the tables that are provided by WebSphere Commerce do you want to use and what new tables do must you create? How will the tables be loaded initially and then incrementally over time? What is the source of the catalog data and is it appropriate to display to customers, or does it need some cleansing or transforming first?
Do not write much code that sits outside of the customizable and flexible development framework
Do not write code that works independently of WebSphere Commerce, or against it. Instead, you can customize, extend, and replace key WebSphere Commerce functionality.
- A database schema that includes customers, catalog, orders, and inventory
- 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 existing systems.
Reduce the amount of time and money that is required to launch your site by leveraging the functionality that comes with WebSphere Commerce, then extending and overriding its capability. Total Cost of Ownership (TCO) is also lowered because the provided code is supported, and later migrated, by IBM, whereas customized code must be supported and migrated by your organization.
When you design the site, storyboard and mock up the business flows
It is difficult to explain in words how a store page will look and how it will be used by shoppers. Reduce ambiguity and increase understanding by using the documented business process flows and building HTML mock-ups. Often, the person who describes the page, the person who implements the page, and the person who builds the test plan around the page interpret the written words differently. Screen mock-ups and business process flows can significantly reduce ambiguity and ensure a common understanding.
Do not overuse personalization
You must incorporate personalization requirements into the design to ensure the solution meet performance objectives. Understand the performance and potential capacity cost of the level of personalization you plan to include. It is important to separate static content, as opposed to personalized content, into different fragments so that different caching strategies can be used.
- Greeting a shopper by name after the shopper logs in.
- Suggesting products that match the buying profile of each shopper.
Do not access the database directly from JSP pages
Use the Model-View-Controller implementation for all database access. Do not attempt to manage transactions and rollbacks within the JSP pages.
WebSphere Commerce uses Enterprise JavaBeans (EJBs) for data persistence and data beans for data retrieval. The WebSphere Commerce run time manages transactions and controls whether to commit them or roll them back. If you update the database from within a JSP page using JDBC, you circumvent the WebSphere Commerce programming model, which can cause deadlocks or data inconsistencies.
Understand expected peak performance characteristics and ensure that the system can meet them
Establish peak performance characteristics, such as throughput and response time, at the beginning of the project. Before the site is launched, test to make sure the site performs as expected.
For a WebSphere Commerce site, determine:
- How many times are prospective shoppers willing to click to find the products they seek?
- How many seconds or minutes is a prospective shopper willing to spend between starting and completing a transaction?
- How many clicks and seconds is a shopper willing to expend to learn the status of an order?
Often, an organization must determine their expected performance from the performance of their competition. For example, Company A must provide an experience that is as fast as their competitor, Company B.
- Peak hour order volume (orders per hour)
- Average number of items per cart
- Peak hour page views (pages per hour)
- Unique visitors for the peak hour
- Promotions and personalization planned for the special event
Develop well-tuned SQL queries and table indexes from the start
Incorporate performance considerations up-front when you build SQL queries and database tables. Do not leave performance tuning as an afterthought.
WebSphere Application Server applications typically use databases to store and persist data. SQL queries are used to retrieve information from a database that is used as input for decisions, and then displayed to the shopper. Review SQL queries early for performance. If the review reveals performance deficiencies, you can rewrite the query, add new indexes to the database, or modify the original table to increase performance. Design performance into the application, rather than waiting to add performance improvements in response to bad performance test results. Since the SQL access plan changes depending on data, it is critical to test the SQL performance with realistic data.
Do not leave caching as an afterthought; include it as part of your initial site design
A website can draw millions of visitors per hour, and each visitor can view tens of pages during a visit. If each page is dynamically generated and accesses the database for information, the load on the application and database server can be significant. Slow responding pages could mean lost business revenue when shoppers are turned away before completing their purchase.
WebSphere Commerce supports full-page caching and fragment caching using DynaCache, the dynamic cache that comes with WebSphere Application Server. WebSphere Commerce also works with Centralized caching grid such as WebSphere Extreme Scale and Edge Caching technologies. When you storyboard your site, determine which parts to cache, and where to cache them to maximize the reduction of traffic to application and database servers.
WebSphere Commerce ran tests between a starter store that uses DynaCache and the same store without DynaCache. In the tests, the store with DynaCache had up to double the throughput and response times were reduced 50%. These tests assumed that an appropriate amount of memory was available for caching. They also assumed that no other parts of the system was a bottleneck when throughput doubled.
A critical part of creating a caching strategy is to consider invalidation. To ensure that correct content is displayed to shoppers, cached objects must be invalidated when the data changes. Forming your invalidation strategy is a collaborative exercise between IT and Business teams. Although you might initially decide to invalidate all content as soon as it expires, excessive invalidation can reduce the effectiveness of caching. An important guideline for invalidation is to leverage as much event-driven invalidation as possible. Invalidate data only as they change, rather than relying on time-based invalidation, which might remove unchanged entries.
For more information about caching, see the Dynamic caching section.
Ensure that you deploy on a supported, up-to-date software stack
Read and follow information that is provided about prerequisites and supported software configurations. It is critical that you have the right combination of application server, HTTP Server, LDAP server, database server, and operating system.
A solution that is based on WebSphere Commerce can contain many individual software applications, such asWebSphere Application Server, a database, an HTTP Server, an LDAP Server, and IBM Content Manager. It is critical that you have the right combination of software applications. Ensure that your combination is fully tested and that it is supported by IBM. If you are not sure whether a certain combination is supported, contact IBM Support.
IBM also publishes updated fix packs to its products. Be proactive by developing deployment strategies that ensure you are on the latest fix pack levels. Installing the latest fix pack ensures that you have the best coverage of fixes, and that you receive any potential feature and performance gains.
Validate the production environment early in the project lifecycle
Do not leave planning of the production environment until the last minute. Make sure that the production environment infrastructure works well before you need it for testing so that any issues do not hold up the test effort.
Usually the development environment is not the same as the environment that is used for production. However, it is best that the test environment duplicates the production environment as much as possible so that as many defects and problems as possible can be found by testers before customers find them.
If differences between the test environment and the production environment are unavoidable, do not wait to the last minute to design the production environment and prepare it for launch. For example, the production environment can use different machine types with different amounts of memory, which require the machine and operating system to be configured differently. Another potential difference is that horizontal and vertical cloning, which can be used in a production environment but not in a test environment. If you plan to use cloning, you need adequate time in the schedule to work through any issues that arise.
Remove unnecessary and unwanted information from the WebSphere Commerce database
If you do not remove the unwanted data before you launch your store, there is the risk that customers might see some of it. When you publish a starter store to look at the features that are provided, also publish one of the sample catalogs to see how the pages display and how data is handled. When you build your actual store, you can publish the starter store without a catalog. If you publish sample data or created test data of your own, do not forget to remove the data from the catalog before you officially launched your store. Even if you cannot see the catalog data when you navigate through the category-hierarchy, the data might be found if customers do a keyword search.
Use the Database Cleanup utility to remove data before you launch your store. Continue to use the Database Cleanup utility regularly to remove guest customers, their abandoned shopping carts, and marked-for-delete items from the database. If the database is clean on the day it is launched, then running the Database Cleanup utility periodically does not require much time or system resources. When you run the Database Cleanup utility, database statistics are updated. Update statistics ensures that the query optimizer has the correct information about the amount of data in each database table, so that it can efficiently optimize SQL queries.
For more information, see Database Cleanup utility.
Do not 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. However, launching a Commerce website is not a one-time activity, so new ideas that arise during a project can be held over to a future update. Websites undergo constant improvement, as the business seeks to grow customer relationships, capture opportunities, react to the competition, and react to customer feedback. Consider holding off late requirements until the next update of your site, rather than adding them to the current update late in the cycle. Incremental roll-outs of small bits of functionality can be done during regular maintenance windows, so that the site can evolve over time.
Do not reduce testing to contain the project launch date
System Integration Test and Stress Test are the most important tests as they ensure that you can handle the expected customer traffic and behavior. Ensure that project plans contain a buffer to that there is time to test.
You have only one chance to make a first impression. Launch dates are important, as they are usually tied to marketing and sales activities. However, do not compromise your test plans to contain a launch date. It is equally important to launch a site that performs as expected by both customers and the developers. Sometimes you must move a launch date to ensure that the site is ready.
The System Integration Test ensures that the entire solution from start to finish works together as expected. Can data be loaded into the system? Can customers see the data and make a purchase? Can orders be fulfilled and shipped to the customer?
The Stress Test ensures that the site can handle the expected number of customers who perform the expected customer scenarios. As customer traffic increases, do you know what part of your system will be maxed out first? What is the limiting factor in your deployed solution?
Understand how to monitor deployment and ensure that it is successful
Ensure that site administrators know which logs, monitors, and reports they need to look at. Make sure that business managers receive the reports that they require to learn about revenue, profits, and results.
Before you deploy the WebSphere Application Server application, the administrators of the site need to make sure that 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.
- Business reports that highlight sales per hour or per day
- Reports of any orders or products on backorder
- Information that shows the impact of marketing campaigns
Ensure that change control procedures are established and enforced
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, and processes. A sound and risk-managed project can be derailed by the best of intentions. Even when you carefully gather requirements for the design and architecture of the site, new ideas and perspectives can arise during a project. In the attempt to achieve more, you can put the entire project at risk. Establish a cutoff date for design change requests and adhered to it. 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, and performance tuning.
No one wants to launch a site only to discover that it underperforms, has application problems, or does not meet customer expectations.
IBM Business Consulting Services, Software Services, or Business Partners are ready to assist. For WebSphere Commerce, typical service engagements include Solution Design Workshops, Migration Workshops, Implementation Services, and Performance Tuning.