Enterprise Architecture Trades The North Star For Survivability As AI Splinters Core Systems

The views and opinions expressed are those of Sergey Sergeyev and do not represent the official policy or position of any organization.

The economics that held enterprise architecture together for the last 30 years are beginning to flip. For decades, custom systems were expensive. That reality forced organizations toward shared platforms, standardized processes, centralized governance, and long-range target-state architecture. ERP, HCM, CRM, ITSM, data platforms, integration hubs, and other enterprise systems became structural beams inside the company. That model is now under pressure. AI-assisted development is lowering the cost of creating narrow, fit-for-purpose software. A workflow that once required funding approval, architecture review, backlog prioritization, development capacity, testing, integration planning, and release coordination can now be prototyped in days or hours. That doesn't mean it is enterprise-ready, nor does it mean it's secure, scalable, supportable, compliant, or semantically aligned. But from the business perspective, the initial financial logic can look irresistible. That's where the danger starts.

Large enterprise platforms may increasingly be challenged as “too expensive,” “too broad,” or “too slow.” Business teams may begin asking why they should wait for centralized delivery when AI can help generate a narrow application that solves their immediate problem. One team replaces one workflow; another team duplicates one capability; another team builds around one platform constraint. Each decision looks rational locally, and may even create measurable short-term value. But architecture doesn't usually fail because of one bad decision. It fails when too many reasonable local optimizations weaken the structure no one is watching anymore.

Sergey Sergeyev is an enterprise architecture and AI governance leader with more than two decades of experience across enterprise technology, architecture governance, portfolio management, and AI strategy. His recent writing focuses on how AI-assisted development, agentic systems, and context-driven software generation are changing the economics, control model, and accountability structure of enterprise architecture. In his view, the discipline is entering one of its most important inflection points in a generation.

“Enterprise architecture must evolve from designing future systems to defining the structural rules of survivability,” said Sergeyev. “You will not always be able to define a fixed North Star because all it may take is a single change in a skills file, a prompt, a context boundary, or a business definition, and the application can be regenerated into something materially different.” The traditional North Star assumed convergence. It assumed the enterprise could define a stable target-state architecture and gradually move toward it through standardization, rationalization, migration, and governance. That model made sense when software was expensive, delivery capacity was constrained, and enterprise platforms were hard to replicate. AI changes that assumption.

The future enterprise may not converge toward one clean target state. It may continuously mutate. Applications may be generated, regenerated, extended, decomposed, and replaced at the edges. Business logic may move into prompts, orchestration layers, agent workflows, skills files, model instructions, API contracts, and embedded decision services. The organizations that survive will not be the ones that try to stop every form of fragmentation. They will be the ones that learn how to govern mutation without losing structural coherence. This is the Jenga tower problem.

• Jenga block jeopardy: “From the finance perspective, everybody may be happy at first,” said Sergeyev. “But from an architectural standpoint, every local optimization can weaken the structural integrity of the larger system. The enterprise can lose stability long before anyone sees a single catastrophic failure.” The pattern is easy to imagine. A business unit identifies the most expensive platform or process in a revenue-generating value stream. It builds or buys a narrow AI-assisted alternative that fits its immediate workflow better than the enterprise platform. Another team does the same. Then another. Across 20 or 30 value streams, the enterprise gradually becomes a loose federation of independently evolving capability fragments, each built on different assumptions, different data interpretations, different exception logic, and different governance models. At first, the tower stands. Then one day nobody understands how the full system actually works.

This doesn't make AI-assisted development bad. In fact, Sergeyev argues that AI is solving one of enterprise architecture’s oldest problems. For decades, architects struggled to keep documentation current, translate business requirements into technical structures, and keep architecture reviews aligned with delivery speed. AI can help close that gap. Requirements can be expressed in business language and translated into working software. Documentation can be generated alongside code. Architecture guardrails can be captured in skills files before development begins. Risk assessments can be accelerated. Code repositories can be analyzed to produce just-in-time documentation for engineers, architects, risk teams, executives, and support teams. That's a real breakthrough. But most of those wins are unbounded.

Even with million-token context windows, no model can reliably preserve the full business, technical, regulatory, semantic, operational, and historical context of a large enterprise in a single generation pass. AI can optimize inside the context it is given. It can reason within a bounded frame. It can generate based on available instructions, examples, data, and patterns. But the enterprise is not a single context window. It is a living system of revenue models, policies, exceptions, integrations, incentives, compliance obligations, legacy dependencies, tribal knowledge, customer promises, and operational scars. This is where the new Conway's Law emerges.

For decades, Conway’s Law told us that systems mirror the communication structures of the organizations that build them. In the AI era, systems will also mirror the context boundaries of the agents, prompts, tools, skills files, and orchestration patterns that generate them, whether the enterprise intended those boundaries or not. If the context is narrow, the system will be narrow. If the semantic model is incomplete, the system will encode incomplete meaning. If the skills file optimizes for local speed, the software may violate enterprise coherence without anyone intending it. If the AI agent has access to tools but lacks architectural boundaries, it may execute a technically valid action that creates enterprise risk. That's why the next version of enterprise architecture cannot simply be a prettier future-state diagram. It has to become a control system for coherence. 

