Data Maturity Takes Time: Don't Focus on the Summit to Scale the Mountain

In 2025, every company has had, in a sense, to behave like a technology company to stay competitive, but that’s not how they started. If they had, they wouldn’t need consultants to bring their expertise. In consulting, one of the terms we use to talk about clients’ data journeys – a term that seems simple but is difficult (for reasons we’ll look at in this article): “Meet the client where they are.”

‍

What that means, in essence, is that if an organization has siloed, unstandardized data, then they shouldn’t begin their data maturity journey by adopting machine learning solutions right off the bat. Building up infrastructure and data models will eventually support augmented analytics, but you must look at where you are and start there. Any consultancy worth their salt will guide you from that point, not suggest potentially unrealistic and resource intensive solutions as soon as they walk through the door.

In the world of data, there are certain stages of being “not ready” that companies can’t skip on the road to an optimized state.

In this blog, I’m going to take you through my experience of “meeting the client where they are” so that, as a leader at your company, you can use these techniques to meet your own teams where they are while considering your organization’s status on their data maturity journey and how to move forward. You’ll learn to guide both your employees and your company practically and effectively to your end goal. The most important takeaway, if nothing else, is that you must recognize you cannot simply skip to the end!

The journey is the point, and it’s our focal point in this article.

What you’ll learn in this article

•  The main stages of architectural maturity—Business Silos, Standardized Technology, Optimized Core, and Business Componentization—and how to grow through each stage effectively to reach the holy grail: Digital Ecosystem.
•  Strategies for managing resistance to new tools, driving adoption, and smoothing the transitions among data maturity phases.
• What business value and operational efficiency look like at every stage ofyour data maturity journey.
• Change management strategies to help you move along the curve.

Phased thinking: Stages on your data architecture journey

I’ll say it again for those in the back: Most companies aren’t tech companies.

‍

As I was reading Jeanne W. Ross’ article on data architecture maturity, I began to realize that I had been approaching my clients as if theywere tech companies – even though they were manufacturers, retailers, and so on – because we were working with technical solutions. 99% of my client organizations started before “Big Data” had been coined and once I realized that they were dealing with decades of past technology that now had to be rationalized and consolidated I was better able to “meet them where they were”. By using the stages Ross identifies, I was able to categorize the stage my teams were in and coach them accordingly.

‍

 Let’s look at those stages and how they apply from a company-like-yours perspective.

‍

1.  Business Silos: Your starting point

What is it?

If your organization still has business silos that use different applications, tools, and data sources, you’re still at the beginning of your journey. If you continue to allow the business silos to exist – even as you evolve more complicated solutions – you’ll be in for a wake-up call later when a CIO decides it’s time to rationalize and consolidate the tooling. Consolidate your data in anticipation of this eventuality.

What challenges will you face at this stage?

In my experience, consolidation of tooling with leadership support is usually the first step of a successful digital transformation. The organization decides on one data warehouse, one analytics platform, one ERP – and then commits to it. The biggest source of failure is waffling.

How do you successfully grow out of this phase?

The goal is to build a scalable and flexible data platform that (1)offers configurations to meet each business unit’s requirements and (2) serves as the foundation for an interoperable set of services. The idea is to start with configurable, service-oriented enterprise systems and wrap legacy tools in APIs instead of replacing them all at once.

In a nutshell, you’re digitizing your backend while creating middleware that connects cleanly to your new frontend platforms. This approach supports individual business unit needs while enabling shared capabilities—like unified product search or a customer 360 view. The result is a seamless experience across your data applications and a practical path to modernization without blowing everything up at once.

2. Standardized Technology: Letting go of inefficient tools and managing change

What is it?

The second phase of architectural maturity, Standardized Technology, is conceptually the easiest, but one of the hardest to implement because of the change management aspect.

‍

You know when you’ve reached the Standardized Technology phase when all your business units are using the same data warehousing, frontend platform, service desk, messaging service, etc. In this phase, no BU should be using Tableau while the rest use are using Qlik.

What challenges will you face?

People resist change and will, in some cases, take up the cause of the very niche messaging app their business group of 15 people uses simply because they don’t want to learn how to use something new. It helps to have support from the top, early adopters, and user champions. And you must be ruthless in finding and uprooting shadow IT.

How do you successfully grow out of this phase?

Though the statistics vary, Forrester posits that 84% of digital transformations fail due to the failed adoption of technology. So you’ll need to lay out your rationale for the new technologies or ways of working succinctly and stick to the plan despite resistance. Communicate consistently with your teams. My colleague, Michael McAlpine, has written about strategies for doing so. (You can download our comprehensive change management checklist for strategies to overcome resistance at this stage.) It’s important to let people express their concerns and to give feedback, but once the decision is officially made, brook no argument.

3. Optimized Core: Start to see ROI

What is it?

Once an organization gets to the Optimized Core phase, usually multiple years (sometimes 3, sometimes 5) into their journey, that’s where things start humming along nicely and you begin to see the value return from IT initiatives like these. You understand the processes and tools you’re expected to use, you’re experienced in working with them, and everyone is doing things the same way. It levels the playing field and simplifies day-to-day work.

What challenges will I face?

