This article discusses evolving trends in data modeling capability.
This article is the third one in the Data Management Maturity Trends 2025 series. In this article, I focus on the trends in the development of the data modeling capability and its core components.
The annual results of the Data Management Maturity Scan, which is a part of the O.R.A.N.G.E. Data Management Framework, form the basis for these trends. The scan results have been published on my site, www.datacrossroads.nl, since 2019.
This article will:
• Present the definition of the data modeling capability accepted by the O.R.A.N.G.E. Data Management Framework (DMF).
• Highlight six-year trends in the development of this capability and its components.
• Provide practical recommendations for further development of this capability.
Governance for Data Modeling
Let’s first discuss the challenges organizations worldwide face with establishing a data governance framework and function.
Definition and Positioning Challenges
I have widely addressed the challenges of defining the “data modeling” capability in my books and publications. The key point is that there are different approaches to recognizing and defining data modeling.
Let me summarize the industry approaches:
- DAMA-DMBOK2 considers data modeling as a separate Knowledge Area. It defines it as a “process of discovering, analyzing, and scoping data requirements, and then representing and communicating these data requirements in a precise form called the data model. This process is iterative and may include a conceptual, logical, and physical model.” So, the key point is that this is a process with key outcomes: data models. What is interesting is that the DAMA Dictionary provides a quite different definition, defining data modeling as a method for documenting data models with different purposes.
- The TOGAF® Standard, v.10, the leading industry architecture framework, considers data models as the deliverables of data architecture.
- The DCAM, the Data Management Capability Model by the EDM Association, applies the TOGAF® approach to positioning data modeling as a part of architecture.
The O.R.A.N.G.E. Data Management also follows the TOGAF® Standard approach. It defines the data modeling capability as a company’s ability to deliver, maintain, and manage data models that help to “[…] a) define and analyze data requirements, b) design logical and physical structures that support these requirements, and c) define business and technical meta-data.” The second part of this definition comes from the DAMA Dictionary. It highlights the key areas of the data model’s usability.
So, what do we have? Data modeling is either a process, or a method, or a capability. It is either an independent data management subject area or part of data architecture. So, the choice is yours. In my opinion, the labeling of this capability is less important than properly defining its deliverables. Let’s discuss it in the following paragraph.
Design Challenges
The answer to the question, “Why does business need data modeling?” defines the set of its deliverables. The definition of this capability already leads us to a simple answer: we need data modeling to understand data to make effective use of it. For that, we need to define it and place it in a particular context that can be done at different abstraction levels. To achieve this goal, we need several outcomes:
Business glossary – it describes data using terms and their corresponding definitions.
Conceptual model – it defines the data domains and helps to optimize business around them. Doing it helps link business to the data it uses and produces.
Logical model – it helps identify data requirements and prepare requirements for designing IT solutions.
Physical model – it forms the foundation for implementing IT solutions.
All these data modeling products describe data at different abstraction levels. Therefore, they serve different purposes and cover the needs of different stakeholders. They all describe the same data at different abstraction levels and must be linked. And here, we face some implementation challenges.
Challenge 1: Different approaches to modeling data exist.
The first challenge is the use of different methodologies for documenting the models.
Figure 1 demonstrates the two approaches: the classical/canonical approach and the semantic approach.
Figure 1: Approaches to designing and linking data modeling outputs.
The canonical approach focuses on designing conceptual and logical data models. A business glossary provides business definitions to the data elements in these models. The conceptual model includes a set of key data entities related to the specific business model. Then, the logical model details the conceptual model by breaking down the key data entities and by adding attributes to them. Still, a business glossary provides the meaning of these entities and attributes. So, the business glossary’s role is to provide the meaning of data elements in both models.
In the semantic approach, the role of a business glossary is quite different. It replaces the conceptual model by demonstrating not only the meaning of the key data entities but also the relationships among them. So, instead of a conceptual model plus business dictionary, we now have a semantic model. Then, the semantic conceptual model can be detailed into a semantic logical model.
Be aware that you may face totally different definitions of a semantic model. So, I describe only my vision of it here.
When choosing between these two approaches, you should be aware of the associated challenges.
The canonical approach focuses on designing conceptual and logical data models. A business glossary provides business definitions to the data elements in these models. The conceptual model includes a set of key data entities related to the specific business model. Then, the logical model details the conceptual model by breaking down the key data entities and by adding attributes to them. Still, a business glossary provides the meaning of these entities and attributes. So, the business glossary’s role is to provide the meaning of data elements in both models.
In the semantic approach, the role of a business glossary is quite different. It replaces the conceptual model by demonstrating not only the meaning of the key data entities but also the relationships among them. So, instead of a conceptual model plus business dictionary, we now have a semantic model. Then, the semantic conceptual model can be detailed into a semantic logical model.
Be aware that you may face totally different definitions of a semantic model. So, I describe only my vision of it here.
When choosing between these two approaches, you should be aware of the associated challenges.
Challenge 2. An organization may need more than one conceptual model depending on the business model. These models must be linked.
The canonical approach, as shown in the DAMA-DMBOK2, illustrates the case where an organization has a single conceptual model. An Organization with multiple and varying business models may require multiple, distinct conceptual and underlying logical models. This situation is common in practice, where even different business domains within a single business require distinct models. If it is true, then we face an associated additional task: map these models.
Challenge 3. Logical models can be application-agnostic or application-dependent. The same application-agnostic model can be applied to different applications.
As we already discussed, data models can serve different purposes and needs of various stakeholders. Logical, application-agnostic data models help identify data and data quality requirements. Logical application-dependent models assist in designing and implementing applications. The same application-agnostic model can be applied to multiple application-dependent data models.
Challenge 4. Different data modeling schemes require specific diagramming notations.
The DAMA-DMBOK2 mentions six common schemes, each with diagramming notations specific to that scheme. The usage of these schemes depends on the choice of databases. A company with numerous types of databases may be forced to use different methods to document its data models.
Implementation Challenges
Challenge 1 – Data modeling deliverables face challenges in practice.
I’d like to start this paragraph by sharing the results of a poll I recently performed on LinkedIn. The question I asked was straightforward and focused on a data modeling deliverable that is the most challenging to establish effectively in practice.
Figure 2 represents the results of the poll.
Figure 2: Trends in challenges with data governance implementation.
For me, the key signal is that the business glossary remains the most challenging deliverable. I would interpret it to mean that many organizations are still working on the foundational element of data modeling: shared business meaning.
A business glossary feeds other deliverables, including data models, requirements, and critical data. It is also required for other data management capabilities. When the glossary remains difficult, it usually shows that the organization has not yet moved far enough toward the more advanced modeling work that depends on it.
Challenge 2 — Weak Maintenance After Project Delivery
Another familiar challenge appears after the project ends. A data model may be useful during design, but it quickly loses value when business processes, reports, products, or applications change while the model remains static. I see this especially when ownership of model maintenance is unclear, and change processes treat models as documentation rather than living governance assets. Over time, people stop trusting the model, and the organization loses an important source of shared business and data understanding.
Challenge 3 — Involving Business People in Modeling Work
Another challenge I often see is the difficulty of involving business people in data modeling work. Many stakeholders can discuss reports, processes, and data issues, but they find it harder to validate business definitions, explain relationships in data models, and formulate their data requirements.
As a result, data modeling can quickly become a technical exercise. The model may look correct from a system perspective, yet it still misses how the business understands and uses data in practice. This weakens one of the main purposes of data modeling: reflecting business reality in a structured way.
Maturity Measurement Challenges
When I assess data modeling maturity, I would ideally like to measure outcomes. The real question is not whether an organization has created a business glossary or data models, but whether these deliverables improve the organization’s understanding, management, and use of its data.
In practice, however, measuring these outcomes is difficult. Data modeling rarely produces a business result on its own. Its impact usually appears through other capabilities, such as data quality, analytics, system development, or AI. This makes it difficult to separate the contribution of data modeling from the effects of other activities.
For this reason, this review still relies mainly on outputs. They provide tangible evidence that can be assessed consistently across different organizations and compared over several years. I therefore look at the maturity of four key deliverables: the business glossary, data models, documented information and data requirements, and identified critical data.
I see this as a practical measurement approach rather than a claim that outputs equal success. The existence of a deliverable tells me that a capability is being built. Its use, quality, and contribution to business results tell me whether that capability is actually working.
This distinction is important when interpreting the trends that follow. They show how far organizations have progressed in establishing the foundations of data modeling, rather than directly measuring the business value those foundations create.
Trends in Data Modeling Development
General Trends
When I look at the data modeling maturity trend from 2019 to 2025, I see steady progress, although most organizations are still somewhere in the middle of the maturity journey.
Figure 3: Trends in data modeling development.
One change is especially visible: the uncontrolled level has become much less common. For me, this shows that data modeling is increasingly moving away from completely unmanaged practices.
At the same time, in development remains the largest group throughout the period. This suggests that many organizations are still formalizing how data modeling is performed and managed. They are making progress, but the capability is not yet fully established.
The higher maturity levels show a less consistent picture. The share of capable organizations grows in some years, while the effective level remains relatively small. Overall, I see a capability that is becoming more structured, but still has considerable room to mature operationally.
Trends in Core Data Modeling Capability Outputs/Indicators
The core indicators help explain why this transition takes time.
Business glossary
When I look at the business glossary trend (Figure 4), I see gradual movement away from completely informal practices. By 2025, fewer organizations remain at the informal stage, while the in-design stage has become more prominent. The share reaching implementation or operational use is still much smaller.
Figure 4: Trends in developing business glossaries.
For me, this shows that many organizations recognize the need for a shared business vocabulary, but are still working out how to formalize and maintain it. The business glossary is increasingly being designed as a managed deliverable, yet embedding it into everyday data management practice remains a challenge.
Data models
For me, Figure 5 shows that data models as a deliverable are still far from consistently operationalized. Informal practices remain the largest group, although their share has declined in recent years. At the same time, the in design stage becomes more visible in 2025, while implementation remains relatively stable.
Figure 5: Trends in designing data models.
What stands out to me is that the operational level is still comparatively small. This suggests that many organizations create data models, but fewer have established a mature approach to maintaining and using them as part of regular data management.
Data and information requirements
Figure 6 gives me a more mixed picture for documented data and information requirements. The largest share still sits at the informal and in design stages, while the operational level remains relatively small.
Figure 6: Trends in establishing data and information requirements.
What I find particularly interesting is the fluctuation between design and implementation over the years. This tells me that organizations are working to formalize this deliverable, but the transition from defining requirements to managing them consistently in practice remains uneven.
Critical data
What stands out to me in Figure 7 is that identifying critical data remains largely a deliverable under development. The in-design stage dominates throughout the period, while the share at implementation rises noticeably in 2025. At the same time, the informal stage declines.
Figure 7: Trends in identifying critical data.
For me, this suggests that more organizations are moving from simply recognizing critical data toward formally defining and implementing how it should be identified. However, the relatively small operational share shows that this practice is not yet fully embedded.
What the Maturity Results Add to the Poll
When I compare the maturity results in Figures 4-7 with the poll results on Figure 2, I see a clear connection. The business glossary stands out as the most challenging deliverable in the poll.
The maturity results help explain why. Across all four deliverables, many organizations are still concentrated at the informal or in design stages. Operational maturity remains limited.
For me, this does not mean that data models, requirements, or critical data are easier. It may simply mean that many organizations are still struggling with the semantic foundation that comes first.
Until business terms and definitions are sufficiently established, it is difficult to move consistently into the next modeling deliverables.
For me, this suggests that more organizations are moving from simply recognizing critical data toward formally defining and implementing how it should be identified. However, the relatively small operational share shows that this practice is not yet fully embedded.
What the Maturity Results Add to the Poll
When I compare the maturity results in Figures 4-7 with the poll results on Figure 2, I see a clear connection. The business glossary stands out as the most challenging deliverable in the poll.
The maturity results help explain why. Across all four deliverables, many organizations are still concentrated at the informal or in design stages. Operational maturity remains limited.
For me, this does not mean that data models, requirements, or critical data are easier. It may simply mean that many organizations are still struggling with the semantic foundation that comes first.
Until business terms and definitions are sufficiently established, it is difficult to move consistently into the next modeling deliverables.
Recommendations
When I look at these trends, I see one practical message. Data modeling is becoming more structured, but many organizations are still building the foundations and connecting individual deliverables into a working capability.
Build the semantic foundation first.
The poll results make this especially clear. If the business glossary is still difficult to establish, the same ambiguity will affect other modeling deliverables. I would start with the business concepts that matter most and make sure their meaning is agreed and owned.
Bring business people into modeling work.
Data modeling cannot remain mainly a technical exercise. I would involve business experts early and use views they can actually understand and validate. Their input is essential if the model is expected to reflect business reality.
Connect the modeling deliverables.
A glossary, data model, data requirements, and critical data should reinforce each other. I would check whether these deliverables are linked rather than developed as separate documents or tool entries.
Make models part of ongoing change.
A model quickly loses value when the business changes but the model does not. I would embed model maintenance into project and change processes and make ownership of updates explicit.
Go beyond measuring outputs.
This maturity review still relies mainly on the presence and maturity of modeling deliverables. I use this approach because outputs are observable and can be compared across organizations more consistently than business outcomes, which are often influenced by several capabilities at once.
However, outputs tell only part of the story. I would complement them with evidence that modeling actually improves business results, such as less rework, faster impact analysis, or greater consistency in reporting and analytics.
Use maturity results to decide what to strengthen next.
The assessment should not end with a maturity score. I would use the results to identify where the capability is stuck and which deliverable needs attention before moving further. This makes maturity measurement useful for planning rather than simply describing the current state.
