Dominic Jainy is a seasoned IT strategist with a deep background in artificial intelligence, machine learning, and blockchain, but his current focus is on a more fundamental crisis: the silent accumulation of “cloud debt” within large-scale organizations. Having observed the evolution of enterprise technology from the rigid ERP implementations of the late 20th century to the frictionless, high-velocity cloud environments of today, Jainy brings a unique perspective on why modernization efforts often fail. He argues that many companies are currently mistaking hardware outsourcing for digital transformation, creating a fragile architectural foundation that could lead to systemic collapses similar to the high-profile corporate bankruptcies of the past. Our conversation explores the hidden dangers of the “lift and shift” mentality, the critical distinction between engineering and true architecture, and the impending reckoning facing enterprises that prioritize speed over verifiability.
The following discussion examines the shift from on-premises hardware to cloud-scale infrastructure, the breakdown of traditional governance models, and the urgent need for architectural discipline. We delve into how the removal of procurement friction has accelerated undocumented decision-making and why the next three to five years will be defined by expensive remediation efforts for those who fail to map their systems today.
Many organizations prioritize the “lift and shift” of existing workloads to the cloud to achieve quick wins, but what essential elements are they neglecting in this rush?
The most dangerous thing they are neglecting is the fundamental question of verifiability, or simply knowing if the system is actually working correctly. When you take an old application and drop it into a virtual machine on Azure, you aren’t transforming the business; you are just outsourcing your hardware management to a larger provider. I often think about a packaging company that implemented a major platform and went bankrupt within six months because, while the system produced reports, nobody could verify if the numbers were accurate. The old manual cross-checks were gone, and the seasoned experts had been replaced by a dashboard that outputted data with a cold, unearned confidence. In the rush to move Active Directory to Entra ID or servers to the cloud, companies are losing the ability to see where data flows and who truly owns the integrity of that information.
How does the current speed of cloud deployment compare to the ERP wave of the 1990s, and what specific risks does this acceleration bring to the enterprise?
We are essentially making the same historical mistakes, just at a much higher velocity and on a compressed timeline. During the ERP wave, it took nearly twenty years for organizations to realize they had prioritized software implementation over architectural discipline, eventually spending billions on remediation services to untangle those choices. Today, the cloud removes the physical friction of hardware procurement, meaning a developer can spin up a new database or an API endpoint in an afternoon without any capital approval or oversight. This lack of friction sounds like an advantage, but it allows for the rapid accumulation of undocumented architectural decisions that no one fully understands. Three years into this cycle, you often find fifteen different integration patterns and identity approaches that were set by someone who left the company eighteen months ago, creating a fragile environment that is ripe for a security or operational disaster.
You make a sharp distinction between infrastructure engineers and architects. Why is this role separation so critical for a company’s survival in a cloud-first world?
The distinction is vital because an infrastructure engineer and an architect are answering two completely different, yet equally important, questions. An engineer is focused on the “how” of provisioning—they are experts at configuring networking, identity services, and virtual resources to ensure the lights stay on. An architect, however, must look at how these systems relate to one another and what happens when a specific dependency fails in a complex chain. Without a dedicated architect, you end up with a collection of “locally reasonable” decisions that, when combined, create a globally incoherent and untrustworthy environment. If you don’t have someone whose specific mandate is to ensure the environment is coherent and verifiable, you are essentially building a skyscraper without a blueprint, relying solely on the skill of the individual bricklayers.
When cloud environments become undocumented and sprawling, what specific “points of failure” should leaders be looking for to identify hidden risks?
Leaders should start by looking at their integration layer and the flow of data across system boundaries, as this is where the most significant gaps usually hide. You likely have data moving in ways that have never been mapped, often through legacy code that was never properly documented during the initial migration. Look for spiraling costs that are running three times over original projections, as this is usually a sensory signal of architectural inefficiency and sprawl. Another red flag is when security incidents or system failures can only be diagnosed by reading through raw code because there is no high-level map of how the components connect. If your team cannot tell you exactly where a piece of data originates and how it is verified before it hits a financial dashboard, you are operating in a state of high-risk uncertainty.
What practical steps should a large enterprise take today to prevent the “reckoning” you predict will occur in the coming years?
The first step is to commission an honest architectural assessment that is strictly separated from a standard security audit or a cost review. You need a comprehensive map of how your systems actually connect and where the data flows, and you need to do it now while the people who built these integrations are still employed at the company. I recommend establishing a lightweight architecture review process for any significant technical decision to ensure that “locally reasonable” choices don’t sabotage the broader system. It is also crucial to formalize the role of the solution architect as a separate entity from infrastructure engineering, giving them the authority to ask the difficult questions about system dependencies. Ultimately, it requires a cultural shift back to the question that the failed packaging company ignored: how do we know for certain that this is working?
What is your forecast for the state of enterprise cloud architecture over the next few years?
Between now and 2030, we are going to see a massive wave of remediation investment that will likely dwarf the initial costs of cloud migration. I estimate that within the next three to five years, the pain of spiraling costs, frequent security breaches, and fragile digital transformation programs will become too visible to ignore. Organizations will be forced to spend millions untangling the mess created by the “lift and shift” era, much like they did with ERP systems in the early 2000s. However, the companies that choose to prioritize architectural governance today will find themselves in a much stronger position, possessing the agility to actually use technologies like AI and blockchain effectively rather than just fighting to keep their basic infrastructure stable. The reckoning is coming, and it will separate the organizations that truly transformed from those that just moved their problems to someone else’s data center.