By Sramana Mitra and guest authors Shaloo Shalini and Bhavana Sharma
SM: In the discussions we just had, it sounds like there are external vendors involved in your deployment of cloud-based solutions. What is the process, or what are you looking for in terms of key requirements for adoption and deployment of cloud computing solutions within CA? What do vendors need to be aware of?
DF: Well, again, there is no single thing we have look for in cloud vendors. When we started to figure out what our cloud portfolio of products should be and what products we need to build to manage cloud computing, the team came up with an acronym called QUARCS. It stood for Quality, Agility, Risk Capability, Cost, and Security.
Currently, I think what we look at for cloud services varies from one cloud service to another. In the Amazon EC2 case, it’s clearly cost. Amazon EC2 would not score well on any of the other matrices such as risk. Amazon EC2 won’t tell you what your capacity is going to be, and they won’t sign on a service owner contract.
When we use an external partner and we call their APIs or something such as that which benefits overall management, we are focusing primarily on capability. What is the capability of the provider and what is the cost? It is not just the IT cost but the actual per employee cost, and it tends to vary.
As we roll up all the QUARCS stuff into something we call a service measurement index, part of the model we have for our cloud management products is that over time, people will score internal enterprise IT services as well as actual external cloud services using these matrices and then make decisions about which one to use and what to trade off, so to speak. Our approach is to score the vendors, and then for a particular service you weigh the various aspects of QUARCS. But I would say the vast majority of it is currently capability and cost.
SM: Let’s take the cost parameter. What are your thoughts about the new business models that have evolved with cloud computing? Looking at ROI, how do you view the different business models, and what are your preferences for business models?
DF: Well, there are two ways to look at that question. The first is, what is our preference for business models when we use cloud providers? The second is, what business model do we view or think about when we offer our products visa SaaS? I would deal with the second one.
I think the direction that we are going in with most of our products is a metered approach. It is not a software licensing approach. It is based on the nature of the product that we have. When we talk about IT management products and the people who use these products, we sometimes use the term “front office and back office.” A front office is like an employee in a company who is using service desk because that person are having an IT problem or is participating in a project plan. The back office is somebody like the IT administrator who is actually trying to solve the problem. Products that are heavily front office tend to be more amenable to SaaS because they have less interaction with the on-premise physical IT systems – for example, they are not monitoring routers. Products like NetQoS that perform monitoring the on-premise network cannot be initial candidates for SaaS. So the products that we do via SaaS are things like Agile Planner, Clarity, and so forth. Those tend to be metered, and they way we tend to meter them is per user. A typical customer signs up on per user contract and pays a certain amount per user.
SM: Is that per concurrent user or per named user?
DF: I think it is primarily per named user.
SM: Does it matter whether that named user is using it or noy? Do they still have to pay for it?
DF: I believe that is the approach. I will have to go back and check. I don’t know off the top of my head, but I believe that it’s per named user.
SM: What happens when you buy a cloud-based solution, say when CA is buying cloud services from other vendors? What business models do you prefer? Does the same logic apply in that case?
DF: It does. When CA is a consumer of cloud services, we are acting almost like any other enterprise, so we are behaving like our customers. Our customers have certain expectations when they deal with us as a software provider. When we are getting cloud services from other vendors, we are actually functioning inside the firewall. The actual model varies, though. For instance, we host a lot of things on places like Rackspace. That is almost like a hardware lease model, not the user model. When we go to things like Salesforce, it tends to be some combination of user and usage. Since we are a big company, the contracts that we have tend to have both the concurrent usage and named user. If you look at something like Salesforce or if you look at other cloud providers, a lot of cloud providers are this funny mix of business models. It is a cloud provider because it has APIs that we can call. But it is also business process outsourcing. So, we are using their APIs as a way of building applications that expand into the cloud and supports our business processes. But the primary relationship is termed by the business conditions.
SM: Let’s visit the question of integration at this point. Obviously, there are lots of APIs, as you said, and lots of interfaces with other vendors products or other people’s capabilities. How does integration feature in your thought process?
DF: Well, as part of our product development, when we build our products one of our mandates is that our products will comply with standards. All of our products have to comply with a set of standards that facilitate integration. It is an imperative for all products. Moreover, all of our products have to have the ability to integrate with external systems. We have a mandate to be able to integrate, and we have a mandate to be integrate-able. We actually have more than one mandate, and we execute on that.