The Enterprise. Simplified.

Posted On August 25, 2026

Separating Business from Implementation

This is Part 2 of The Enterprise. Simplified. In Part 1, I introduced the vision.

One of the first questions I ask when meeting with an executive team is deceptively simple.

“What are you trying to accomplish?”

Sometimes I phrase it differently.

“What are your strategic objectives?”

The answers are pretty much consistent. Organizations want to improve customer experience, reduce operating costs, increase revenue, shorten delivery times, expand into new markets, or improve operational efficiency. Regardless of the industry, the conversation begins with the business. Everyone in the room understands what success looks like because we’re talking about customers, products, services, employees, suppliers, and outcomes—not technology.

As the conversation continues, however, something begins to change. The discussion shifts from what the organization is trying to accomplish to how it will accomplish it. Strategic objectives become projects. Projects become applications. Applications become APIs, databases, integrations, reports, and data pipelines. Before long, we’re no longer discussing customers or products. We’re discussing Salesforce objects, SAP tables, REST services, message brokers, and cloud platforms.

That transition is completely understandable. Projects exist to implement business capabilities, and applications are how those capabilities are operationalized. Every project makes design decisions that are appropriate for its objectives, timeline, budget, and technology choices. None of those decisions are inherently wrong.

The Inherent Complexity

The challenge is that projects are temporary, but the implementations they produce become part of the enterprise. Over time, each project leaves behind another application, another integration, another security model, another API, another interpretation of business rules, and another way of representing the organization. Individually these implementations solve important problems. Collectively they become the enterprise that everyone else must navigate.

Perhaps that’s why enterprise complexity never seems to decrease.

For more than three decades we’ve invested in technologies intended to simplify enterprise information. We built enterprise data warehouses to consolidate reporting. We introduced operational data stores to integrate operational information. We embraced data lakes and later lakehouses to manage scale and variety. We migrated to cloud platforms, adopted semantic layers, implemented metadata catalogs, and more recently began building AI-ready data platforms. Each generation solved important technical problems and delivered real business value. Access became easier. Performance improved. Governance matured. Analytics became more sophisticated.

Yet despite all of that progress, every major initiative still seems to begin in much the same way. Teams identify source systems, interpret application schemas, reconcile conflicting definitions, rediscover business rules, and map relationships between systems. The technologies have evolved dramatically, but the enterprise is still largely presented through the applications that implement it. We’ve become exceptionally good at moving information, integrating information, and optimizing information. We haven’t spent the same effort simplifying how the enterprise represents itself.

I’ve often found that interesting because software companies rarely expose their products that way.

When we purchase enterprise software, we’re presented with business capabilities. We create customers, place orders, approve invoices, schedule shipments, and manage products. We’re not expected to understand the vendor’s database schema, internal APIs, storage model, or service architecture. Those implementation details are intentionally hidden because they don’t help customers accomplish their work. As a result, the software vendor can redesign its implementation, replace technologies, or modernize its architecture while presenting a largely stable experience to its customers.

Why shouldn’t enterprises work the same way?

Instead of exposing applications as the primary interface to the business, perhaps the enterprise itself should expose a stable representation of its customers, products, employees, suppliers, contracts, and business capabilities. Applications would continue implementing those capabilities, but they would no longer become the primary way the enterprise understands itself.

At this point someone usually asks, “People still have to use the applications, don’t they?”

Absolutely.

Operational systems exist to execute business processes, and they should continue to do exactly that. Orders need to be created. Invoices need to be generated. Employees need to be hired. Claims need to be processed. Those transactions belong in the operational systems designed to execute them. Nothing about this perspective suggests replacing ERP, CRM, HCM, or industry-specific operational platforms.

The challenge is that executing business processes is only one way participants interact with the enterprise.

Executives need to understand performance. Analysts answer business questions. Developers build new capabilities. Integration platforms connect systems. Governance teams enforce policies. Partners exchange information. Increasingly, AI agents assist employees, automate work, and make decisions within defined boundaries. Most of these participants are not interested in how a customer is represented inside a CRM or how an order is stored within an ERP. They need to understand the business, not the implementation.

Even when they need to execute a business process, the implementation should remain largely invisible.

Consider an AI agent asked to create a customer order. The agent shouldn’t need to determine whether the order ultimately resides in SAP, Oracle, Microsoft Dynamics, or another operational platform. It shouldn’t need to understand database tables, application-specific APIs, or integration flows. It should simply invoke the business capability to Create Order, supplying the required business information. The enterprise determines which operational systems execute that request. The same principle applies to a developer creating a new application, a planner analyzing demand, or a business partner integrating with the organization. They interact with business concepts and business capabilities while operational systems remain responsible for execution.

That distinction changes the architectural conversation.

An Alternative View

Instead of asking how every new platform should reconstruct the enterprise from operational systems, we begin asking how the enterprise should consistently present itself to every participant. Data warehouses, lakehouses, semantic layers, AI platforms, operational applications, and integration technologies all have important roles to play, but they become consumers of a stable enterprise representation rather than independent interpreters of the business.

The objective isn’t to simplify the business. Businesses are inherently complex.

The objective is to simplify how the enterprise presents itself and how participants interact with it.

Those are very different problems.

When we stop equating the business with its implementations, the enterprise becomes easier to understand, easier to govern, easier to integrate, easier to evolve, and ultimately easier for both people and AI to participate in. Technologies will continue to change, operational systems will be replaced, and new architectural patterns will emerge. The enterprise, however, should remain recognizable regardless of how those implementations evolve.

If that’s true, then another question naturally follows.

If the enterprise should present a stable representation of itself, what exactly should that representation contain, and who should own it?

That’s where we’ll go next: Part 3 – Enterprise Information as a Business Asset.