The keys to success here are communication, ownership,and a centralized IT team. You should know if a request on your backlog for one business group is similar to another, as well as the common workflows across business groups. Leverage the apps and dashboards you create accordingly. Don’t create specialized apps that can only be used by one team – consolidate similar business requirements to create an app that can be used by several teams. The biggest challenge here is maintaining organization and communication networks to enable this.

How do I successfully grow out of this phase?

This is certainly not a bad place to be, and it is a comfortable one. If you want to stay competitive, the next phase of Business Modularity or Business Componentization will be a game-changer. Analyzing, documenting, and researching what you’re doing now takes time, effort, comfort with tedium, and an eye for small details. But the payoff is worth it, though the journey can take years. The result of that work will set you up for Business Componentization. That’s when what we build for one business group can be used for another. I once saw an organization retire hundreds of individual reports across two different business groups in favor of one data app. Those are the sorts of major gains we’re talking about in this stage.

‍

4. Business Componentization: Interchangeability and interoperability

What is it?

This phase is where you need to ensure your IT structure is carefully aligned with respective business lines, as well as the corresponding markets. It's an adage, but aligning IT with the business increases the likelihood that IT decisions will result in measurable business value. You can further drive alignment between tech and business by reducing the degrees of separation in your reporting structure: Can your developers, reporting teams, and data engineers all lead up to the CIO (who is in turn lockstep with the CEO)? IT projects and initiatives should correspond to a well-defined and clearly sponsored business problem, without which your run the risk of creating separation between IT and business.

What challenges will I face?

If your current reporting structure means that different IT initiatives are spread across different verticals (for example, Marketing, Finance, and HR), you may also need to structure your departments to work better together. Companies often end up in this position when they come from a tradition of considering IT a cost center for different departments and have decentralized IT teams catering to those departments’ needs. In other words, you’re not just consolidating platforms and tools: You’re consolidating your people into org structures that make the work flow more easily. Instead of throwing solutions “over the wall” and waiting for a business unit to approve days, weeks, or even months later, streamlined org structures make light(er) work and, in turn, improve processes across the board.

‍

How do I successfully grow out of this phase?

To puzzle out how to graduate from Business Componentization to the next phase, Digital Ecosystem, let’s look to the sage advice of Gartner, which breaks down the idea of a “digital business”. At this point, you are a digital business – a unified entity with smooth technological operations. According to Gartner, “digital business looks less like fixed systems and more like platforms.” That’s what we’re aiming for in this phase to facilitate consistent growth toward data maturity – essentially, you’re in a position to deliver data products that can support your entire workforce.

In summary: If you’ve consolidated your platforms, your IT is centralized, and you’re in lockstep with the business side, you are a digital business.  

Digital business layers: A path to understanding “Business Componentization”

Now, as a digital business, think about your “Digital Use Cases” as natural extensions of system consolidation. The fact that IT is solving validated and sponsored business problems creates the link between IT and business units naturally. But I want to look at the people aspect in this part of the article, rather than the technology.

‍

‍So, what does the Digital Use Case layer look like in terms of people and organizational structure?

In terms of use case development and oversight, I’ve always favored the method where the product owner and/or the manager of any digital team comes from the business side. They should be able to build relationships with and deeply understand the business users and their needs. How they prioritize requests that come in reflects that knowledge, so we know we’re building the right things in the right order. Because IT is centralized, we’re all speaking to each other and know what other teams are working on – and we have visibility into those items in planning and review sessions so we’re not duplicating work and know what solutions are available.

Once you’ve reached this point, you’re most likely ready to graduate to Digital Ecosystem.

5. Digital Ecosystem: Apply learnings, commit, and continue

What is it?

When we think about the next phase, Digital Ecosystem, from a data perspective, we basically want to apply all the learnings from thefirst four phases and digitize and harvest data from everywhere imaginable. If you’re a manufacturing plant, do your machines have sensors telling you when parts need to be replaced? Maintenance schedules? How can you implement that data into a centralized dashboard, and what analysis can you do on it? Can you integrate augmented elements when you’re ready to go beyond BI?

In the restaurant industry, organizations are using the Internet of Things to optimize their operations. Texas Roadhouse utilizes a Digital Ecosystem to manage fridge temperatures, food waste, and customer offers on and offline. What are the actual results of committing to being “digital to the core”? For Texas Roadhouse, a 32% increase in operational efficiency in 2024.

What challenges will you face?

When we talk about data and the Digital Ecosystem, things can seem futuristic and unattainable, like when we consider the use case of Digital Twins for wind turbines. How can an organization be ready to implement something so complex? The answer is to work through the stages of architectural maturity, commit to each stage, embrace the challenges, and continue the journey.

You can’t take a helicopter to the top of Mount Everest.

Remember: You can’t reach the next phase without completing the prior and it is truly one of those moments where you need to trust the process. You might think that instead of climbing Mount Everest, you could take a helicopter to the top instead, but you can’t. A helicopter can fly at that high of an altitude, but there’s no area flat enough to land. Without each stage of the architectural maturity model, you will not have a sturdy and level enough base on which to build the next stage.

‍

Get started with DI Squared

 Consider us your mountain guides. We've helped hundreds of organizations -- from the smallest pickle company to the biggest retailers -- to reach new heights on their data journey. Let's start yours together.

‍

‍