As the CEO of Arango, Shekhar Iyer leads the company’s mission to make enterprise AI contextual, scalable and trusted.
AI and other mission-critical applications can work exactly as designed in development and still fail to meet production requirements. Consider an AI support agent. It works fine in development. But once in production, it encounters new variables and may recommend the wrong resolution because it lacks a customer’s product configuration or prior case history. That’s just one example.
Saying that the application itself failed isn’t necessarily accurate. What happened is that the requirements it had to operate under changed. In production, data volumes and users grow, relationships deepen and context changes faster. The underlying data architecture must sustain performance while enforcing security and governance across required deployment environments. If it can’t account for context correctly in real time under those conditions, context becomes a liability, and the data architecture becomes a constraint.
Ultimately, a production architecture problem can wreak havoc on a business, such as creating security vulnerabilities for customers or harming the user experience to the point where it decreases renewals.
When Context Becomes Leverage—Or Liability
Context becomes leverage when an application can connect current data, relationships, history and permissions in real time to make a reliable decision. But when context is incomplete, outdated, inconsistent across systems or too slow to retrieve in production, it becomes a liability.
What initially appears to be separate engineering problems may actually be symptoms of a deeper issue: The application has outgrown the data architecture. I saw this with one of our cybersecurity customers who was building an AI-driven security application. The application needed to determine who had access to which systems, how that access was granted and whether it should be retained.
Identity applications increasingly need to account for people, service accounts and AI agents—and track how access changes over time. That requires tracing connections among identities, groups, roles, permissions and resources across enterprise systems. Removing an employee from a group may still leave them with access through another role. Revoking one permission from an AI agent may leave it able to reach the same system through a different connected service account.
If the context is current and complete, it helps the application identify risky access, explain how it was granted and support its removal. An incomplete or outdated view can become a security liability.
The same pattern appears across industries. For example, a manufacturer may need to understand how a component change affects products, suppliers and production. A clinical research organization may need to connect the requirements of a study with investigators, patient populations and site performance. In each case, context creates leverage only if it remains current, connected and available within the application’s production constraints.
The Reframe: Production-Architecture Fit
This is where technology leaders need to change the question they ask. Instead of asking, “Can our data architecture support this application?” they should ask, “Can our data architecture support the conditions under which this application must operate?”
I think of this as “production-architecture fit.” Can the data architecture satisfy an application’s performance, scale, security, governance and deployment demands as the data, relationships and operating conditions change?
Production readiness rarely comes down to meeting one requirement. An application may need low-latency performance as data grows, stronger controls as context changes and flexibility across deployment environments. Whether the architecture can meet these demands simultaneously is the true test of production readiness.
How To Recognize A Production Architecture Problem
In my experience, there are three key signs of a production architecture problem.
1. The Answer Depends On Multi-Hop Relationships
The first sign is that an application can no longer produce a useful answer by finding one direct connection. It must follow a chain of relationships across data at the speed and scale production requires. For example, from a user to accounts, permissions, applications or resources, or from a component to designs, suppliers and releases. That path may vary from one question to the next.
The signal for leaders is when tracing those relationships becomes essential to producing a useful answer or decision. For example, a decision that depends on multiple, changing relationships places very different demands on the underlying architecture than a one-hop lookup. The question is whether the architecture can reliably navigate those deeper, more complex paths.
2. Production Requirements Start To Accumulate
The second sign is when production requirements begin to stack up. An application may have to meet several requirements at once. Production architecture problems often appear at the intersections, such as when deeper relationship traversal must remain low latency, when continuously changing context must remain auditable or when scale must increase without weakening isolation or deployment controls. Any one of those requirements may be manageable on its own. The warning sign comes when the architecture struggles to meet them at the same time.
From my observations, the natural response is often to solve each new problem individually. Teams might add another database, build another pipeline, introduce another API or create another layer of custom logic. Each addition can solve an immediate requirement, but together they can create a new liability: multiple representations of operational context that must remain synchronized, governed and available at production speed.
Leaders should ask how much engineering effort is advancing the application, and how much is compensating for the data architecture underneath it.
3. Data Architecture Constraints Turn Into Business Or Mission Constraints
Perhaps the clearest sign of a production architecture problem is when constraints stop being just a technology concern. Performance limitations can delay a launch or put customer commitments at risk. Deployment constraints can determine whether an application can operate in a customer’s required environment. Security or governance requirements can limit where and how the application is used.
The transition that leaders should watch for is when data architecture choices begin determining not simply how an application performs, but what the organization can deliver, where it can deploy and whom it can serve.
The Importance Of Diagnosing The Pattern, Not Just The Symptoms
As a technology leader, before addressing the next production issue in isolation, you should ask the following three questions:
1. “Are we fixing an isolated technical problem, or seeing repeated evidence of an architecture/application mismatch?”
2. “Can the architecture keep the application’s context current as relationships, identities and operating conditions change, and still meet its performance, security and governance requirements?”
3. “Is the architecture beginning to determine what we can ship, where we can deploy or which customers, users or missions we can support?”
The true test of a data architecture is whether it can keep its context current, connected and governed, while meeting the conditions under which that application has to perform. When it can, context becomes leverage. When it can’t, context becomes a liability—and the data architecture eventually becomes a business or mission constraint.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
