The Infosys global supply chain management blog enables leaner supply chains through process and IT related interventions. Discuss the latest trends and solutions across the supply chain management landscape.

« What a 3PL Warehouse contract needs to include | Main | How do I forecast during Recession? »

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 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.  

Functional View of SCM cloud

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.

Tiered SCM Cloud Architecture


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.


A very nice article. A somewhat new thought (to me) presented in a simple and interesting manner.

Thank you Hari. Please also refer to for a prequel on this one.

Nice article. My thoughts: Underlying motivation to run every process is different in different organizations. Say for example, some organizations work @ 95% service level whereas some others strive for 98%. This will have a direct impact on the way they will want the process to be executed. Indeed, Agile SCM Cloud offers promising results but there is a need for having a so called "Strategy Definition Layer", which will define strategy to call for the cloud and the "Decision Layer", which will be constantly fed by the results on previous transactions and provide business intelligence to the strategy layer.

We are still at an (intra) organization level when it comes to such implementations. The attempt is to get to the inter-organization level. Even when it comes to virtualization also you usually see its use only for an application, but the real benefits of these technologies can be harnessed when we move it to all the applications in the enterprise.

I agree with you Mayank. When to call upon a cloud must be strategized and the experience of using it can be fed back to tune the strategies. Say for example when you try to compute a transportation route, we can choose to execute the routing alogrithm which is compute intensive on a cloud. Thank you for your thoughts.

We are in SCM for decades. Just one word of caution from the experience!

A LEGO construction is bound to come down when the pieces holding together are not tightly coupled!

Even if it is tightly coupled, the ease with which the LEGO construction can be destroyed to be built again, poses dire consequences when standards are not adopted.

The cloud offers the same degree of loose coupling whether it is cloud computing or the services in the cloud or the SCM in the cloud.

As you mention, it will come down and rebuilding is difficult, and I agree. But we must also note that until recently we were lacking all the technology and the inherent standards that needed amassed before such a design. Today Intel has put out the concept of extended page tables to handle mutiple OS to handle H/W - OS decoupling.

In my opinion, this was absent in the past - a fundamental and comprehensive change to accomplish "cloud" or an "intergallactic computer" as Licklider called it. It is certainly a good time to test this out. I think.

I also like that you are indifferent to the terminology. The concept remains the same.

How is this concept different from the SaaS model ?

In essence, there is absolutely no difference.

However, as I mentioned in the prequel to this one, people tend to over define such interesting concepts and it kinda gets drowned.

Take for example Grid Computing. The concept is still being used be it SaaS or Cloud. Shockingly some CEO's say that Grid has nothing to do with Cloud.

That is why before these things get over defined, I wanted to propose something small and precise and feasible. To have a platform to develop and roll out SCM functions to customers taking care of implementation cycle, infrastructure and integration outlets. All through coordination of services in each domain with appropriate authentication and authorization.

This approach it think is a "comprehensive SaaS". I my opinion this approach will open up a whole new arena of customers - small and very small industries who cannot afford to host a server or maintain it. They will be ok with minimal customaization and basic functionalities.

A very good read. You have touched upon the most critical aspects of cloud computing in a layman's terms. I look forward to reading your next blog.

Thank you Manish. I have posted the third one. Please take a look when you get a chance.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter