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.

« DNA Therapy for Strategic Cost Reduction in Supply Chains | Main | An Approach to Effective APO Demand Planning Design »

Agile SCM Cloud - How to implement one?

In the previous two blogs I have talked about the possibility of creating a cloud of SCM functions and commoditizing’ em to relieve the user from the tedious task of choosing, procuring, implementing and customizing SCM functions for his business. The general trend these days with the advent of grid and cloud computing is to focus more on the application and its use for the business rather than worry about scalability, reliability and security which are now an integral part of the cloud offerings.

Web based companies like Amazon and Google have already realized the potential of such offerings and have their own version of Cloud Infrastructure to-let for a host of different customers. For example, anywhere from a huge oil and gas company renting the infrastructure to process a portion of their new-energy-source-data-set to a small start-up that need not procure any hardware to keep its IT budget low. So what is new about the SCM cloud?

N-Tiered Applications: What the Elastic Cloud provides is the base infrastructure. Almost exactingly SCM applications are multi-tiered in nature comprising of applications, application containers, databases, intra and inter application communication buses and so forth. In other words, we would need Sterling DOM 8.0, WebSphere Application Server, 6.1 Oracle 10G, IBM MQ 6.1 etc on the cloud to be able to host ‘Order Fulfilment’ function on the cloud.

Licensing Model: I think service providers like Infosys should take the cudgel of getting a variety of vendors who fill the SCM space to sign-up on the cloud. We need a licensing model to translate a cloud user subscription to licensing cost for the application stack he uses. IBM shook hands a couple of weeks back with Amazon to host some of its products on the cloud, which in my opinion, is almost a testimonial to this thought.

SCM Function Instance (inspired by Amazon machine images of course): We also need a unit of measure to charge the user who subscribes to the SCM functions. This must be a composite cost for the infrastructure and the cost for the application stack for different products involved in rendering the SCM function.

Edgy Features: All the points I have discussed thus far will just give us the ability to host some SCM functions on a bed of unceasing infrastructure – the rudimentary SCM cloud. So what gives us the vantage point? Really cool features like the following: 

Role based access to SCM functions – distinguishing the business A users from enterprise Z and business A admin from business A end user with only one time authentication and authorization. 

Customization at a cost – providing the user an ability to further customize the SCM function offerings to suit his business. For example: if it is a Manhattan forecasting function the user is subscribing to, we should give him the ability to define the input parameters for forecasting. 

Seamless integration – End user should not distinguish the parts of his application/portal that are hosted on the cloud and from the ones that are hosted in-house. The same criterion applies to the batch mode of communication between SCM functions on the cloud and other in-house applications. Perhaps the ability to integrate SCM functions to subscriber’s ESB. 

Subscription Catalogue and its granularity – User should be allowed to choose different SCM functions and define his own application stack by providing him the ability to choose vendors for every tier of his application stack.

Mix all these ingredients and bake it at 375 degree Fahrenheit for 30 minutes and the SCM Cloud is ready!

This vision has a lot of potential. I think. It is a win-win for the infrastructure vendors, SCM product vendors, service providers and the users. In the reverse order, users because they get TCO benefits, service providers because they are the facilitators of this idea, SCM product vendors and infrastructure vendors because the cloud has opened gates to a legion of user. 

Taking it to the next level, IT developers/free lance developers can come-up with their own ideas and host it as a service on the cloud and get paid as the users sign-up. For example, a forecasting rule engine. Users can only use what they want for as long as they want. I can prepare all the inputs for a forecasting function and use it once every quarter to generate the demand forecast and unplug from the forecasting function. If vendor A forecasting did not work well the first time he can choose vendor B the next time.

In essence, ignite your whims and fancies guys and it is possible!!


A company will go to the cloud only to avoid capex investment for temporary computing requirements such as for ad-hoc runs of utility applications such as data transformation.

Supply Chain applications (both planning and execution) support core business processes that are complex, custom, and functionally rich. Since even a mid-sized company needs to devote permanent resources to this, how do they benefit from going to the cloud?

Today the companies are very hesitant about this model of running custom applications and storing data in a shared environment. But it won't be the same tomorrow. There are already a lot of production applications hosted on Amazon for instance.

Further, capex benefits and adhoc processing are not the only two driving factors for cloud. In SCM, we are seeing customers requiring us to host the infrastructure and implement SCM solutions as a platform. So, we as service providers have the onus of raising the infrastructure and building the application stack for them.

What I propose here need not use Amazon EC2 or Google's AE, it could be an intra enterprise cloud, or a cloud hosted at our site for someone else. In the former, the enterprise is its own cloud provider in the latter, we are the cloud providers.

I wanted to focus more on the scalable architecture that moves away from the traditional app-on-a-OS-on-a-processor approach. The roles of cloud providers and subscribers must be decided on a case-by-case basis.

Amit, Further cool features like Google's Secure Data Connector will alleviate all the tension around data security (

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