Enterprises know everything is not moving to the cloud – that was the lesson of 2024, and it triggered some extreme reactions that fueled the cloud repatriation stories we all heard.
The lesson for 2025? It’s that some things are, and should be, moving to the cloud. The challenge is navigating that complicated between-the-extremes space. The first step in addressing that challenge, according to enterprises, is addressing why cloud application planning is a challenge in the first place.
One of the hidden truths about the “move to the cloud” strategy is that it implies a simple transformation of a hosting point. Repatriation implies the same thing, in the other direction. Whatever is between the two means a redo of applications, perhaps a major redesign. That means you need not just someone who knows cloud features, but also someone who knows how to design a hybrid application model with one foot in a static data center and the other kicking around in an agile ether. That, it turns out, is very hard to find.
Talent is the problem, enterprises say. One CIO told me every time they’d made a cloud architect an offer, a Silicon Valley firm would steal away the candidate by beating the offer handily. Getting anyone with cloud skills is an HR challenge, but getting a well-qualified cloud architect is like winning the lottery.
Some enterprises have tried training application architects in cloud principles, but on the average, they say this takes a year. And at the end of the process, the architect has had a dazzling array of other job opportunities presented to them, often during the time they’d been obtaining cloud certification. The same CIO complained that the very companies that were certifying their architects in cloud technology were often subtly recruiting them.
As a result, enterprises must work through a process of cloud planning that’s feasible with the resources available.
The top strategy so far is what one enterprise calls the “Cloud Team.” You assemble all your people with cloud skills, and your own best software architect, and have the team examine current and proposed cloud applications, looking for a high-level approach that meets business goals. In this process, the team tries to avoid implementation specifics, focusing instead on the notion that a hybrid application has an agile cloud side and a governance-and-sovereignty data center side, and what has to be done is push functionality into the right place.
The Cloud Team supporters say that an experienced application architect can deal with the cloud in abstract, without detailed knowledge of cloud tools and costs. For example, the architect can assess the value of using an event-driven versus transactional model without fixating on how either could be done. The idea is to first come up with approaches. Then, developers could work with cloud providers to map each approach to an implementation, and assess the costs, benefits, and risks.
Ok, I lied about this being the top strategy—sort of, at least. It’s the only strategy that’s making much sense. The enterprises all start their cloud-reassessment journey on a different tack, but they agree it doesn’t work.
The knee-jerk approach to cloud costs is to attack the implementation, not the design. What cloud features did you pick? Could you find ones that cost less? Could you perhaps shed all the special features and just host containers or VMs with no web services at all? Enterprises who try this, meaning almost all of them, report that they save less than 15% on cloud costs, a rate of savings that means roughly a five-year payback on the costs of making the application changes…if they can make them at all. Enterprises used to build all of their core software internally, but those I chat with say that more than two-thirds of their stuff is now off-the-shelf, and their development resources tune it to their needs. They can’t change the internals of what they get from third parties, and they don’t have the resources or the time to do it all themselves.
What can the Cloud Team accomplish, in comparison? Of 33 enterprises who used this approach in some form to redo applications to optimize cloud cost/benefit, the average savings reported was 55%, and the payback period on the implementation cost less than two years. Big difference, huh?
To enterprises who tried the Cloud Team, there’s also a deeper lesson. In fact, there are two. Remember the old “the cloud changes everything” claim? Well, it does, but not the way we thought, or at least not as simply and directly as we thought. The economic revolution of the cloud is selective, a set of benefits that has to be carefully fit to business problems in order to deliver the promised gains. Application development overall has to change, to emphasize a strategic-then-tactical flow that top-down design always called for but didn’t always deliver. That’s the first lesson. The second is that the kinds of applications that the cloud changes the most are applications we can’t move there, because they never got implemented anywhere else.
Remember my comment about event-driven versus transactional? IT, for decades, has really been about the transactional stuff. Collect and process business records, commercial paper in some form. When the Internet brought technology into our lives, into our hands and on our wrists, it opened up the need for a new and more agile form of IT, one that can ebb and flow with our work and lives. We’ve not really addressed this new set of things because it doesn’t fit the transactional model. Enterprises now realize that the cloud is the natural place to host the new stuff, and that the hybrid applications they’re building with the Cloud Teams are created by separating off the front-end pieces of transactional applications, leading them to look at the full set of things the cloud’s agility can support. Ebb and flow is a cloud thing, if the cloud is to reach its value potential, and it’s our next thing.
The important point, though, is that the cloud isn’t pushing this, it’s the applications that are pulling it. That’s why cloud optimization succeeds when it starts at the top, the strategic level. Enterprises tell me that what makes the Cloud Team work are application and enterprise architects, not cloud-expert developers. A good developer, they say, can master cloud technique. A good architect knows what to apply the development effort to, and that’s the skill needed.
What’s true for the cloud is also true for new technologies like AI. Talking about replacing workers with AI is like talking about replacing servers with the cloud; you need to get to what justifies either one to make a difference, and you can’t get to the penthouse from the basement. You need to talk about rethinking work, reimagining business processes so they can take advantage of an AI intelligence injection at strategic places. What can help the cloud change everything can help AI do the same and help how the two work together, too.
And how is that, exactly? Let me give you a hint until my next blog. Think agent but not “agentic” AI.