The coming WebSphere Commerce Upgrade Imperative
IBM has announced end-of-support for its IBM WebSphere Commerce v7.x version. The D-day is end of April 2019. Extended support is until December 2021, but that requires a separate contract and comes with a price. For omnichannel retailers across the world, therefore, a platform upgrade/migration imperative is just around the corner. Most have to begin the journey at some point over the next few months and quarters. By our reckoning, 85% of the IBM WCS installed base is on v7.x. Therefore a large proportion of the WCS community will first have to decide whether to migrate to v8.x or v9.0 and take the first steps towards what would certainly be a major upgrade.
When a major platform partner announces an end-of-life decision it is a fait accompli, an imposition an enterprise cannot do much about. It (justifiably) feels like a needless disruption of business-as-usual. However, the good news is that the IBM WebSphere Commerce v9.0 represents a major architectural departure from the past and introduces a set of changes that collectively work towards easing deployment and ongoing management. The improvements are considerable and span microservices, Dockerization, independent scaling of components; easier, less intrusive customization; and a headless architecture that affords considerable latitude on how the storefront is designed, built, and maintained.
Microservices and Dockerization. Retailers all over the world are working on breaking out of their legacy monoliths, reducing the size of deployment units to achieve agility, essential to competing in the age of Amazon. The platform vendors have finally begun to answer the siren call and take specific steps to re-architect their platforms. A great exemplar of the above is WCS v9.0. The product comes in the form of five distributed servers, the transaction server, the search server, the utility server, the extension server, and the store server — and each ships with its own pre-configured Docker image. The five can all be independently managed and scaled, and of course the Docker-based approach aids DevOps automation. The distinct components communicate through REST APIs. The principle of smaller and independent deployment units have been extended to ongoing maintenance. Upgrades and fixes will be provided as Docker images as well. IBM self-describes the transition from the earlier monolith as an implementation of the well-known Strangler Pattern.
Novel approach to customization. Customization is now externalized from the out-of-box code and part of the xC (which literally expands to externalized customization) framework. Custom business logic can be deployed on a separate server, which eases the process of ongoing management, such as applying fix packs and feature packs. xC furthers the cause of CI/CD as changes to custom code would not necessitate testing of the out-of-the box code. The xC approach does not support all scenarios currently, but the list is expected to grow. Also, traditional customization is still supported, though use of both xC and the traditional model in the same implementation is not recommended.
Headless architecture. The store server has been decoupled from the customization, transaction, and search servers, and communicates with the rest of the platform via REST APIs. The store server can now be managed and scaled independently. Also, enterprises can use powerful content management systems such as the Adobe Experience Manager or the Watson Content Hub to build personalized storefronts that are powered by REST APIs.
Evolution of the technology stack. Version 7 was a long time ago. It went GA in 2009. As would be expected, the building blocks are now more contemporary. The WebSphere Application Server has been replaced by the WebSphere Liberty server, which is lightweight , has a smaller server footprint, and would requires less infrastructure capacity (the transactional server is still on the WebSphere Application Server). Beyond the open source Liberty server, other points of modernization have been introduction of JPA instead of its heavy weight counterpart EJB and JQuery in lieu of the Dojo toolkit. The Aurora starter store, which ships out of the box, has been completely rewritten in JQuery.
Lastly, the path to WCS v9 upgrade will vary from customer to customer. There are a two main approaches that can be considered, namely the complete platform engineering way and an initial lift-and-shift approach adopting minimal architectural changes mandated for WebSphere Commerce v9 which would then lead to iteratively adopting other architectural and functional capabilities of the WebSphere Commerce v9 platform. The appropriate upgrade path can be adopted based on the output of the detailed assessment of the current state as well as business requirements.
Why Litmus7? First, you will be hard pressed to meet a technology firm more retail focused than us. We serve some of the largest, most well-known, and sophisticated omnichannel retailers in the world. Retail is 100% of our business and all our clients are marquee names. Second, our IBM WebSphere Commerce practice is battled hardened, with implementations at large retailers. We have worked in both B2C and B2B environments in the WCS domain. Our WCS engineers average over eight years’ of industry experience. Next, we are intimately familiar with architectural concepts that underpin the new platform. We recently drove a microservices implementation at the Canadian division of a very large omnichannel retailer, enabling a paradigm shift from a proprietary merchandise model to a market place model. The shift saw SKU volume grow 200k to 1 million. Lastly, we have built a repeatable methodology for the v9.0 migration with the appropriate utilities and tools. If you engage with Litmus7, you will be dealing with a well-equipped veteran of many a ecommerce platform migration.
