Maximizing cloud: An operating model to drive value and efficiency

Introduction: Cloud is now ‘BAU’ …  but enterprises don’t find it easy 

When it comes to the benefits of migrating to the cloud, few organizations still need to be convinced. Adoption has continued to gain pace across many industries, with some studies suggesting that close to 100% of companies now use the cloud in some capacity.

Rather than curbing cloud spending, the prospects of an economic downturn seem to have the opposite effect. Research firm, Gartner, estimates spending on the public cloud could climb over 20% to near US$600 billion this year. According to Google, over 40% of global tech and business leaders plan to increase investment in cloud-based services in the hopes of enhancing organizational performance and resilience.

Top ways businesses are revisiting cloud strategy in the current economic climate 

But while businesses might see the potential of cloud to deliver these outcomes, realizing them is another matter. Rather than giving the company more control over costs, cloud may create new complexities. One recent poll highlighted managing cloud spending as the top cloud-related challenge enterprises face, crowding out even security and skills shortages. Some are struggling to the point that they’ve thrown in the towel, and migrated back to on-premise infrastructure. “Most organizations realize the need to move to cloud, and many have already started their journey,” says Rashmi Tambe, Head of Enterprise Modernization, Platform and Cloud at Thoughtworks, India. “But most of the time, these decisions are taken in a reactive manner, just because the competition is doing it, or purely from a cost optimization perspective. Fundamentally, most decision makers still look at cloud as an infrastructure play.”

“Often there’s an element of peer pressure in cloud migration,” notes Ajay Chankramath, Head of Thoughtworks’ Delivery & Cloud Infrastructure practice. “But senior leaders in various sectors continue to tell us that once they’ve actually moved to the cloud, rather than seeing benefits, they’re actually spending more, they have less predictability on their spend, and business value is not being realized. This becomes a real challenge for organizations because, at the end of the day, CIOs and CTOs are accountable to their CFOs and their board.” 

The disconnect between cloud expectations and enterprise realities is often rooted in a fear of the unknown, according to Thoughtworks Director of Enterprise Modernization, Platforms and Cloud, Sarah Taraporewalla. 

“There’s a degree of risk aversion because the transition can be difficult,” she explains. “People are hearing stories about cloud not delivering on its financial or security promises and wonder why they should move if things are running relatively well as is. They may fear opening a backdoor vulnerability, or losing control over governance and costs.”

But according to Thoughtworks experts, the risks can be managed, and gains maximized, by a carefully mapped out cloud strategy that understands infrastructure as just one aspect of the transformation.  

“If you’re just moving applications to the cloud, the strategy piece is missing,” says Tambe. “If you’re looking at cloud to play a role in growing and scaling your business, building newer products faster, you have to think about multiple building blocks beforehand. It doesn't have to be a big bang strategy exercise – but you have to plan it out so that the cloud becomes a journey for you, not a one-stop destination.” 

“The reason cloud strategy and governance operating models are so important is because of challenges that organizations face around the fundamental concept of how you rent and use cloud space, versus how to run a data center,” agrees Taraporewalla.

One of the most essential components of a cloud strategy is “defining the business value that cloud is going to provide you,” says Chankramath. “It's no longer about whether you can actually have workloads running efficiently on the cloud – the answer to that is absolutely. It has to be more of a holistic activity that spans every part of the organization. It’s not a technology issue alone – it’s a security issue, it’s a product issue.” 

“The technology aspect of cloud is just a small part of it and in most cases easily manageable, because so many services are available,” Tambe says. “It’s the process and the people part, changing the enablement of the organization to develop, manage and optimize on cloud, aligning your teams, skills, capabilities, and ways of working, where the emphasis needs to be placed.”  

The path to a cloud-first operating model 

Acknowledging reality, and making the difficult decisions  

Because the impact of cloud migration is business-wide, it’s helpful to kick off the process with an organizational sense check – “just looking at adoption readiness overall,” as Tambe puts it. 

Unfortunately, the answers to key questions that help put the enterprise on the right path, such as which applications to move first and which teams need to be involved, can be elusive, not least because companies often lack knowledge of how their systems have built up over time. 

“One big problem is that while the company retains the people who run the business, the people who understand how systems work are often no longer there,” Taraporewalla says. “Some systems are staying alive through a sort of miracle. People really don't know what the system’s meant to be doing, what bolt-ons have been added – or what value it brings. Some of the complexity is in that uncertainty.” 

