When a data center goes dark, a network link fails, or an entire cloud region stumbles, the difference between a brief hiccup and a multi-day outage often comes down to decisions made months or years earlier – in the architecture diagrams, replication strategies, and failover plans that few outside the engineering team ever see. Over the past eighteen months, Srinivas Kakarla has published a trio of research articles that dig into exactly that problem space: how large enterprises can keep their SAP systems available, resilient, and well-governed as they move onto the major public clouds.
Kakarla’s work sits at an intersection that has become increasingly consequential for global business. SAP systems run the financial, supply chain, and operational backbone of many of the world’s largest companies, and as those companies migrate from on-premises data centers to Amazon Web Services and Microsoft Azure, the old playbooks for high availability and disaster recovery no longer translate cleanly. Cloud regions, availability zones, replication services, and managed load balancers all behave differently than the hardware clusters and storage arrays they replace. Kakarla’s three papers, published between March 2020 and June 2021, each take on a piece of that translation problem.
Rethinking Disaster Recovery for SAP HANA on AWS
The research paper, “Multi-Region High Availability and Disaster Recovery Architecture for SAP HANA on AWS: Design Patterns Using HANA System Replication with Dynamic Tiering,“ appeared in March 2020. It tackles one of the thorniest engineering challenges in enterprise SAP deployments: how to keep an in-memory database like SAP HANA both fast and durable when the infrastructure underneath it spans multiple AWS regions.
SAP HANA’s in-memory design is what gives it speed, but it also means that a poorly designed replication strategy can leave a company exposed the moment a region becomes unavailable. In the paper, Kakarla lays out design patterns built around HANA System Replication paired with Dynamic Tiering, a combination that allows less frequently accessed “warm” data to be offloaded from memory without breaking the replication chain that keeps a secondary region ready to take over. The result is an architecture that aims to preserve low recovery time objectives and recovery point objectives across regions, without forcing companies to pay for the cost of keeping every byte of data in memory in two places at once.
For SAP customers running mission-critical finance, manufacturing, or logistics workloads, that distinction between theory and a workable, cost-conscious pattern is where much of the value lies. Kakarla’s paper doesn’t just describe what dynamic tiering is; it maps out how to combine it with system replication in a way that holds up under an actual regional failure.
Central Finance and High Availability on Azure
Kakarla’s other research, published in February 2021, moved from AWS to Microsoft Azure and from infrastructure resilience to a specific SAP application: Central Finance. Titled “Architecting SAP Central Finance on Microsoft Azure: A Reference Architecture for High Availability Using Azure Availability Sets and Application Gateway Load Balancing,“ the paper addresses a deployment pattern that has become central to how large, multi-system SAP landscapes consolidate their financial reporting.
Central Finance works by replicating financial postings from multiple source SAP systems, sometimes running different versions of SAP software, into a single, unified system. That consolidation is powerful, but it also creates a single point of dependency: if the Central Finance system goes down, the flow of financial data across the entire organization can stall. Kakarla’s reference architecture addresses that risk directly, describing how Azure Availability Sets can be used to distribute the application layer across fault domains and update domains, while Azure Application Gateway handles load balancing and traffic routing to keep the system responsive under load and resilient to individual instance failures.
What distinguishes the paper is its attention to the practical mechanics of Azure’s availability primitives as they apply specifically to SAP’s application architecture, rather than treating high availability as a generic cloud problem. It gives architects a reference they can adapt rather than a set of abstract principles they have to reinterpret for SAP on their own.
A Validated Design Pattern for the Azure Well-Architected Framework
The third research paper, published in June 2021, broadens the lens again. “Applying the Azure Well-Architected Framework to Enterprise SAP Workloads: A Validated Design Pattern for Reliability, Security, and Operational Excellence“ takes Microsoft’s Well-Architected Framework – a set of principles Azure architects are meant to apply across reliability, security, cost, operations, and performance – and works through what those principles mean concretely for SAP workloads.
This is, in some ways, the most ambitious of the three papers, because it isn’t confined to a single component or application. Instead, it proposes a validated design pattern that enterprise architects can use to assess and structure an entire SAP-on-Azure landscape against the framework’s pillars. Reliability decisions about redundancy and failover, security decisions about network segmentation and identity management, and operational decisions about monitoring and automation are all threaded through the same architectural pattern, rather than addressed as separate initiatives that risk pulling in different directions.
Taken together with the two earlier papers, this third piece rounds out a body of work that moves from a specific database replication problem, to a specific application’s high-availability design, to a framework-level pattern for governing SAP workloads on Azure as a whole.
A Body of Work Built for Practitioners
What comes through across all three papers is a consistent orientation toward the people who will actually have to build and operate these systems. Kakarla writes for enterprise architects and infrastructure teams who are being asked to move complex, business-critical SAP landscapes onto AWS and Azure, often on tight timelines and with limited room for error. Each paper takes an abstract cloud capability – dynamic tiering, availability sets, a well-architected framework – and turns it into something closer to a blueprint.
That focus matters because the stakes in this space are unusually concrete. An SAP outage doesn’t just interrupt a website or a mobile app; it can halt order processing, delay payroll, or stall financial close for a multinational company. The design patterns Kakarla has published address exactly the scenarios that keep infrastructure leads awake at night: a region failing over, a Central Finance system needing to stay available around the clock, an entire SAP estate needing to satisfy security and reliability requirements simultaneously.
With enterprise cloud adoption for SAP workloads continuing to accelerate, research that translates cloud-provider capabilities into workable, SAP-specific architecture is likely to remain in demand. Kakarla’s three publications, spanning both of the industry’s leading hyperscale clouds, offer a coherent and practically grounded contribution to that ongoing conversation – one built less around abstract cloud theory and more around the architecture decisions that determine whether a company’s SAP systems stay up when it matters most.
