AGILE SCM CLOUD – Why do we need one?
Because we do. Is it that simple? No way.
I guess the answer to this question manifests when we take a close look at any SCM application environment and the landscape of the hardware and software technologies associated with it and the amount of effort required to integrate these applications.
For example: Let us consider the case of a major online retailer (similar to Amazon.com). Let us also assume, he wants to use ATG for order capture and Sterling as a background application for order management. Given the scenario (which BTW is one of the simpler scenarios in SCM domain), there is a host of solution design decisions to be made now; Choosing ATG and Sterling for order capture and management, database for both of these packages, and middleware to integrate these packages. Versions of each of these components will further induce certain restrictions that do not necessarily ease the problem at hand because each component is equally responsible to meet the overall SLA – response time (for UI), throughput (for batch mode). Throw in the infrastructure options to host each of the aforementioned components, hosting costs and HA and DR considerations, the problem gets transported to an all new tangent of heterogeneity.
At the crux of these options/complexities the online retailer just needs a product to showcase his inventory, capture orders, fulfil and manage the orders. The product should be highly available and disaster proof. It should scale to meet the growth in customers, vendors and inventory.
Wait a minute that is what SCM Cloud offers - “a set of services that provide SCM functions to any cloud user in an efficient, scalable, reliable and secure way”. That is, Cloud masks all the heterogeneities involved in implementing various SCM functions and the tiers within each function and provides a purely functional view rather than having to deal with the inherent technologies. The following illustration provides this functional view with users enrolling (based on the SLA) to different SCM functions rather than JDA-TMS or Sterling-DOM.
This view of the cloud makes us, the service providers the best ones to take the cudgel to implement the CLOUD. We must therefore prepare a pool of requirements and a pool of plausible technologies and create a layer of abstraction to free the user from choosing packages, best-of-breed solutions, databases, integration middleware, and infrastructure and think only about the required functionality and how much he can/should pay for it. Here is a simplified tiered-illustration of SCM cloud components.
Of course the biggest of all challenges in realizing this cloud is security. How do we isolate one user (from one enterprise) using the cloud from another user (from another enterprise). Of course all tiers. All the way down to persisting data. We have the technology to device such a model. For example a security vault that based on the SLA and user credentials internally instantiates a virtual machine for order capture and links appropriate data sources.
Oops!! I am just getting ahead of myself. Aren’t I? You just have to wait for my next blog guys.