“Many clients have a monolithic or large legacy system, but don't have a lot of developers who understand it,” agrees Chankramath. “They look at the cost of migration – not just CapEx, but development costs, the opportunity cost that you incur when you actually try a feature freeze to break down your model – and end up taking the passive path of least resistance, which might be a lift and shift.” 

While simply running virtual machines on a cloud versus a data center can provide some benefits, he notes, unlocking deeper cost savings or performance gains requires more engineering investments and architectural rigor. The uncertainties around migration contribute to a situation where “everybody wants to go to the cloud, but most take the path of least friction to get there,” as Chankramath puts it.

“Organizations have failed with cloud by concentrating on the easy things, not business value and risk,” agrees Taraporewalla. “A significant number are still reluctant to move critical systems – those that actually run the business and make money. They’re thinking, let's do that low-hanging fruit, bring the easy things across – but if it’s easy, it’s probably not valuable to the business.”

An abundance of tools are available to help organizations come to terms with their systems. Thoughtworks, for example, has created an assessment framework called X-act “because you can think of it as X-ray vision and act on it,” says Tambe. “You’re literally looking at your applications, figuring out various layers, to assess cloud readiness and adoption. We have a set of questions and can build cloud maturity models based on the answers that we receive.”   

“In many cases, we end up working with the CIO, VP of engineering or the CTO, and present this modular framework to them,” she adds. “Leaders understand the thoroughness, and realize there are steps or issues they’ve not considered. Based on this modular approach, we can identify problems and start to build a cloud strategy.” 

Tambe cites four main considerations in deciding what to migrate first. First is how critical the application or system is to the business. Second is its technical footprint – a critical application on a legacy mainframe might essentially be locked in, for example. Last but not least are the risk impact, and total cost of ownership. 

Establishing cloud migration priorities: Four key considerations

Source: Thoughtworks

“The application could be very critical, but if it’s a core business application, there's a lot of risk associated with it,” she explains. “If migration doesn't go well, you could be at risk of losing revenue or customer satisfaction. The other aspect is the total cost of ownership in terms of infrastructure licenses, people, and maintenance. If it's a business-critical application already in a very good place in terms of the technical foundation, you might as well just do a lift and shift. But if the tech stack is entirely legacy and you don't have the talent to maintain it, the best approach is probably to modernize it in phases.”

“Our fundamental advice is in line with all of our other advice around modernization – tackle the things that deliver the most business value first,” says Taraporewalla. “You want to optimize for either the value that it brings to the company, or the reduction in business liability. If it's a risky thing, start doing that one early. If it's going to unlock latent revenue streams or the ability to innovate fast, do it first.”  

Leaving the least strategically or financially important applications for last can also unlock additional advantages in terms of costs and complexity, she notes. “It allows you to get most of the way through the migration and possibly stop at that point, and decide to just sunset all the rest of the applications, because they're not giving you enough of that value.”  

Fostering new ways of thinking 

The cloud journey is continuous, but can broadly be divided into three parts: the build, design and run phases, each of which presents different people and process challenges, according to Tambe. 

“If you’ve not thought about the building blocks – meaning you don’t have guidelines or frameworks for your application teams to migrate or modernize applications – everyone’s going to struggle,” she says. “Even though you may have people who understand the technology, they’re going to have to solve the same set of problems. You’ll increase the cognitive load on every team to figure out cross-cutting concerns like security, compliance and encryption.” 

“You have to have a clear way to figure out how to actually translate your workloads to the right places to run them on the cloud, because you can choose the worst option, and the cloud providers you’re using will tell you what you should consider, but nobody actually stops you from doing it,” notes Chankramath. “When this gets scaled up, you end up creating significant inefficiencies in the run phase, not just in terms of resources and the costs, but also user experience.”    

Avoiding this situation comes down to platform engineering; creating “the foundational layer that’s needed, whether you’re on cloud or elsewhere, to increase your economies of scale,” Chankramath adds. “Depending on your workloads, it’s not necessarily easy for teams to dive in and figure out the right kind of services to use.” 

A clear decision tree that reflects the organization’s architectural components and ecosystems can be created to guide developers towards optimal services. “If developers are given all the options, they're going to fall back on their experience – which will eventually require more draconian governance to solve the misalignment this will create with the overall strategy,” Chankramath says.

