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