A phone is a phone. A chip is a chip. A bottle of shampoo is a bottle of shampoo.

While not as simple, having a physical product takes away some complexity when it comes to enterprise data management.

Service-oriented enterprises—from telecommunications to financial services—deal with intangibles. This makes building data products that much more complex.

It’s different when you’re dealing with intangible concepts, overlapping customer hierarchies, and similar data from a multitude of sources and channels.

We’ll explore the source of this complexity and how a well-thought-out data modeling approach can help simplify things.

The Challenge: Intangible Products & Complex Customer Hierarchies

Service-driven products change more often and at a faster rate than physical products.

An insurance policy can have small but significant changes that impact the entire data pipeline. Something that holds true for phone plans.

A single management decision can restructure entire product lines in a matter of months or even weeks.

Concepts such as coverage plans, adjustable subscriptions, network elements, or policy terms aren’t neatly packaged in a box; they’re open-ended, configured differently for customers, and are guaranteed to evolve.

It gets complicated in three ways:

• Misaligned Definitions: Different teams label the same business concepts in different ways, because their context is actual data. This leads to confusion and inconsistent reporting when the domains collide.
• Disconnected Views: A subscription bundle might be a standalone product for one business unit, but only a configurable component for another. This is more than a definition of something, but how businesses actually view different things in different contexts.
• Complex Relationships: A single customer can have multiple simultaneous relationships with your business (corporate contract, personal plan, family plan), each tied to distinct data streams and analytics workflows. How do you consolidate these relationships so that data isn’t lost or multiplied?

Let’s consider a telecom operator. Though services are fundamentally the same, the B2B, B2C, and wholesale business units have challenges of data interoperability.

Even if you’re able to standardize models within a unit, working across different teams requires data transformations. Multiple domains and data sources—each with its own logic—often pull you in conflicting directions.

Why Service Data Defies a Single Model: Complicated Product Structures

Physical products have a standard definition: every iPhone 16 Pro Max has to be built about the same way, no matter how many contractors are involved.

Services are more fluid; a subscription plan exists on paper (or possibly accurately in a database) and will be configured differently over time.

Services are also often renewed, upgraded, downgraded, or extended.

Let’s take a bank that offers a bouquet of financial services. You could have the same customer across a savings account, home insurance, and an investment account. Sales and marketing efforts might even converge to ensure the customer has a better experience.

Yet, these separate transactions create a web of data points when they’re billed, measured, and reported in the context of each line of business.

Conventional product-oriented data models don’t always account for such blurred edges.

Relying on Standard Frameworks & Why They Fall Short

Industry frameworks are a way to capture best-case business scenarios as a data model. They often break down when you try to adapt to your “real” data.

What looks logical becomes unwieldy in the messy world of enterprise operations.

Why?

Because every organization has unique processes. Your billing system might capture or label attributes differently from your provisioning system.

The net result: you still need additional modeling steps to integrate and rationalize data in a way that works for your context.

This doesn’t mean you ignore frameworks. Rather, you need a way to represent a framework such that adapting it to your enterprise data product is possible.

For instance, given that every telecom operator has the issue of intangible products, they often base their data models on a TM Forum standard (TMF SID: Product, Services, Resources domains). Similarly, financial institutions might rely on the ISO20022.

In our experience, you need an accessible and adaptable format of the model to make it work. A format that can be accessed by both business experts and data teams, a format that’s flexible enough while also being reusable.

Enterprise Data Product Design

From Technical Schema to Business Value

A purely technical approach—focusing only on how data is stored—often neglects the business context.

That’s where data product design comes in: you build data models around the business processes they serve, reflecting how subscriptions, customers, and relationships actually work in day-to-day operations.

Bridging IT and Business Expertise

Service operators have to orchestrate teams with vastly different priorities.

Your data engineering group might be well-versed in database schemas, while your product owners know the intricacies of how policies or subscriptions change over time.

True data product design happens when you bring these teams together, ensuring you model data in a way that’s both technically solid and business-relevant.

How Data Modeling and Enterprise Data Architecture Help

1. Model Intangible Concepts (Without Losing Your Mind)

How? Build a Common Business Glossary: Define key terms (e.g., “policy,” “bundle,” “subscription”) in one place so everyone speaks the same language.  

Design Modular, Reusable Data Products: Represent complex offerings as composable data products that are easy to reuse, adapt, or extend.

2. Leverage Industry Frameworks and Real Data Together

Adapt Existing Standards: Consider starting with TM Forum or ISO frameworks, but be ready to adapt them to fit your operational reality.  

Reverse Engineer Your Source Systems: Take inventory of your existing data flows and determine how best to map them onto more standardized conceptual models.  

Stay Practical: Focus on capturing essential data structures and relationships without getting caught up in every last detail of legacy data sources.

3. Drive Incremental Transformation

Start Small: Tackle a high-impact problem (like consolidating subscription data across your channels) and iterate from there.

Document Faster: Keep a clear record of how your services are structured, laying the groundwork for future transformations, whether cloud migration or new data products.

If you’re struggling to unify disparate sources—whether you’re dealing with overlapping subscriptions or customer relationships across business—investing in data modeling is the key.

Building a common vocabulary and reusable structures that strike a balance between standards and real-world requirements can power your data architecture to solve actual business problems (rather than just engineering ones).