Established structures help teams navigate the unfamiliar territory that comes with cloud in a consistent way. “Organizations need to understand they’re not just replacing where workloads are running; there are actual changes in behaviors they need to make when they’re working in the cloud,” Taraporewalla points out. 

She cites the example of a client who, pre-cloud, had a managed services deal in place where provisioning more infrastructure was a simple matter of a phone call to the provider. “That’s how you do things in a data center, and without changing to cloud-first operating models, organizations continue with that mindset: ‘Let me buy the server, let me provision the server to the highest we need to go,’” she explains. “A lot of costing problems come back to the fact that the cloud and data centers are significantly different, and you need to treat them differently.” 

In the run phase, enterprises will have to establish policies across areas like virtual machine provisioning, resource utilization and development environments to ensure they’re operating optimally, Tambe points out. 

“If these aspects have not been thought through, you will see similar problems across teams,” she says. “Optimization has to be the beginning of cloud strategy. All the economic aspects, alerts and notifications if your bills are growing, policies around unused resources and reserved instances, all this has to be built in so that when you go into the run phase in earnest, they’re all set up for everyone. That’s where you reap the advantage of cloud.” 

Coming to terms with costs, and asserting control  

Costs are far from the ultimate measure of cloud performance, but if not rigorously managed, can rapidly undermine the transition to cloud and prevent the enterprise from making the kind of leaps possible in later stages of adoption. The financial aspects of cloud governance and management – collectively labeled financial operations, or FinOps – therefore have to be front of mind. 

“Optimization used to be treated only as an engineering team problem, but now finance controllers, enterprise groups are also part of it, which means that finance as a process has to be institutionalized,” Tambe explains. “It’s not just tweaking certain services or infrastructure to save costs. You have to figure out your charge headquarters, your reporting back models, how you’re going to do budget tracking and measure results.” 

Having visibility over costs is one thing; what organizations should really strive for is forecasting – “knowing how much it’s going to take to run certain instances a year, which supports negotiating your contracts with a cloud service provider,” says Tambe. “Front-level optimization, application and service level optimization, and finally the implementation of different processes in the organization mean costs don’t become an afterthought or a shock. It becomes a more proactive process where you're forecasting your cloud space and mapping it to your business status.” 

Effective cost optimization covers four key stages: report, recommend, remediate and retain. Reporting comes down to having the right data, presented in the right way. “Cloud providers create all kinds of data, but sometimes when you look at your usage reports, your head starts spinning and you can’t figure anything out,” Chankramath says. “So we advocate putting some tools and higher levels of automation in place to make more sense of it all.”    

The four stages of effective cloud cost optimization

Reporting can tell you what kind of cloud resources you’re using on an application or account, but more important are the recommendations that emerge to fix evident problems such as the underutilization of resources, Chankramath says. 

A certain amount of optimization can be tackled or automated without really impacting workloads, Chankramath notes. But “the biggest FinOps challenge is remediation, or actually solving problems for the long term – and how that will impact your product, because the last thing you want is your customers suffering negative consequences,” he says. “FinOps tools and recommendations are becoming more and more commoditized every day. What’s really needed is guidance on how to approach remediation, to ensure you get the benefits while minimizing the downsides.” 

The final stage of cost optimization, retention, focuses on cementing those benefits through widespread cultural change that compels people to use resources in the right way. 

“The engineers working in the code are the ones who are actually dialing up and down and buying, or not buying, servers,” says Taraporewalla. “As long as there's a credit card attached to the account, they've got free rein. Where the purchasing power used to be procurement, and the CFO and the finance office, now it’s with the engineers on the ground, who are often devoid of all budgetary rationale as to what they can purchase, or how much whatever they’re currently running or planning to run will actually cost the business.” 

Because of this shift, “decision-making needs to come closer to the engineers, who need to be more empowered with an understanding of the budgets and what sort of mechanisms they can work within,” she explains. “At the same time, they need to give visibility up to the CFO’s office in terms of exactly what's being spent. The benefit of that is that you can start closely matching spend to value. Whereas in the past, everyone was running from this one server, you can actually start looking at individual parts of the organization and feature sets, saying this feature set gives us this amount of revenue, and it's directly costing us this in cloud spend.” 

