Ramesh Kasarla on Enterprise Architecture’s Generational Shift

With more than two decades in application development, Principal Engineer Ramesh Kasarla has watched enterprise systems transform from fortified monoliths into composable, AI-ready architectures. His perspective bridges a gap few engineers can claim: deep experience with the mainframe-era mindset and hands-on leadership in modern distributed systems at a major telecommunications company.

When Kasarla started his career, engineering teams built what he calls “Systems of Record,” massive, stable fortresses where everything lived together to ensure data integrity. Changing a single component required redeploying the entire structure. “Today, we don’t think in terms of ‘applications’ anymore; we think in Business Domains,” he says. Microservices and event-driven patterns allow teams to swap out parts of the system without collapsing. And with AI agents entering enterprise environments, Kasarla notes that systems must now be “Reason-ready.” Data can’t sit in silos; it must flow in real-time to where automated agents can act on it.

Security thinking has undergone an equally dramatic transformation. Two decades ago, safety meant a big firewall. If you were inside the network, you were trusted. That perimeter is now gone. “We’ve moved to Zero Trust by Design,” Kasarla explains. “We assume the network is already compromised, so security is baked into the code rather than the infrastructure.” The focus has also shifted from monitoring (knowing if something is broken) to observability (understanding why systems behave strangely). At enterprise scale, predicting every failure mode is impossible. Engineers must be equipped to debug the “unknown unknowns” in production.

The organizational shifts may be more significant than the technical ones. Kasarla recalls the era of “tossing code over the wall” to QA, who passed it to Ops. There were Database Guys, Middleware Guys, UI Guys. That wall is gone. High-performing teams now use Platform Engineering, providing “golden paths” and self-service platforms that let developers spin up an entire, security-compliant, scalable environment in minutes. “A small team of 5-8 versatile engineers today can maintain what used to require a department of 50,” he observes.

This organizational philosophy shapes his approach to microservices architecture. Kasarla views microservices as “an organizational solution to a human communication problem, not just a technical solution to a scaling problem.” He follows Conway’s Law, the principle that systems reflect the communication structure of the teams that build them. Early on, enterprise architecture was about permanence: choose a technology stack and commit to it for a decade. Now, evolvability is the priority. “We assume that any part of the system might be replaced in three years.”

Where machine learning fits into enterprise architecture, Kasarla has strong opinions informed by practical deployment. He describes a fraud detection system that had devolved into thousands of lines of hardcoded if-then statements. The rules couldn’t keep pace with adversaries who changed tactics faster than developers could respond. Rule fatigue set in, and adding a new rule to catch specific fraud would accidentally block thousands of legitimate customers.

“A human developer cannot write a nested if statement that weighs 50 variables at once,” Kasarla says. The solution was a Gradient Boosted Tree model that discovered non-linear correlations from five years of transaction data. The system caught “low-and-slow” attacks (bots mimicking human behavior over weeks) that manual rules never could have detected. False positives dropped by 40 percent. More importantly, when new attack patterns emerged, the team didn’t write new code; they retrained the model on fresh data. His takeaway: “Traditional programming is about Logic. Machine Learning is about Patterns. You use Logic for the ‘rails’ (compliance, business rules) and Patterns for the ‘intelligence’ (predictions, anomalies). You need both.”

Integration challenges have taught Kasarla the value of resilience over optimization. His most complex project involved building a real-time order-to-fulfillment pipeline connecting a legacy ERP, Salesforce, a third-party logistics provider, and a payment gateway. The happy path was easy; the nightmare was partial failure. What happens when the payment gateway charges the card, but the ERP fails to reserve inventory?

Traditional request-response calls proved too brittle. One slow service created cascading timeouts that froze the entire user interface. The team implemented an Event-Driven Architecture using a message broker. When an order was placed, they published an Order_Created event; each system subscribed and handled it at its own pace. A Canonical Data Model meant every third-party API was translated into an internal standard format by an adapter layer. Swapping a logistics provider required updating one adapter, not the whole system. For partial failures, they implemented the Saga Pattern. If inventory reservation failed, the system automatically triggered compensating transactions: refunds, support alerts. “We moved from ‘Hoping it doesn’t break’ to ‘Designing for when it does,'” he says.

