Enterpriseland and Productland

Are you modeling data in a cost-center or a revenue-driver?

This is an adaptation from an article I wrote last year called “WTF is a Data Team?”, where I introduce the notions of Enterpriseland and Productland. Basically, it comes down to whether you’re working in a cost-center, or a revenue-driving part of the business.

The broader chapter on Organizations and Data Modeling (of which this is a part) is almost done. I’ve been battling a nasty eye infection since Sunday, so it’s been very difficult for me to write. But I’m plugging away and will post it soon. Fair warning - it’s gonna be long. But, I think the organizational and human-relations parts of data modeling don’t get nearly the coverage they deserve. Since most data initiatives stall because of people, you’d think this is worth discussing, right?

Thanks,

Joe

---

Ellie makes data modeling as easy as sketching on a whiteboard—so even business stakeholders can contribute effortlessly. By skipping redraws, rework, and forgotten context, and by keeping all dependencies in sync, teams report saving up to 78% of modeling time.

Bridge reality with Data! Read more here.

Thanks to Ellie.ai for sponsoring this post.

---

To understand why a data model succeeds or fails, one must first understand the organizational context in which the data model is created. Who is the data for? How does the organization perceive the value of its data? The answers to these questions reveal that data modeling practices exist within two fundamentally different universes.

In the first universe, which we can call "Enterpriseland," data teams typically function as a back-office, internally-facing component of the IT department. Their primary mandate is to serve the business with reports, dashboards, and what are often vaguely termed "insights." The work might be overseen by a Chief Information Officer (CIO) or Chief Data Officer (CDO), who manages the team's budget and sets its priorities.

Critically for Enterpriseland, data is a byproduct of business operations, often referred to as "business exhaust." It is not the core product that the company sells. Consequently, the primary challenge for data modelers is to retroactively impose structure and meaning onto data that was not created with analytical rigor or AI in mind.

Data modeling in Enterpriseland dictates a specific, inward-facing approach. IT is responsible for managing internal-facing systems and reports. While IT might maintain the data of these systems, most of these systems are third-party and come with their prepackaged data models. When it comes to data modeling, the principal aim is to support business intelligence (BI) and analytics, where the data model is often derived from these various systems. The effort usually focuses on establishing a "single source of truth" within a centralized data warehouse. Ideally, the data warehouse will answer most questions throughout the business. However, data modelers in Enterpriseland are often reacting to business requests. The process can be slow, as making changes to a large, centralized model without disrupting existing reports is a delicate and complex task. Some might call it dangerous.

Enterpriseland is a constant source of complaints and frustration for data modelers and other technical people. The most common struggle in Enterpriseland is quantifying the return on investment (ROI) for IT, and data modeling by extension. What is the precise business value of a dashboard? Why invest in data modeling at all? The ambiguity about the value of data is pervasive. A worthwhile thought experiment is to ask, "What would happen if the data team and its models vanished tomorrow?" If the answer is "critical operations would cease," its value is clear. If the answer is "nothing," the answer is also clear. Many teams reside in a grey area where the impact is unknown, leaving them vulnerable to the perception of being a cost center, the eternal problem for traditional IT departments. In case you’re concerned, we’ll discuss ways to sell data modeling initiatives later in this chapter.

The second universe, "Productland," operates under a different set of principles. Here, data is not a byproduct. In most cases, data is the product, or at least a critical component of it. Consider a ride-sharing application, where its ability to connect drivers and riders efficiently is an intensely data-driven product. Or a popular streaming service where data is used to recommend movies and music to millions of users, all on a personalized basis. In Productland, the lines between software engineering, data engineering, AI/ML engineering, and data science blur.

Productland adopts a functional approach to data modeling, where models are designed with a distinct purpose. Instead of building data models for retrospective reports, data is used to power a live feature. This could be a recommendation engine, a fraud detection system, or a dynamic pricing algorithm. The model's performance is directly tied to the product's performance.

Instead of a single, monolithic enterprise model, Productland favors a constellation of smaller, domain-oriented data models. Each model is optimized for a specific task or feature. This aligns closely with modern architectural concepts, such as Domain-Driven Design and the principles behind a Data Mesh, both of which we’ll learn about later.

Finally, data modeling in Productland is an integral part of the product development lifecycle, where the feedback loop is immediate and measurable. If a new model for a feature improves a core product KPI, such as user engagement or conversion rate, the value is unambiguous and directly attributable to the team's work.

In Productland, the ROI of a data model is rarely in question. Its value is calculated not in the nebulous currency of "insights" but in the tangible metrics and results that drive the business forward. The data model is an asset that generates revenue or enhances user experience, not an artifact used to report on past events.

For decades, teams in Enterpriseland have struggled to justify their value. However, a shift is underway as these organizations seek to emulate the success of their counterparts in Productland. This transition is driven by two primary forces currently at work. First is the widespread adoption of AI, which requires high-quality, multimodal, product-oriented data that can be utilized in various ML and AI use cases. Seemingly every company is (or wants to be) an AI company. Data modeling is receiving increased attention as a result of the surge in interest in AI. Second is the rise of "data-as-a-product" (or data product) thinking, where the primary concern is no longer just internal reporting but a user-centric view where data is the product used and purchased by the end-user.

It’s important to note that the Enterpriseland and Productland universes can co-exist within the same organization. In Big Tech’s Productland, I know many software, data, and ML engineers working on cutting-edge data products that are used by millions of users every day. Within the same organization in Enterpriseland, I also know analytics engineers and data analysts who work hard to produce internal reports for stakeholders, who are often very data-driven. I get the impression that these companies are generally more data-driven, and even in Enterpriseland, data teams are given plenty of support. Perhaps this is due to the data-native origins of these companies. It’s hard for me to say. However, when these universes collide, data is viewed as a value creator rather than a cost center. Data models are designed to enable new business capabilities or directly improve customer experiences. Here, data moves from the cost side of the ledger to the revenue-generating side.

Knowing if you’re working in Enterpriseland or Productland will save you a lot of time (and headache) understanding how to work with data, and what’s expected from you. Many frustrated engineers, analysts, and data scientists simply have misaligned expectations from the reality of where data sits in their organization, and how data is perceived. You don't have a clear idea of the game you're playing.

The frustration mainly stems from thinking you’re in Productland (where data drives revenue), when the organization thinks you’re in Enterpriseland (where data is a cost center). Changing this perception is very challenging, as the Enterpriseland team will argue that they deliver “business value” with data. Perhaps they do, but value is ultimately in the eye of the beholder.