Thoughtworks experts see encouraging compliance as less a matter of implementing strict rules than using methods like automated alerts to raise awareness around costs and setting sensible boundaries in development environments. “This goes back to your operating model, because that’s where you’re defining the ways of working, checklists, and actually implementing those checklists as code,” Tambe says. 

Matrices can also be established to direct notifications to finance or management teams when resources are nearing or exceeding designated limits, Tambe adds. However, cost management will often come down to the teams on the ground. 

“Generally, the way cloud accounts are set up is that not everyone has access to spending information, but making dashboards available so that the team starts to actually own costing of the cloud and the value that it’s bringing is something we recommend,” Taraporewalla says. “Overall, we advocate bringing decision-making close to the people who can act on those decisions. Through that, we see better control of the costs of the cloud.”   

Extending governance and security guardrails 

Around cost and other essential considerations such as security, Thoughtworks advocates a light-touch approach to cloud governance that is embedded from the earliest stages and automated wherever possible, to minimize instances of confusion and friction. 

“If you see governance as a separate activity outside your software development lifecycle, it invariably fails,” says Chankramath. “If your product goes through an evolution, the compliance at that point of change, built into your process, makes a huge difference to ensuring that you generate business value. If you make improvements along the way, you don’t go all the way to step eight and then figure out that your steps four and five had inefficiencies and compliance issues and have to go back and fix them, losing your advantage of going fast and getting things done.” 

“Governance and security need to be a balance,” Taraporewalla explains. “We’ve seen organizations on both ends of the spectrum – locking things down so much it’s a bottleneck, like they’re still in a data center, where teams are unable to create the infrastructure themselves. And then there’s the cowboy situation where, regardless of any automation provided to the group, they just go in and manually change things, and their environments drift further and further away from standard. You can achieve the happy medium: autonomy with guardrails, scaffolded environments that enable teams to do what they need to get done to deliver business value, but protect the organization as they do it.”

Good governance is built on observability, since, as Chankramath notes, “if you want to change behavior, you need to know what you’re changing.”

“Step one is to make sure there’s a consistent understanding of what that change is across the organization, because there will be a lot of different stakeholders involved in the process,” he says. 

This can be approached tactically by ensuring observability for eight key axes that Thoughtworks has identified as important windows into health and performance: 

• The project portfolio

• The application

• Platforms

• Infrastructure

• The performance of the cloud itself  

• Incidents

• Service health 

• Business operations

The eight key axes of observability

“If you make sure you’re looking at all these data points, and make that data available to everyone, conversations and action on governance become much easier,” Chankramath explains. “If you see your portfolio observability is showing some really terrible signs of decline, whereas your application observability shows everything is perfect, for example, you know you still have a problem.” 

Security and compliance are key governance aspects that must be factored in at a fundamental level, and closely watched as ‘first-class citizens’ of a cloud strategy. 

“At the infrastructure level, first and foremost, you have to look at automating most of the security policies that you define,” says Tambe.  

“A lot of it is shifting left in thinking about security and governance controls over your infrastructure – deciding what mechanisms to put in place that allow you to automate environment creation, so that you don't have manual backdoors that can provide accidental access to your system, and building with security constantly in mind,” agrees Taraporewalla. 

One of the inherent advantages of cloud is that certain aspects of security, such as identity, access and encryption management, are relatively robust ‘out of the box,’ typically requiring only minor configuration, Chankramath notes. 

However, the deciding factor in security is ultimately how services are used, and to what extent developers operate within embedded guardrails or are given the leeway to make their own choices. 

“This is where the concept of compliance at the point of change comes in,” he says. “If you're developing an application to put in front of clients, do you get the opportunity to bypass many things because they’re time-consuming? Or do you have to use pipeline X? If security becomes the culture, it becomes easier for developers to do the right thing without always having to know what that is, because your pipeline’s enforcing it. Reducing the cognitive load on developers is a huge part of security, because that’s historically been one of the main reasons organizations have struggled with it.”    

One recurring issue is a lack of awareness that major cloud providers often make settings public by default, making it relatively easy for teams to accidentally open up new sites to the internet in the course of their work, Taraporewalla points out. 

“There’s got to be specific steps to turn off those features, but we’ve seen plenty of teams being caught out,” she says. “You need a layer above the default, a baseplate with all the privacy and controls, that turns off things that shouldn't be on. Everything needs to start from this landing zone and you can build on that, baking in the security controls to allow the teams to create the infrastructure they need without worrying if they’re configured correctly.” 

