By Sramana Mitra and guest author Shaloo Shalini
SM: What applications have you moved to the cloud? You have described the principle of which applications you are moving. Would you give me examples of those that fit that model?
JS: Yes, but the application names won’t mean anything to you because they are internal applications. We have moved an application that is the user admin front end to our hosted IP centrex application. It is an admin front end to be accessed by our external customers. We moved part of our Verizon enterprise center, which is the portal we give to our enterprise customers, and we have development and test environments for a couple of our heavier network systems applications out there as well. These are the things that you provision and do surveillance for our network. But those, as I said earlier, they are the test and development environments.
SM: What kind of stack are these applications being built on so that they are in a cloud-ready environment?
JS: Well, they are all either Microsoft or Linux stack.
SM: So you are using Azure?
JS: Nope, Windows 2003. We are not using Azure yet, at least in our applications.
SM: So, you don’t have any kind of platform as a service (PaaS) in your organization yet?
JS: Tell me what you mean when you say that?
SM: You know, in many similar cases where a lot of applications, especially the kind of cloud movement that you are talking about at Verizon, which are enterprise- or industry vertical-specific applications that may be your own custom applications – they are being built on platform as a service framework, whether it is Force.com or Azure or something that comes pre-packaged, and then you build your applications on top of that platform as part of moving your applications to the cloud.
JS: I see! We have not. There isn’t any in my organization, but then in the related ones nearby, there is work going on with data warehousing and business intelligence (BI) applications, using a software as a service (SaaS) or PaaS model inside the company. But the BI space is the one that people are kicking the tires on a little bit.
SM: Now, I haven’t heard you say anything about the most highly adopted public cloud applications such as CRM, talent management, or expense management. Have you adopted any of those applications, or haven’t they been touched yet?
JS: They haven’t been touched yet at Verizon. Our CRM application in the enterprise space is a very large Siebel implementation. It is one of those examples of applications that have dozens of back end interfaces, and it actually extends a lot deeper into the stack. Some of the CRM or Salesforce automation applications that you are talking about, we have looked at those. We haven’t made that move yet, nor have we done that kind of thing for talent management.
SM: There is a major switching cost involved in those application movement to the clouds, especially for large organizations, primarily because you have so much customization and deep integration there already that it does not make much business sense or in terms of cost savings. I assume ERP is the same way, right?
SM: It is too much of a headache to get to move ERP to the cloud right now?
JS: That is the thing. For a large enterprise like ours, it is very different from making such a move if you are a startup. For a large enterprise like ours, the switching cost is extraordinarily high. It is not clear that some of the applications you are talking about would actually replace the system that we already have. We are wary about just adding another system to our portfolio that takes on some of the functions but not all. By adopting a new system such as that, we would have just added another system in our portfolio without addressing all the requirements. The back end interface is a challenge for us. Remember, the equation for us is cost. If you are a different kind of a company, say you are a start-up company and you are dealing with time to market, or you are dealing with the software licensing costs where you don’t have favorable pricing, or with the talent issue in terms of bringing up applications like this, or you don’t have many other applications that you are interfacing with, all of those equations come out in a different way than in an enterprise like ours. For us it comes down to costs, with the exception of things like I mentioned earlier, such as testing and development or brand-new applications that are being into products and services. For example, the ones that we don’t sell now but will in the future, where there is no barrier where there is no entry barrier for us.
SM: Absolutely. Does the same logic apply to your e-mail infrastructure? Are you on Exchange or Lotus as one of the legacy e-mail servers? Is there is a high exit barrier to that as well?
JS: Oh, yes! We are on Exchange, and I think that those teams are looking at it and considering it. We are certainly moving in the direction of wanting to offer those kinds of services to our customers. But again, we are targeting more customers down market and in the medium and small business market that don’t want to run large applications as we do.