About This Episode
In episode 16 of Data and AI Heads, host Ian Allison sits down with analytics practitioner Erica Howard to unpack what it actually takes to build and execute a dynamic data strategy. Erica walks through the foundational questions every organization must answer: what data do you have today, what do you need but lack, and what might you need in the future. She explains why the right answers depend heavily on organizational age, size, acquisition history, and the complexity of existing tech stacks, and why no two data strategies should look identical.
The conversation moves into one of the most debated architectural decisions in modern data leadership: data centralization versus data mesh with data products. Erica offers a practical framework, arguing that highly regulated, recurring reporting use cases favor centralization, while dynamic, fast-changing business environments benefit from data products that can be added, removed, and adjusted with greater agility. She also introduces the concept of allowing business SMEs to prototype data products in a disciplined frontier environment before promoting them into a centralized or governed architecture.
Erica closes by connecting data strategy to talent strategy, making the case that upskilling business SMEs, embedding change management, and building flexibility into the strategy itself are just as critical as the technical architecture choices. For data and AI leaders navigating legacy systems, post-acquisition complexity, or rapid organizational growth, this episode delivers concrete, experience-grounded guidance on where to start and how to adapt.
Key Takeaways
- Every data strategy must start by answering three questions: what data do you have and want to keep, what data do you need but currently lack, and what data might you need in the future.
- Newer organizations can build data infrastructure from the ground up with greater agility, while older or acquisition-heavy organizations face a reconciliation challenge that requires rationalization of legacy systems and tech debt before strategy can scale.
- The choice between data centralization and a data mesh with data products should be driven by how the data will be used: centralization suits stable, regulatory reporting use cases, while data products are better suited to dynamic, evolving business environments.
- Over-customizing or under-customizing applications when replacing legacy systems is a root cause of structural tech debt, and organizations must be willing to challenge existing processes rather than simply lift and shift them into new tools.
- Effective data product design requires asking stakeholders not just what they need today, but also the follow-on questions they will inevitably ask once they see initial results, so that a single product can answer multiple questions and enable self-serve analytics.
- Allowing business SMEs to prototype data elements in a disciplined, isolated environment, then promoting the most valuable outputs into a governed architecture, bridges the gap between business agility and centralized data quality.
- Upskilling business SMEs through structured training programs not only accelerates data product development but also surfaces the next generation of data engineers, analysts, and BI developers from within the organization.
- A data strategy must include built-in flexibility to accommodate unforeseen events such as acquisitions, and the talent mix of the organization must be evaluated as a core component of the strategy alongside architecture and tooling decisions.
What We Cover
Frequently Asked Questions
How should an organization decide between a centralized data model and a data mesh with data products?
According to analytics practitioner Erica Howard, the decision comes down to how the data will be used. Centralization works well for stable, recurring use cases such as regulatory reporting, where data needs to be standardized and governed consistently. A data mesh with data products is better suited to dynamic environments where use cases evolve frequently, because data products can be added, adjusted, or removed more quickly than a centralized model allows. The size and maturity of the organization also affects the speed at which either approach can be implemented.
What are the core questions to ask when building a data strategy?
Erica Howard outlines three foundational questions: what data do you have today and want to keep, what data do you need but do not currently have, and what data might you anticipate needing in the future. These questions should be combined with an assessment of the technology stack, the degree of regulatory obligation, the history of acquisitions or legacy systems, and whether the existing talent mix can support the strategy. The goal is to identify immediate needs, potential needs, and future needs while ring-fencing the problem areas that must be resolved.
How do you design a data product that remains useful beyond a single use case?
Erica Howard recommends starting with the specific request but then asking the follow-on questions that users will inevitably have once they see initial results. For example, if a stakeholder wants to see customer product holdings, she would also ask whether they need leading indicators of attrition, balance trends, or engagement metrics. By expanding the requester's thinking toward broader requirements upfront, the resulting data product can answer multiple questions and support self-serve analytics rather than serving only one narrow purpose.
Why does tech debt grow so quickly in organizations that have gone through multiple acquisitions?
Erica Howard explains that organizations often make acquisition decisions focused on preserving a specific application's customer-facing functionality rather than evaluating how the new system will integrate with the existing data architecture. After several acquisitions, this can create a Gordian knot of duplicative or poorly connected systems. Manual processes get stood up to bridge functional gaps, and over time organizations end up over-customizing or under-customizing applications rather than adapting their processes to fit the tool. The reluctance to have change management conversations allows the debt to compound and becomes harder to unwind over time.
How can business SMEs be involved in data product development without creating uncontrolled technical debt?
Erica Howard describes a structured approach where selected business SMEs receive focused training, roughly one hour per week over five to eight weeks, to build their own data elements. These individuals work in a disciplined, isolated environment to prototype solutions, and the most valuable outputs are then evaluated for integration into a governed architecture through a defined development lifecycle. This approach gives the business agility and reduces dependence on the central data team for every request, while preventing the proliferation of ungoverned shadow solutions that create additional complexity for IT.
How should talent strategy factor into a data strategy?
Erica Howard argues that talent mix is a core component of any data strategy, not an afterthought. Organizations need to assess whether their current people have the skills to execute the architectural direction they are pursuing, and then define what upskilling, role transitions, or new hiring is required to close those gaps. She notes that training business SMEs can surface future data engineers, analysts, and BI developers from within the organization. The talent strategy must scale in parallel with the technology stack and data infrastructure to ensure the strategy can actually be executed.
How much flexibility should a data strategy include, and why?
Erica Howard recommends building a degree of flexibility into any data strategy because organizational circumstances can change rapidly, such as an unexpected acquisition or a shift in business priorities. A rigid strategy that cannot pivot when conditions change risks becoming obsolete or requiring a costly rebuild. She suggests treating flexibility as a deliberate design element, so that when disruptions occur, the team has a defined way to adapt the strategy rather than abandoning it entirely. The appropriate level of flexibility is situational and depends on the organization's size, pace of change, and operational environment.
About the Guest
Erica Howard
Erica Howard is a seasoned analytics practitioner with extensive experience designing and executing data strategies across complex organizational environments, including financial services and acquisition-heavy enterprises. She has built data products and analytics infrastructure at multiple organizations, guiding teams through the challenges of legacy system rationalization, data architecture modernization, and the transition to cloud-based environments. Erica is known for her ability to bridge business context and technical execution, having developed methodologies for upskilling business SMEs to participate in data product development and for designing data products that serve broad organizational use cases rather than narrow, single-purpose requests. Her expertise spans data centralization, data mesh architecture, change management, and the alignment of talent strategy with long-term data infrastructure goals.
Connect on LinkedIn →More Episodes