Even with the most optimal configuration, policies and automation, “you’ll still need people doing a lot of vulnerability testing,” notes Tambe. “Cloud security has to be offensive and defensive. Going offensive is actually doing multiple sets of tests to break down your cloud environment and figuring out vulnerabilities in that.” 

The people factor

Along with technology and governance processes, people represent the other lynchpin of the cloud operating model. A strategy has to consider to what extent the enterprise already has the skills and capabilities needed to support cloud-first ways of working – and, if not, how these will be hired or developed. The reality, according to Taraporewalla, is that pure-play cloud talent – the kind that blends deep knowledge of operational aspects like firewalls and network security with understanding of software and platform engineering concepts – is hard to come by. 

When migrating, Taraporewalla recommends enterprises focus on upskilling the operations team, which “usually makes that journey pretty easily,” she says. “There's a lot of material to draw on. Amazon Web Services and Google Cloud Platform have made a lot of guidance public, and there are loads of external training courses that make the transition a lot easier than, say, a developer going from Fortran to Java.” 

“There are two ways to upskill –- one is putting capability programs in place, either internally or in partnership with training academies,” says Tambe. “The second is hiring the talent from outside, because if you're looking at a large-scale cloud strategy implementation, you’re probably not going to have all the skills in-house.” 

Relationships with external providers can also help the organization extend its capabilities. “The best way to enable client teams is to actually work with them,” Tambe explains. “We've worked very closely with client teams to upskill them in newer ways of working – from understanding how to do cloud native application development, to infrastructure as code. We emphasize pairing so we work together, they learn and gain actual experience. When their teams reach a certain level, our experts move out and the client experts completely take over.” 

In general, Thoughtworks counsels a persona-based, rather than broad-brush approach to data and cloud skills development. 

“Even among developers, there are differences in how they actually use resources and perceive what’s happening,” Chankramath says. “It’s key to establish the right kind of structures, training and certifications for internal usage models, and to build awareness of the cultural patterns for engaging different stakeholders. One of the things we focus on is to provide opinionated points of view in the form of accelerators to address skills shortfalls. These are built on proven successes that are codified. All these things will resonate with people as you start practicing them.” 

“We put a lot of emphasis on change enablement,” says Tambe. “You need to have teams organized to develop your foundational platform engineering capabilities, as well as application or product teams who are working closely with the platform team to develop applications. Then domain-aligned teams – for example, if you're working with a lending business unit in a retail bank, you would have lending product teams aligned to the team doing platform development.”

This kind of alignment ensures the business is structured and working in a way “that reflects how it looks to the outside world,” Tambe adds. “When that’s also how teams are aligned inside, it becomes easier to manage. Unless you have these alignments, you won’t be able to address the friction, and the interdependencies of these systems; everyone is waiting on someone else to do something before their own job can get done. A clear separation of responsibilities must be reflected in how your teams are organized, so that the cognitive load is reduced, and everyone can work independently.”  

Fundamentally, according to Chankramath, organizational capabilities and ultimately cloud performance are enhanced by taking steps to make the journey more inclusive. 

“One big challenge is that when we talk to organizations about cloud migration and the business, we’re usually talking with the technology people,” he says. “It needs to be a more holistic conversation with product management, especially since it's a business value activity.” 

“It all goes back to the very simple idea of communication,” he adds. “We recommend establishing office hours and contextually incentivizing participation. The reason people don't do the right thing is most often because they don't know what the right things are. Office hours provide a great way to connect with people who will listen to all the great presentations, the decks and the strategy documents, but still have lingering small questions they don’t feel like asking in a meeting of 100 others. Those kinds of conversations help move the needle in the positive direction, over time.” 

Measuring and maintaining success 

Regardless of the rationale behind cloud migration, the investment will eventually have to be justified. Thoughtworks experts emphasize the need to have clear, and shared definitions of success baked into the cloud strategy from the beginning, and to set benchmarks so teams know what they’re working towards. 

Financial metrics are common, but far from the only ones that matter. “KPIs all come back to the reasons why organizations take their change to the cloud,” Taraporewalla points out. “They’re not technology reasons – it's the ability to innovate; to rapidly respond to customer demand, attract and retain talent, boost speed to market and speed to value. All of these business-level metrics that prompt the journey to the cloud are the same ones you need to be looking at to measure results.” 

