Jim Stikeleather: [Consolidating] becomes much more manageable when you start thinking about moving to the cloud because the problem cloud brings you, it’s not terribly unlike the late 1070s and the early 1980s when PCs were starting to be used on a mass scale by companies. They came in, and we’ve got the same problem with cloud and utility computing: You have individual departments running SAS applications, you have individual departments running applications on the Amazon, so it’s less getting the cloud and less about getting control of the hardware than it is starting to rationalize your application portfolio.
Anyway, we’ve gone through the virtualization process, and now we are starting to move into the private cloud model. The difference with virtualization and the private cloud virtualization is of multiple instances of servers going on a single server when you start going to private cloud. You start taking all of these servers and begin looking at them as a single resource pool, and now you can start moving workloads around that pool and around the different servers that are available to you.
That’s really how the private cloud starts you down the process. At that point I virtualize the servers’ tasks, things running, and I can take all the physical servers, pull them together, and create. You have a bigger pool of sharable resources. You also start doing things like virtualizing. If you are just doing virtual servers, you’re basically [revitalizing] your compute capability when you start moving through a private cloud module. You start to virtualize your storage and your networking modules as well. That’s the next step and a process we are going through right now.
Sramana Mitra: You also consolidated applications. Has there been a cloud strategy in that application consolidation?
JS: Immediately [there was not a comprehensive] cloud strategy in it, although for example we are one of the largest customers of Salesforce.com. We do have and we are consuming cloud products and services from the outside. We also offer cloud services ourselves; we have one product which is SaaS for email. We have our Silverback product, which is SaaS for systems management.
Again, what we are doing as part of Dell and Dell’s strategy is beginning to consume our own SaaS offerings. Two things one to learn how to do it but second the better offers the better to our customers and the long range model is to get to a true utility in which you know whether you are running on your own hardware or somebody else’s hardware that really at that point you’re just managing the workload.
To start from scratch and say OK, we are going to move everything to the cloud is foolish because there are some applications that just aren’t written [that way] and it would be ineffective in a cloud model. What we think is that over time what will happen is people will quit doing maintenance and upgrades to those and instead out bore them with either software as a service capabilities or architecture capabilities or some type of mash-up wherein you are mixing what your legacy system does with the new systems. Over time, the legacy systems that can’t be moved to the cloud will fade away. So, it’s more of an evolutionary strategy than a directed strategy.
SM: Now, that statement you just made that legacy systems that would not move to cloud are going to fade away – you have very serious legacy systems like ERP systems and MRP systems and so on. Those systems, I have to believe, are not in the cloud right now. Is it?
JS: No, those are not in the cloud right now. What you have is, over time, the models of at least enterprise software becoming increasingly “modelistic” and putting increasing functionality into a single code line. You saw the growth of that [in the rise of programs] like SAP and the work of financial and civil CRM systems.
What’s happening in the cloud is almost the exact opposite; what the cloud does is take a lot of economic friction out of the software business. What you have then is an upswing, if you will, of very small, narrow functionality deep domain knowledge [of] software programs’ service applications. It’s highly specialized because Dell can create a company of just a few employees and maybe do something very specialized, such as accounts payable for Eastern European job shop manufacturers using rubber technology for export to the Middle East. There are maybe six companies in the world that do that, but economically I can create a viable company servicing them with that specialized piece of software. What you see is really an Anderson long-tail effect wherein highly specialized, unique, highly differentiated deep domain knowledge of a software program’s service applications are coming onto the marketplace. Rather than being acquired by IT to service the entire company, this is being acquired by individual departments inside of an organization to serve specific needs. Thus, the IT role will become one less one of managing a monolithic ERP system to one of coordinating the integration of all these different SaaS applications. That’s the game of what’s going on.