On CI/CD adoption, Kasarla sees organizations repeatedly stumbling into the same traps. Creating a dedicated DevOps team that owns pipelines actually recreates the silos CI/CD was meant to destroy. When pipelines break, developers say “that’s a DevOps problem,” and the coordination tax returns. His preference: Platform Engineering teams build reusable templates, but feature teams own their own pipelines. “If you don’t own your deployment, you don’t truly own your code.”

Pipeline velocity should be treated as a Tier-1 metric. When builds take longer than ten minutes, developers start context-switching, and productivity collapses. He’s seen teams where a two-line code change takes 45 minutes to clear the pipeline because of test bloat and legacy security scanners. And there’s a more fundamental problem: teams automating broken processes. “They take a complex, 10-step manual approval process involving three different departments and try to script it,” he says. “Now you just have a fast way to get stuck in a digital bottleneck.” Automation must follow simplification.

When discussing GraphQL versus REST, Kasarla advocates for pragmatism over ideology. GraphQL shines when frontend requirements are volatile or when multiple clients (mobile apps, web dashboards, smartwatch interfaces) need different subsets of the same data. For deeply relational data, GraphQL replaces the waterfall of 3 or 4 REST requests with a single round-trip. For rapid prototyping, it prevents backend teams from becoming bottlenecks for new field requests.

But he still reaches for REST in specific scenarios: simple CRUD services where GraphQL’s parsing overhead is overkill, public APIs where REST’s universal familiarity matters, and heavy binary transfers where REST handles streams more naturally. His recent projects use a hybrid approach, with REST for high-traffic internal microservice communication where performance is predictable, and GraphQL as a gateway for frontend teams who need flexibility.

After 20 years, Kasarla has one technical hill he’ll die on: code is written for humans first, then for machines. Early in his career, he wanted to write clever code (one-liners, complex abstractions, micro-optimizations). Two decades of 3 AM debugging sessions cured him of that impulse. “In an enterprise, the cost of software isn’t in the writing; it’s in the reading and modifying,” he says. “If a senior engineer writes a complex abstraction that only they understand, they haven’t solved a problem. They’ve created a single point of failure.”

He refuses to compromise on explicit dependency management. No “magic” frameworks that do things behind the scenes via reflection or global state. He’ll spend ten minutes debating a variable name in code review because “a bad name is a lie that lives in the codebase forever.” And he’s reversed his stance on DRY (Don’t Repeat Yourself): “Duplication is far cheaper than the wrong abstraction. It’s better to have three copies of a simple function than one ‘god-object’ function with 15 flags trying to handle every case.”

Looking at unsolved problems in enterprise software, Kasarla points to distributed data integrity as the most pressing crisis. The industry has moved from a single big database to thousands of microdatabases, trading consistency for availability. When a user buys a product, five services (Inventory, Billing, Shipping, Loyalty, Analytics) need to know. If Shipping is down, the system enters an inconsistent state. “We use the Saga Pattern or Eventual Consistency, but these are elaborate patchwork fixes for a fundamental problem: we don’t have a ‘Global Truth,'” he says. Engineers spend 40 percent of their time writing reconciliation logic. “We’ve built a world where ‘probably correct’ is the best we can do at scale.”

Conway’s Law remains a persistent bottleneck. If Marketing and Sales don’t communicate, their software modules won’t either, even when customers need a seamless experience. Platform Engineering and Agile frameworks help, but enterprise software still reflects internal politics rather than customer journeys. “We are still building ‘Silos with APIs’ instead of unified digital experiences.”

And legacy debt is reaching a breaking point. Enterprises sit on 30 years of COBOL, Java 8, and early cloud code. As teams try to inject AI and agentic workflows, they’re finding foundations too brittle to support the new capabilities. “We are essentially trying to replace the engines of a plane while it’s mid-flight,” Kasarla says. The industry’s only answer, Strangler Fig patterns, often takes a decade to complete.

Twenty years ago, Kasarla would have said the biggest problem was CPU speed or bandwidth. Today, he knows it’s Semantic Consistency: getting a thousand different microservices to agree on what the word “Customer” actually means. His goal isn’t to be the hero who solves the complex bug. It’s to be the architect who designed a system so simple that the complex bug never had a place to hide.