AI Strategy →

Enterprise Software Strategy in the AI Era: What Changes and What Stays the Same

AI changes the economics of building, buying, and extending software. The decisions at the top of the portfolio — what to invest in, what to buy, what to automate — are more consequential in the AI era, not less.

At TRW — a Fortune 122 diversified technology company — one of the questions I was brought in to help answer was whether to build a custom enterprise database-replication mechanism for inventory control or adopt existing commercial software. The comparative cost, the integration constraints, the maintenance burden on each path, the organizational capability to support each option — working through those specifics took months.

In the AI era, the same question has a third option that complicates the analysis in useful ways. But the fundamental strategic logic has not changed.

quadrantChart
title Enterprise Software Investment in the AI Era
x-axis Low Strategic Differentiation --> High Strategic Differentiation
y-axis Low AI Acceleration Potential --> High AI Acceleration Potential
quadrant-1 Build custom with AI assist
quadrant-2 Automate existing workflows
quadrant-3 Buy off the shelf
quadrant-4 Extend with AI augmentation
Customer-facing platform: [0.82, 0.75]
Reporting and analytics: [0.28, 0.85]
CRM and sales workflow: [0.18, 0.60]
Core data infrastructure: [0.75, 0.48]
Internal tooling: [0.35, 0.70]

What the Build / Buy Framework Actually Is

Every enterprise software decision sits somewhere on two axes.

The first is strategic differentiation: does this software encode something about how your business operates that competitors cannot easily replicate? A proprietary pricing model, a workflow that reflects 20 years of domain knowledge, a data processing capability specific to your customer base — these are differentiated. Authentication, expense reporting, scheduling, customer service routing — these are not.

The second is integration dependency: how tightly does this software need to connect to the rest of your technical estate? High integration dependency raises the cost of buying a solution not designed for your environment, because every integration point becomes a customization. It raises the cost of building, too, but the cost is known rather than discovered post-deployment.

The right call on any specific decision depends on where it falls on those two axes. The AI era has not changed the framework. It has changed several of the inputs.

What AI Changes in the Analysis

The cost of certain kinds of custom development has dropped. AI coding assistance reduces the time and labor required to build systems that follow well-understood patterns — CRUD applications, integration adapters, reporting layers, workflow automation, internal tooling. What would have required a team of three engineers and six months might now require one engineer and two months with AI assistance. That changes the build-versus-buy math on a specific class of problems.

It does not change the math on everything. Building software still requires architectural judgment, security review, testing, documentation, and a maintenance plan. AI accelerates the generation phase; it doesn’t eliminate the governance work that makes a codebase maintainable five years later.

The practical implication: AI lowers the cost threshold for building differentiated software. Problems that were previously not worth building because the ROI didn’t justify the development cost may now be worth building. That is a genuine shift. The mistake is reading it as a reason to build everything. The more useful question is still: does this encode something specific to how we operate, or is it commodity infrastructure that someone else has already solved?

At TRW, the eventual recommendation on the database-replication question was to weigh the long-term operational cost of custom maintenance against the integration flexibility it provided. AI doesn’t eliminate that analysis. It changes the input values.

The Enterprise Software Debt Problem in the AI Era

First American Financial spent a decade acquiring more than 80 companies. By the time I was working there as enterprise architect, the organization had accumulated over 700 software applications — dozens of overlapping CRM systems, redundant policy management tools, half-integrated data pipelines that had been promised post-close and never finished. The consolidation and remediation work was one of the most expensive consequences of the acquisition strategy, and it was rarely counted in the deal economics.

AI-era enterprises are creating a version of the same problem without acquisitions.

When AI coding assistance is adopted without portfolio governance — when teams across the organization each use AI to build systems, internal tools, automation workflows, and data pipelines — the catalog grows faster than governance can keep up. Six months later, there are four different AI-generated versions of the same workflow, built by different teams, integrated differently, documented inconsistently, and owned by nobody.

The solution is not to restrict AI adoption. It is to apply the same portfolio logic to AI-generated software that mature companies apply to acquired software: catalog it, look for overlap, make deliberate decisions about what to consolidate, and establish an architectural standard that new AI-generated work has to meet before it gets added to the estate.

The Decisions That Matter Most Now

The most consequential enterprise software strategy decisions in the AI era are not about which AI tools to buy. They are about portfolio governance.

What is the threshold for building something new versus buying or extending something existing, and has that threshold been adjusted to account for the new AI-assisted cost of custom development?

What is the architectural standard that AI-generated code has to meet before it enters the production estate?

Who owns the catalog? Not the backlog, not the sprint plan — the full picture of what software the organization operates and who is accountable for each piece.

These decisions determine whether AI acceleration compounds or degrades over time. The companies that get this right will have a leaner, more coherent software estate at the end of the decade than they started with. The ones that don’t will spend the early 2030s doing what large enterprises spent the 2000s doing: consolidating an estate that grew faster than anyone tracked it.

Frequently Asked Questions

How does AI change the build versus buy decision for enterprise software?

AI lowers the cost of certain kinds of custom development, which shifts the economics of the build side of the equation without changing the buy side. The trap is treating this as a signal to build more. What AI actually changes is the types of work worth building: differentiated business logic, proprietary data workflows, and systems where your specific processes don't map well to commercial off-the-shelf options. Commodity infrastructure — authentication, scheduling, notification, reporting — is still better bought. AI makes building the differentiated parts faster and cheaper; it doesn't make buying commodity parts less rational.

What is the enterprise AI software debt problem?

When companies adopt AI coding assistance without portfolio governance, they accumulate AI-generated code across teams and projects without a coherent architectural strategy. Over time, this produces a version of the same problem that plagued enterprise acquisitions in the 2000s: dozens of overlapping capabilities, inconsistent patterns, undocumented systems, and a maintenance burden that compounds with each new AI-assisted project. The solution is not to slow down AI adoption but to apply the same portfolio governance logic that mature companies apply to acquired software: catalog it, consolidate where there is overlap, and make deliberate decisions about what to maintain versus retire.

How should enterprise technology leaders think about AI-generated software in their architecture?

AI-generated code is not categorically different from human-written code in terms of what it requires: documentation, testing, ownership, and a maintenance plan. What is different is the speed at which it can be created, which means the catalog can grow faster than governance can keep up if there is no discipline at the portfolio level. Enterprise technology leaders should apply the same architectural review process to AI-generated systems that they apply to acquired systems: where does this fit in the portfolio, who owns it, how does it integrate, and what is the deprecation plan if it needs to be replaced.

Shawn Livermore — Fractional CTO & Chief AI Officer
About the Author

Shawn Livermore

Fractional CTO and Chief AI Officer with nearly 3 decades of enterprise architecture experience. Clients include Kelley Blue Book, LERETA ($18B property tax processor), First American Financial, Carvana, WellPoint/Anthem, and PacifiCare. 92 client reviews, 5-star average.

View full background →

Need a fractional CTO or CAIO?

Technology leadership without the full-time headcount. Engagements start with a conversation.

Man writing a flowchart diagram on a whiteboard with a blue marker.