By Sramana Mitra and guest author Saurabh Mallik
SM: So, if you summarize that thought, can the advantages of integration surpass the cost of risk in cloud computing?
MW: I remember the day when integration costs plus the software costs for big ERP were 5:1; it’s now much less than that. I can then speculate that as we move more into the cloud, given best-of-breed forces – which has to do with lot of different startups innovating in different directions, including small and medium businesses or avant-garde large businesses – integration costs are going to be higher multiples in the early days than they were originally. Now, will that outstrip the benefit? Probably not. The first thing you should do when you are looking to move a workload to the cloud is do a business case, and if it’s a small workload or a small cost benefit, make it a small business case. However, if it’s something significant, or with a lot of moving parts, do a more rigorous business case. It’s not a huge amount of time, and it will definitely shine a light on places where there might be a risk to the savings case of the cloud. Now, savings has a few parts; there is speed to solution and opex over capex in the savings element, and the expertise of the organizational resource. It may be that it’s not cheaper than an in-house transaction or analyzed scenario, but I got there much more quickly, or I don’t have to have a bunch of expertise in-house.
SM: Right, it’s a lot less complexity, but potentially not very much cheaper. I hear both points of view. Some people are saying that the cost structure is going to be a third of what it really was. Some people have achieved a third of the cost structure. You are saying that it’s not going to be that much cheaper.
MW: I think it’s dependent on the circumstances. Say I have a single source of service from the cloud for something that’s very clear; let’s just use compute machine images. It’s very precise, it’s almost commoditized, and for those kinds of business cases, the cost can be a third of what it was. I actually have a proposal submitted this week which was considerably better than a third from a capex standpoint and probably half the cost from an opex standpoint. And it allowed this company, which is in an explosive growth mode and which started at scale 1, to now go to scale 5. So, it is all of those good things. However, that is not the case in the example we were talking about. With five different sources, and doing innovation and integration, that’s where the integration costs come in. It will be higher today than in three to five years, probably because people are still figuring things out.
SM: People are saying that in the next five years there will be more standard and better APIs, and the integration piece will get smoother.
MW: Absolutely, and there will also be more examples of what to do well and what not to do.
SM: And probably, there will be more of a value-added provider infrastructure service, even with the small and medium companies, some of which will be experts at doing this stuff.
MW: I hope that is so and that it includes us. As I said earlier, a year ago 90% of the work we were doing was helping people to understand its potential and 10% was actually planning, designing, and implementing. Now, it’s 30%–40% helping people to understand and 50% doing the planning, design, and implementation. So, even those with the most parts are ultimately straightforward. There are only a few cases where we are doing fairly complicated sourcing of multiple providers at multiple levels of infrastructure, software, and business processes. Those are challenging and very rewarding. There may or may not be a cost case, but maybe there will be a speed to solution case or an innovation or opportunity case.
SM: Well, it seems like the infrastructure part is similar in terms of integration of the application layer in the business process where the business process and the functional knowledge kicks in. This is where the integration knowledge is going to get more complex.
MW: Always. It’s always the case that I have more complex integration when I begin to automate business processes, particularly across enterprises. I will say, however, that there is some complexity even today, which is perhaps a reflection of the maturity in our service offerings and our understanding of how to leverage them. An example is infrastructure. I could be sourcing computing services from more than one player simultaneously, storage from more than one player simultaneously based on, for example, basic machine images based on development/test automation and virtualization; complex grid computing images from another player; normal relational database data from one vendor and distributed database from another vendor. I could pull those together into a workable, risk control, repeatable, and reliable process, and that’s where there’s still some work to be done. The analogy might be that it’s 1989 again, and I want to do client servers.
SM: Yes, the centralized hub-and-spoke model.