Even engineering KPIs, such as speed of application deployment or time to recovery, should ultimately feed into business performance indicators such as customer NPS scores, the speed at which new products come to market and the associated revenue growth, Tambe says.

“The business is not bothered about how many times the API on a server went down, but they are concerned about the impact on revenue and profitability, and how many customers were lost in the process,” she explains. “You should be able to provide dashboards with different sets of metrics for two sets of users – business and engineering.” 

Chankramath notes the four key metrics typically prioritized in DevOps – lead time for changes, failure rates, deployment frequency and time to recovery – are useful, but also ultimately lagging and not always fit for purpose. 

“You want to really look at what your leading indicators are, a high cardinality set of data along the eight axes, and start there as your initial set of KPIs,” he says. “I've worked in organizations where they say every team should have four key metrics, which is totally absurd if you're an operations team trying to fix certain customer incidents.” 

Whatever metrics are set, it’s important to ask: “Are you actually tracking your incidents or running your portfolio through them?” Chankramath adds. “Business operations are invariably almost never integrated as part of any kind of system; they’re typically bespoke. So the question becomes: How do you bring all these things under one umbrella, some kind of a single pane of glass to create actionable insights out of it? You can have all the data, but if you don't have insights, then it can't really get you where you want to go.” 

Measures of performance are also evolving as organizations change, with sustainability a growing part of the cloud agenda. 

“We’ve designed an in-house tool – the Cloud Carbon Footprint  – in response to clients asking us for ways to track their cloud impact and find greener options,” says Tambe. “It allows you to monitor your overall cloud carbon emissions, optimize costs, and get recommendations on how for example by choosing certain availability zones of a specific cloud provider, you can reduce the environmental impact of your systems.”  

“Exposing sustainability data to the level at which everybody can see it is an incentive in itself,” Chankramath says. “Nobody wants to have an observability dashboard saying, hey, you completed your features, but your carbon footprint increased by 30%. It becomes the wall of shame. People will at least want to start to look into better ways of doing things.” 

However, sustainability is, at times, a trickier undertaking than it might appear. “Just by nature of where you run things, you can be greener,” says Taraporewalla. “But that comes at a cost, whether money, latency or breaking regulations around, say, where data is stored. There’s also a debate over who’s ultimately responsible for cloud emissions – the cloud providers or their clients. The providers can make all of their data centers run off solar and as effective as possible, but a lot of organizations have to get back into the practice of writing better code, and not letting Moore's Law help them with performance.”  

“For a startup, or enterprise who's just starting their cloud journey, thinking about sustainability right at the start could be a burden,” she adds. “It's a typical crawl, walk, run maturity pattern. You first have to get on cloud before you think about optimizing.” 

In the end, whether the cloud strategy is assessed in terms of its environmental impact, cost savings or contributions to corporate resilience, long-term performance comes down to providing “clear, objective measurements,” says Chankramath. “Without that nothing changes. Having that data in front of you, and making sure it's not just about one stakeholder in the organization, that everybody gets to see that same thing from their perspective, will make the difference.” 

New tools may come to the fore to assist enterprises with this process – though Chankramath notes these can often cause confusion and need careful evaluation.

“Generative AI and tools like copilots that generate code for you could become very important at the engineering level,” says Tambe. “We’re trying to figure out if we can extend these to infrastructure automation, and if yes, how that would help infrastructure consultants optimize the way they manage cloud operations. But some of the initial euphoria has to settle down before we start figuring out the actual use cases.” 

"We talk about the impact of generative AI on everything, and I think it’s a little bit ‘pie in the sky’ still,” agrees Chankramath. “But generative AI within the space of making sure that your insights are acted on fairly quickly – that’s just around the corner. I've already talked to some vendors who are trying to offer AI for DevOps, platform engineering and so on. The solution to me is starting there – looking at observability more holistically, making sure enterprises have the right kind of actionable insights.” 

More than any new tech, a solid cloud strategy and practices will encourage adoption and the entire enterprise to go further, “so the whole FinOps and performance side of things becomes a part of the DNA of the organization, as opposed to something that you have to keep driving,” Chankramath says. “Ultimately, that's the only way to make the change.” 

“The cloud’s not the end of the journey,” agrees Taraporewalla. “No CEO says ‘I really want to be in the cloud.’ They want to help their customers, and they want to run a profitable business. Cloud is just the means for them to do that.”