This article discusses evolving trends in data and application architecture maturity.
This article is the fourth one in the Data Management Maturity Trends 2025 series. In this article, I focus on the trends in the development of the information systems (data and application) architecture 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. I have published the scan results on my site, www.datacrossroads.nl, since 2019.
This article will:
• Present the definition of the information systems capability provided by multiple data management industry guidelines.
• Highlight six-year trends in the development of this capability and its components.
• Provide practical recommendations for further development of this capability.
Governance for Information Systems Architecture
Let’s first discuss the challenges organizations worldwide face with establishing governance for information systems architecture.
Definition and Positioning Challenges
I have widely addressed the challenges of defining the “information systems” (data and architecture) 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:
The TOGAF® Standard
The TOGAF® Standard, v.10, the leading industry architecture framework, groups data and application architecture into an information systems architecture. By doing this, it stresses the strong dependencies between these two architectures while still separating them due to different outcomes/deliverables.
It defines data architecture as “A description of the structure of the enterprise’s major types and sources of data, logical data assets, physical data assets, and data management resources.” According to the standard, application architecture is “a description of the structure and interaction of the applications that provide key business capabilities and manage the data assets.”
This standard provides the clearest and most distinguishing definition between these two types of data and application architecture. Data architecture describes and designs data assets, while application architecture demonstrates how these assets have been implemented In software applications. Therefore, the “information systems” architecture may be the best way to describe this dependency. However, I have rarely seen this term used in the data management community.
The rest of the data management guidelines are less precise in defining these capabilities and relationships between them.
DAMA-DMBOK 2
For unknown reasons, DAMA-DMBOK 2, separates data architecture from the capabilities that, according to the TOGAF® Standard, belong to data architecture: Data Modeling and Design, and Data Integration and Interoperability.
At the same time, DAMA-DMBOK 2 omits application architecture. It defines data architecture as “identifying data needs of the enterprise (regardless of structure), and designing and maintaining the master blueprints to meet those needs.” I think this definition violates the rules for creating definitions, and if you can use it in practice, that would be great.
EDM Counsil / Association
The EDM Council two guidelines make data and application architecture difficult to identify as one coherent capability. Three issues stand out.
DCAM® and CDMC™ define the scope differently. DCAM® treats Data Architecture as a distinct capability, while CDMC™ distributes comparable elements across Cataloging and Classification, combining metadata with platforms, applications, interfaces, and interoperability.
Application Architecture is not defined as a separate capability. Both guidelines refer to applications and interfaces, but neither defines or assesses application architecture directly.
Finally, DCAM® combines Business & Data Architecture, but does not provide an equivalent Data & Application Architecture capability. This is surprising because applications and interfaces are essential to implementing data structures and managing how data moves across systems.
The O.R.A.N.G.E. Data Management Framework
The O.R.A.N.G.E. Data Management defines the information systems architecture as a business capability for defining and describing the types, structures, and relationships between data and applications.
Data management community
The professional community has different viewpoints on defining data and application architecture. Very often, the term “data architecture” covers three types of data architecture in the TOGAF® Standard viewpoint: data, application, and technology.
For maturity measurement, this lack of consistency in defining the information systems (data and application) architecture capability creates a serious challenge. Different frameworks use different labels, boundaries, and combinations of capabilities, while some omit application architecture altogether. As a result, comparing maturity levels across organizations or frameworks becomes difficult because the same capability may be assessed through different sets of activities and deliverables. In my view, the most reliable way forward is to focus less on capability labels and more on clearly defined deliverables and their maturity. This provides a more stable basis for assessment and comparison.
Implementation Challenges
From my own experience and from reviewing industry research, I see four recurring challenges. They are closely related, but each creates a different obstacle to establishing and maintaining data and application architecture.
Fragmented data and application landscapes
The first challenge is simply knowing what already exists. I often see organizations with many applications, databases, interfaces, and locally developed solutions, but without one reliable picture of the landscape. SAP LeanIX reports the same problem: 54% of enterprise architecture teams identify a fragmented IT environment as their main challenge, while 66% give high priority to creating a reliable application inventory.
Legacy systems and accumulated technical debt
Architecture decisions are rarely made in a clean landscape. In practice, new solutions must coexist with legacy applications, outdated integrations, duplicated functionality, and historical design decisions. McKinsey links architectural technical debt directly to fragmented architectures, point-to-point integrations, data islands, inconsistent data models, and overlapping technology capabilities. These constraints make both data and application architecture harder to redesign and implement.
Complex dependencies between data and applications
This is one reason I prefer to consider data and application architecture together. Applications consume, create, transform, and exchange data, so changing one element can affect many others. In mature landscapes, these dependencies become difficult to trace. McKinsey’s research also shows that less digitally mature organizations rely much more heavily on point-to-point application integrations, increasing architectural complexity and technical debt.
Weak connection between architecture and business change
The fourth challenge is less technical. I have often seen architecture become documentation rather than an active instrument for making business and investment decisions. The SAP LeanIX findings support this concern: only 14% of respondents said enterprise architecture is perceived as a close business partner, and only 15% reported business representation on architecture review boards. For me, this is a critical implementation issue. Architecture creates value only when business priorities actively influence architectural decisions and those decisions guide organizational change.
Challenges with Delivering Business Value
The results of the LinkedIn poll in Figure 1 makes the business side of these challenges much more tangible. Practitioners seem to notice the value of data and application architecture first when it improves the consistency of data across systems and supports more trusted decisions. Faster business change comes later, which makes sense: speed is usually the result of many architectural and organizational improvements working together.
Figure 1: The business benefits of data and application architecture.
For me, this result reflects where architecture problems become visible first. Fragmented application landscapes create inconsistencies in how the same data is defined, stored, exchanged, and used. Once these inconsistencies accumulate, trust in the data suffers as well. The poll therefore suggests that practitioners primarily recognize the value of data and application architecture through its ability to reduce fragmentation and create coherence across systems.
The lower position of faster business change is equally interesting. It may indicate that organizations still experience architecture mainly as a way to stabilize and simplify the existing landscape, rather than as an enabler of transformation. It may also reflect the fact that business agility depends on many capabilities beyond architecture. For maturity measurement, this distinction matters: some outcomes can be linked to architecture much more directly than others.
Maturity Measurement Challenges
When I assess the maturity of data and application architecture, I would ideally measure the outcomes discussed above: greater consistency across systems, more trusted data, and an architecture that supports business change.
In practice, however, these outcomes are difficult to attribute to architecture alone. Consistency and trust also depend on data quality, governance, integration, application development, and other capabilities. The speed of business change depends on an even wider set of organizational factors.
For this reason, this review still relies mainly on architecture outputs and deliverables. They provide tangible evidence that can be assessed more consistently across organizations and compared over several years.
I see this as a practical measurement approach, not as an assumption that architecture deliverables equal success. Their existence shows that the capability is being established. Their quality, use, and influence on implementation decisions show whether the architecture is actually working.
This distinction is important when interpreting the trends that follow. They primarily show how far organizations have progressed in establishing and operationalizing data and application architecture, rather than directly measuring the business value it creates.
Trends in Information Systems Architecture Development
General Trends
From 2019 to 2025, data and application architecture shows a clear overall improvement. The progress becomes especially visible in the most recent years.
What matters to me is not only that maturity is increasing, but how the capability itself seems to be changing. Architecture is gradually moving away from isolated or reactive work toward a more deliberate approach that connects applications, data structures, and dependencies across the organization.
The development is still uneven, which suggests that many organizations are somewhere between defining architecture and embedding it into regular investment, design, and change decisions. Figure 2 reflects this broader shift.
Figure 2: Trends in data and application architecture development.
Overall, the trend is positive. Still, the results also show a considerable gap between having architecture under development and making it consistently operational.
Trends in Core Data and Application Architecture Outputs/Indicators
The overall maturity score does not show which parts of the capability are moving forward. For this review, I use four indicators because together they show whether data and application architecture is moving beyond design into coordinated implementation.
Optimized reporting practices indicate whether underlying data structures and application flows support consistent information delivery. Optimized application architecture shows whether the application landscape is being deliberately structured rather than allowed to evolve independently. Master and reference data management provides evidence that shared data is controlled across systems, which is essential for architectural consistency. Finally, the enterprise architecture function shows whether these separate elements are coordinated within a broader decision-making framework.
Taken together, these indicators provide a practical view of whether data and application architecture is becoming operational, interconnected, and able to support business change.
Optimized Reporting Practices
The development of reporting practices is encouraging. As shown in Figure 3, reporting has gradually become more structured over the six-year period, although the movement is not completely linear.
Figure 3: Trends in optimizing reporting practices.
I see reporting as an important indicator because problems in the underlying architecture often surface here first. Conflicting figures, duplicated calculations, and repeated reconciliation rarely start in a report itself. They often originate in fragmented data sources, applications, and integrations. The gradual improvement therefore suggests that organizations are gaining more control over the architecture supporting their reporting.
Optimized Application Architecture
Application architecture shows a stronger overall development, particularly in the later years of the period covered by Figure 4.
Figure 4: Trends in optimizing application architecture.
This development matters because applications are where many architectural decisions eventually become tangible. Over time, organizations seem to be moving toward more deliberate management of their application landscapes rather than allowing them to grow mainly through individual projects and local requirements. To me, this is an important sign that architecture is playing a more active role in managing complexity and dependencies.
Master and Reference Data Management
The development of master and reference data management in Figure 5 is slower and noticeably less consistent.
Figure 5: Trends in developing master and reference data management.
This pattern is not surprising. Master and reference data cross application, process, and organizational boundaries. Progress therefore depends on much more than designing a technical solution. Organizations also need agreement about shared data, responsibilities, and its implementation across different systems. The trend highlights how difficult it remains to create consistency when the same data is used and maintained across a complex application landscape.
Enterprise Architecture Function
The enterprise architecture function has also strengthened over the period, with the development becoming more visible in recent years, as illustrated in Figure 6.
Figure 6: Trends in establishing the enterprise architecture function.
I consider this particularly relevant to the development of data and application architecture. Individual architecture practices can improve on their own, but somebody still needs to connect decisions across business areas, applications, data, and technology. The trend suggests that more organizations are building this coordinating capability. That creates better conditions for moving from separate architectural initiatives toward a more coherent enterprise-wide approach.
What the Maturity Results Add to the Poll Results
When I compare the maturity results in Figures 2–6 with the LinkedIn poll in Figure 1, I see a consistent picture.
The poll points to consistent data across systems as the most visible sign that data and application architecture is working. The maturity results show why this remains difficult. Application architecture is becoming more structured, but master and reference data management develops more slowly, while reporting and enterprise architecture are still maturing as coordinating practices.
The second poll outcome, trusted data for decisions, depends on the same foundations. Trust is difficult to achieve when shared data is inconsistent across applications or when reporting compensates for architectural weaknesses downstream.
The position of faster business change also makes sense in this context. It is a broader outcome that depends on several architectural elements working together. The maturity results suggest that many organizations are improving individual components, but have not yet reached the point where these components consistently operate as one architecture capability.
For me, this is the main conclusion: the challenge is no longer simply whether data and application architecture exists. The harder task is creating coherence between its different elements and turning that coherence into business value.
Recommendations
The results point to several areas that may deserve more attention as organizations continue developing data and application architecture.
Greater coherence between data and applications
Organizations may benefit from treating data and application architecture as closely connected rather than as separate technical disciplines. Application decisions shape how data is stored, exchanged, and used, while data requirements influence application design. Stronger coordination between the two can reduce fragmentation and conflicting design choices.
More attention to shared data across systems
The slower development of master and reference data management is especially important. Organizations with complex application landscapes may need to place more emphasis on the shared data that crosses system boundaries. This is often where inconsistencies become visible and where architectural alignment can create the clearest practical benefit.
A stronger coordinating role for enterprise architecture
The improving enterprise architecture trend is encouraging. Its value becomes greater when the function helps connect business priorities, application decisions, and data structures rather than concentrating mainly on documentation. This broader coordination can prevent local solutions from creating new enterprise-wide dependencies.
Using reporting as an architectural signal
Reporting problems can reveal weaknesses much earlier than architecture reviews do. Repeated reconciliation, duplicated calculations, and conflicting figures may indicate deeper inconsistencies in applications, interfaces, or shared data. Organizations can therefore use reporting issues as evidence of where architectural attention may be needed.
A gradual shift from outputs to outcomes
The current maturity assessment still relies mainly on outputs because they provide comparable evidence across organizations and years. Over time, organizations may benefit from complementing these indicators with outcome measures such as consistency across systems, trusted information, and the ease of implementing change.
This would make maturity assessment more useful not only for showing what has been established, but also for demonstrating whether architecture is producing the intended business effect.
