The Enterprise. Simplified.

Posted On August 25, 2026

Enterprise Information as a Business Asset

This is Part 3 of The Enterprise. Simplified. In Part 2 , I covered the importance of separating business from implementation.

One of the things I’ve noticed over the years is that every significant project seems to spend a surprising amount of time trying to understand the business. Whether the objective is implementing a new ERP system, building a data warehouse, migrating to the cloud, deploying a semantic layer, or introducing AI, the work often begins in much the same way. Teams identify customers, products, suppliers, employees, orders, contracts, and countless other business concepts. They interview subject matter experts, reconcile conflicting definitions, interpret application schemas, and gradually build an understanding of how the organization works. The technology changes, but the exercise rarely does.

I’ve often wondered why.

If the enterprise already understands its customers and products, why does every project begin by rediscovering them? More importantly, why do those discoveries so often differ from one initiative to the next? It seems that every project develops its own perspective of the business, not because anyone intends to create inconsistency, but because each initiative naturally focuses on its own objectives. The result is that we slowly accumulate different representations of what is fundamentally the same enterprise.

Enterprise Knowledge

Perhaps part of the reason is that we tend to think about business concepts as objects rather than knowledge. A customer isn’t valuable simply because we know one exists. The value lies in what the enterprise knows about that customer. Their name, location, credit status, preferred language, assigned account manager, support history, purchasing behavior, contractual relationships, and countless other characteristics collectively describe the customer. Remove those attributes, and the customer becomes little more than an identifier.

The same observation applies everywhere. Products become meaningful because we know their specifications, pricing, availability, and lifecycle status. Employees become meaningful because we understand their skills, responsibilities, reporting relationships, certifications, and organizational roles. Orders, suppliers, assets, and contracts are no different. What gives these business concepts meaning isn’t their existence; it’s the enterprise knowledge expressed through their attributes.

Once I started looking at the enterprise that way, another pattern became difficult to ignore. Projects rarely introduce entirely new business concepts. More often, they extend the enterprise’s understanding of concepts that already exist. A CRM implementation contributes sales-related information about customers. Finance contributes payment terms, credit limits, and financial relationships. Marketing contributes preferences and segmentation. Customer service contributes support history and service levels. None of these capabilities creates a different customer. Each simply adds to what the enterprise knows about the same one.

That observation also changes the way we think about ownership. We often ask which application owns the customer, but perhaps that’s the wrong question. Applications own their implementations. Business capabilities are responsible for the information they create and maintain. The customer itself belongs to the enterprise. Sales contributes sales attributes. Finance contributes financial attributes. Marketing contributes marketing attributes. Customer Service contributes service attributes. The entity remains stable while the enterprise’s understanding of it continues to grow.

A Clear Representation

As I reflected on this, I realized there was nothing particularly new about the idea itself. Data architects have been modeling businesses this way for decades. At their core, logical data models identify the fundamental entities of an organization, describe their relationships, and define the attributes that give those entities meaning. Yet somewhere along the way, those models became viewed primarily as design artifacts for databases and application development rather than as representations of the enterprise itself.

Perhaps we’ve underestimated what logical data architecture really represents.

A logical model isn’t simply an intermediate step on the way to a physical database design. It is one of the clearest implementation-independent descriptions of how an enterprise understands itself. Long before a database table is created, an API is published, or an application is implemented, the enterprise already knows what constitutes a customer, a product, an order, or a supplier. Those concepts, their relationships, and the attributes that describe them exist because of the business, not because of the technology.

When you look at it that way, the purpose of logical data architecture changes. Instead of serving primarily as documentation for implementation projects, it becomes the foundation upon which implementations are built. Operational applications execute business processes. Data warehouses and lakehouses organize information for analysis. Semantic layers simplify access. AI systems reason over enterprise information. Each serves a different purpose, but none should redefine the enterprise. They should all begin with the same implementation-independent representation and extend it where new enterprise knowledge is created.

That, to me, is the real value of attribution. Attributes are far more than fields in a database or properties in an API. They represent what the enterprise knows about itself. As business capabilities evolve, they contribute new attributes, refine existing ones, and deepen the enterprise’s understanding without creating another version of the business. Projects come and go. Technologies continue to evolve. But the enterprise representation becomes richer over time because every initiative contributes to the same shared understanding rather than creating another isolated implementation.

If that’s the role of enterprise information, then the next question becomes equally important. How do business capabilities operationalize that information, contribute new enterprise knowledge, and expose the actions that allow the rest of the organization—and increasingly AI—to participate in the business?

This is what I’ll cover in Part 4 – Business Capabilities Operationalize the Enterprise.

---