• Coded in the dark: The support model also changes. “I don’t know how to support these applications in the traditional way,” said Sergeyev. “Historically, developers touched the code. They understood the design choices, the subroutines, the dependencies, and the failure points. But when software is generated or regenerated by machines, organizations may own the codebase without fully understanding the design rationale, dependency chain, or failure modes that produced it.” That problem extends beyond internal IT. Companies looking to package, reuse, or sell AI-generated applications face the same challenge. They may legally own the code, but ownership is not the same as understanding. Traditional support models still assume human-understandable ownership of code paths, dependencies, data flows, and failure modes. When that assumption weakens, production teams inherit systems that may be fast to create but hard to diagnose.

• Probabilistic by default: The deterministic model weakens too. “We are moving from systems where every branch of logic was explicitly designed to systems where behavior is inferred, ranked, generated, and orchestrated probabilistically,” said Sergeyev. “That does not mean enterprises should accept 60 or 70 percent correctness. It means governance must be designed for uncertainty, validation, observability, containment, and controlled authority.” This distinction matters. The integration endpoint may still be deterministic. An API may behave exactly as designed. A database may enforce a schema. A workflow engine may execute a known process. But the decision path that invokes those components may become probabilistic. An agent may choose which tool to call, which data to summarize, which exception to escalate, which workflow to trigger, or which recommendation to present. That is not traditional automation. That is operational decision-making under uncertainty. The accountability model then becomes more complicated.

Historically, organizations knew where to look when something went wrong. A security incident went to the CISO. A financial control failure went to the CFO. A production outage went to technology operations. A policy failure went to risk, legal, compliance, or the accountable business owner. The org chart may not have been perfect, but it gave the enterprise a map of responsibility. This is where the org chart starts lying.

• Ghosts on the org chart: An AI system may not make the final decision, but it may become the reason the decision happened. It may recommend, rank, route, summarize, approve, reject, escalate, trigger, suppress, or silently influence the human who clicks the final button. When that happens, accountability cannot be solved by asking, 'Who used the tool?' The better question is, 'Which human, system, model, agent, policy, data source, and control path contributed to this outcome?' “Your org chart may already be lying to you,” said Sergeyev. “There are digital entities influencing decisions without appearing in the org chart. If an AI agent affects a customer, an employee, a regulator, a financial outcome, or an operational process, who owns that decision path?” That question is now central to enterprise architecture. Agent identity is not just a security problem. It is an architecture problem. What is an AI agent in the enterprise? Is it a user? A service account? An application? A delegated identity? A digital worker? A risk-bearing actor? A temporary execution context? A workflow extension? A control surface? Most organizations don't yet have a clean answer. They will need one.

If agents can reason, invoke tools, call APIs, access data, trigger workflows, and operate across systems, then they need identity boundaries, authority models, access patterns, runtime monitoring, audit trails, containment, prompt injection defenses, escalation rules, and practical kill-switch patterns. But the kill switch is not just a button. It's an operating model.

Enterprise architecture should help define the kill-switch pattern, but ownership must connect security, product ownership, platform operations, risk, legal, compliance, and business accountability. Turning off an agent may break a workflow. Disabling a tool may interrupt a revenue process. Revoking access may stop an operational chain. Killing the wrong thing at the wrong time may create a new incident while trying to stop another one. That's why AI governance cannot remain a policy document sitting in a repository. It has to become runtime governance. It has to know what the agent is doing, what tools it can invoke, what data it can touch, what authority it has, what business process it participates in, what exceptions require escalation, and when it must stop. This is the new EA mandate.

For Sergeyev, the most reliable constant is not the application portfolio. Applications will mutate. Platforms will be challenged. Workflows will be regenerated. Interfaces will shift. Agents will enter and exit processes. But the way the enterprise creates value, serves customers, manages risk, fulfills obligations, and generates revenue remains more grounded in real-world operations. That's where enterprise architecture must anchor itself.

The next generation of EA should focus less on enforcing one fixed future-state application map and more on defining the structural rules that allow continuous change without enterprise collapse. That means interoperability contracts, semantic integrity rules, shared business capability definitions, data meaning controls, identity boundaries, runtime control planes, decision provenance, resilience patterns, human accountability chains, architectural observability, and standards that can be embedded into AI-assisted delivery before software is generated.

The discipline becomes less like traditional city planning and more like structural engineering for a living organism undergoing continuous cellular replacement. “We are being rescued by AI in one sense,” said Sergeyev. “AI is helping solve problems enterprise architecture has struggled with for years. It can help translate business intent, accelerate documentation, improve review cycles, and expose hidden complexity. But there is another problem. Organizations may not fully understand the systems the machines are beginning to build. We solved one problem, and we created several new ones.” That's the real inflection point.

AI will continue to solve local problems. It will help teams move faster. It will generate code, automate analysis, create documentation, recommend designs, operate workflows, and become part of the enterprise execution layer. But local speed is not the same as structural health. The architects who matter in the AI era will not be the ones who try to freeze the enterprise into one perfect future state. They will be the ones who define the structural rules that allow the enterprise to mutate without losing coherence. They will understand that architecture is no longer just about applications, platforms, integrations, and roadmaps. It is about survivability.

AI will not kill enterprise architecture. It will punish enterprises that confuse local optimization with structural design.