Customers using IBM Enterprise Order Management System (OMS) need to upgrade to newer versions of product to take advantage over their competitors due to a number of reasons like –
- Enhance business capability of existing solution through additional out-of-the-box (OOTB) functionalities which offer best industry practices
- Avoid being outdated on technology road map which may limit operational and business scalability
- Deploy custom solution from on-premises to cloud to reduce cost and abstracted from nitty-gritties of infrastructure, hardware, environment provisioning, implementation, roll out and deployment
Nuances during upgrade of any enterprise custom OMS solution can be small to huge with business impact if not planned properly, or if implementation methodologies are not adhered in existing production solution and standards.
The objective of this article is to bring out upgrade methodology and related design considerations for OMS practitioners and business to understand various components involved during upgrade.
While planning and performing upgrade, we think why enterprise applications cannot be upgraded like any other developer or consumer utility applications by just Select Upgrade–>Hit Next–>Hit Next–>Upgraded.
A theoretical simple answer is Yes, However, this works only when business is using an enterprise application as-is without any customization which doesn’t happen in real world. Each business is unique in terms of business rules, technological stack, operational and technical maturity, transaction policies and controls, etc.
Therefore, to upgrade a running production environment with transactions which are in-flight and completed to ensure business continuity is at the very heart of upgrade. To achieve this, entire upgrade activity must be planned, streamlined and executed way different from just selecting upgrade option and hitting complete.
Below diagram depicts the various phases and respective components involved during an upgrade project
Now that we understand the methodology and components during upgrade, below are important steps and design considerations to be borne in mind while performing upgrade.
|Upgrade pre-requisites and Installation||
|Source Files Reconciliation||
|Configuration Deployment Tool(CDT)||
|IBM OMS Call Center and Store||
|IBM Field Sales||
The below table articulates the various testing elements which are needed to validate the accuracy of system upgrade:
Regarding point 3 in the above table, downtime is a total composition of elapsed time derived out of multiple sub-elements. Performing mock upgrades is critical to arrive at a better business window for production shutdown towards upgrade.
- From IBM OMS 93 version, zero down time deployment strategy can be employed to upgrade or migrate to higher versions which strategizes to have two different version of OMS running in parallel at production. Refer below for more details on staged rollout methodology
- The roll outs to new version will be used by certain small segment of business users to validate the features before larger scale fully blown version is rolled out across enterprise. This will be very useful for persona-based applications like IBM Web Store and IBM OMS Call Center.
- Design JMS clustering, which provides high availability for systems that require near-zero downtime.
- For WAS clustering across nodes requiring high availability, use WAS roll out feature to synchronize the update node by node in each cluster
- Adhere to guidelines from a UI, DB, development and customization perspective as mentioned in product documentation
- Refer sample process flow for roll back strategy
This article was co-authored by Raghuveer P Nagar.