Masterclass Mode Engaged

Martyn Rhisiart Jones

Madrid, Sunday 1st February 2026

PART I

PART II

Happy Sunday to one and all. As many of you will know, I have been intimately involved in designing, building, and delivering data warehousing and advanced analytics initiatives for more than 35 years.

Today, I will take a deep dive into requirements gathering for a new iteration of an enterprise data warehouse and a new data mart.

Establishing a case for a new data warehouse iteration is part of the requirements-gathering phase of a project. This must always be at the forefront of the exercise and a continuous question we must ask ourselves. We must always consider the answer to the question “To what ends?”

First, before diving into the core aspects of the iteration, we will examine the legitimate drivers and objectives for data warehouse initiatives. The prerequisite skills, knowledge, and experience needed to carry out this activity successfully, and, after that, we will look at the preparation required to align the personal, business, and technological effectiveness and success of the initiative.

Drivers and Objectives

Key drivers for justifying a new iteration of the data warehouse and the introduction of a new data mart are not to be confused with scalability, data quality and technology integration. Key drivers might include business profitability, performance, risk reduction and strategic opportunities and challenges.

True justification for investing in a new iteration of a data warehouse (DW) or data mart must tie directly to business outcomes, revenue impact, competitive advantage, risk reduction, and strategic goals, not just technical upgrades like “better scalability” or “cloud elasticity” in isolation.

Technical enablers matter, but they only justify the effort when framed as means to business ends.  

Examples of primary business drivers for DW/Data Mart iteration:

1. Faster, more accurate decision-making to pre-empt and capture revenue opportunities
2. Improved customer experience, products and services, and retention/personalisation
3. Cost reduction and efficiency gains that positively boost the bottom line
4. Competitive differentiation and market responsiveness
5. Risk mitigation and regulatory/compliance imperatives
6. Enabling new revenue streams or business models
7. Higher organisational productivity and cross-functional alignment

💡 NB Being able to elucidate these items does not mean that you have the knowledge, skills and capacity to produce these outcomes. So, beware of hubris! Especially your own.

In short, the effort needed to build the DW is justified only when leadership can map it to specific benefits, KPIs and OKRs. For example, X revenue growth improvements, Y reductions in operating costs, Z faster customer acquisition with lower acquisition and retention costs, or avoided millions of EUR/USD in risk exposure.

Pure technology refresh rarely gets funded and business-aligned cases with clear ROI (which speculatively speaking, often can be increased by two to three times over two or more years).

If your organisation is promoting a new iteration, start with: “What monetary or strategic outcomes are we missing today because of our current DW?” That flips the conversation from features to value. What specific business pain are you seeing that technology alone can’t fix, and what is putting important revenue streams at risk?

Prerequisites

Understand the language and culture of the business users

Understanding the language (terminology, metrics, KPIs, business slang) and culture (priorities, decision-making styles, workflows, pain points, and attitudes toward data) of business users is essential in data warehousing—not a nice-to-have, but a core success factor. Here’s why, grounded in proven methodologies like Kimball’s dimensional modelling (which explicitly emphasises this) and broader industry experience:

1. The data warehouse must solve real business problems, not just store data

• Business users don’t think in terms of tables, joins, or schemas; they think in terms of lives saved, lives improved, faster discovery, customer lifetime value, churn rate by segment, same-store sales growth, or inventory turnover.
• If architects don’t speak this language, they build models around technical convenience (e.g., source-system structures) instead of business processes. Result: queries are slow, unintuitive, or wrong, leading to low adoption and failed projects.

2. Dimensional modelling is built around business reality and lenses

• The dimensional modelling method starts with business events/processes (e.g., sales orders, claims processing). It uses facts (measures) and dimensions (context, such as Client, Service, Time) that mirror how users describe and analyse their world.
• Conformed dimensions ensure consistent definitions (e.g., everyone means the same thing by “active client”). Without a deep understanding of user language and priorities, you end up with inconsistent or mismatched dimensions, risking that “the single version of the truth” breaks down. NB not that a single version of the truth is always needed or welcome.

3. Requirements gathering fails without cultural insight

• Users often describe needs vaguely or in domain-specific jargon (“We need to see ‘promo lift by region”).
• Understanding culture reveals hidden requirements (e.g., finance cares about audit trails; marketing wants fast ad-hoc slicing; operations needs near-real-time). It uncovers which metrics truly drive decisions versus what sounds good in meetings.
• Ignoring this leads to over-engineering (building unused features) or under-delivering (missing critical KPIs and promoting dead-end analytics).

4. Adoption and self-service success depend on it

• Modern DWs aim for self-service BI (Tableau, Power BI, etc.). Users adopt tools only when they feel intuitive and speak their language.
• If labels, hierarchies, or calculations don’t match how users think (“Why is ‘Net Sales’ including returns here but excluding them in Excel?”). They revert to shadow IT, spreadsheets, or distrust the warehouse entirely.

5. Avoids costly rework and project failure

• Many DW failures stem from misalignment: technical teams deliver “perfect” data, but users say, “This doesn’t help me.”
• Deep business immersion during requirements, modelling, and iteration reduces scope creep, rework, and the infamous “90% done, 0% used” syndrome.

Simply stated, a data warehouse succeeds when it becomes the trusted, natural extension of how the business operates and thinks, not when it’s a technically elegant silo. Speaking the users’ language and respecting their culture bridges the IT-business gap, ensures relevance, drives ROI (faster insights drive potentially better decisions, which in turn may result in positive revenue and cost-reduction outcomes), and turns data from a cost centre into a strategic asset.

Without it, even the fastest, cheapest, most scalable warehouse collects dust.

Understand the language of the business.

Understanding the language of the business is essential in data warehousing:

1. Aligns the DW with actual business needs
   The warehouse must answer questions in the terms users naturally use (e.g., “churn rate”, “promo lift”, “net contribution margin”), not IT jargon.
2. Enables correct dimensional modelling
   Facts, grains, dimensions, and conformed attributes only make sense when built from the business’s real-world processes and definitions.
3. Creates a single, trusted version of the truth
   Prevents conflicting metric definitions across departments (e.g., what “active customer” really means), eliminating reporting wars and distrust.
4. Drives high adoption and effective self-service BI
   Users adopt tools (Tableau, Power BI, etc.) only when labels, hierarchies, calculations, and filters align with how they already think and speak.
5. Reduces costly rework and project failure
   Deep immersion in business language during requirements gathering uncovers true priorities, rules, and hidden needs, avoiding “90% built, 0% used” outcomes.

A data warehouse succeeds only when it speaks the same language as the business; otherwise, it delivers technically correct but practically useless or mistrusted data.

ℹ️ Why IT Must Speak the Language of Business

Understand the business

Understanding the business (its goals, processes, priorities, metrics, challenges, and decision-making needs) is fundamental to building a successful data warehouse (DW). A DW isn’t just a technical storage system; it’s a strategic tool that can deliver actionable insights to drive real business value, including more informed decisions, potential revenue growth, cost savings, and a competitive advantage in legal matters.

Key reasons why it’s important:

1. The DW must solve actual business problems
   Without deep business knowledge, architects build systems optimised for technical efficiency (e.g., mirroring source systems) rather than business value. This results in data that’s accurate on paper but useless for answering critical questions like “Why is customer retention dropping in segment X?” or “What’s the true ROI of our marketing campaigns?”
2. Business-driven design (Especially in dimensional modelling)
   The most widely adopted approach (dimensional modelling) explicitly starts with business requirements and processes. It involves:
   • Gathering business needs first.
   • Defining facts and dimensions based on how the business views events and context.
   • Ensuring models reflect real-world operations (e.g., grain at the order-line level if that’s how sales analyses performance).
     Ignoring business understanding leads to mismatched models, inconsistent metrics, and failure to deliver a “single version of the truth.”
3. Ensures consistency and eliminates “Reporting Conflicts”
   Departments often define terms differently (e.g., “revenue” including/excluding discounts, or “active user” defined by the team). Understanding the business uncovers and standardises these definitions, preventing conflicting reports, data distrust, and endless debates.
4. Boosts adoption and self-service analytics
   Business users adopt BI tools (Power BI, Tableau, etc.) only when the DW “speaks their language”, with intuitive labels, hierarchies, and calculations that match their daily thinking. Without business insight, users revert to Excel, shadow IT, or ignore the data warehouse entirely, wasting the investment.
5. Maximises ROI and avoids failure
   DW projects succeed when they tie directly to business outcomes (e.g., faster insights lead to quicker market response and potentially higher revenue). Business understanding during requirements gathering reveals true priorities, uncovers hidden rules, and prevents expensive rework or “technically perfect but unused” systems.

In short, a data warehouse thrives when it’s built for the business, not just for data. Deep business understanding bridges the IT-business divide, ensures relevance, builds trust, and turns data into a genuine driver of performance and growth. Without it, even the most advanced DW becomes an expensive, underutilised asset.

Appropriate and realistic management

Having appropriate and realistic management means strong, pragmatic leadership, transparent governance, well-defined scope, stakeholder alignment, and grounded expectations, which is essential for data warehousing (DW) projects to succeed rather than join the high failure statistics (often 50-80% of DW/BI initiatives fall short, get abandoned, or deliver limited value).

Why it’s critically important:

1. Prevents unrealistic expectations from derailing the project
   DW implementations are complex, multi-year efforts involving data integration, quality issues, ETL challenges, and cultural change. Overpromising quick wins, “single version of the truth” overnight, or massive ROI without phased delivery leads to disappointment, loss of sponsorship, and premature cancellation. Realistic management sets achievable milestones (e.g., start with two to three business processes), communicates trade-offs, and builds credibility through incremental value.
2. Controls scope creep and resource overruns
   Without firm, appropriate management, projects balloon from “let’s include every source” or endless “nice-to-have” requirements. This leads to budget overruns, missed deadlines, and team exhaustion. Strong management enforces prioritisation (tied to business value), uses phased/iterative approaches (e.g., dimensional bus architecture incrementally), and applies governance to say “no” when needed, keeping costs predictable and ROI positive.
3. Ensures alignment with business goals and sustained support
   DW succeeds only when it delivers measurable business outcomes (e.g., faster insights leading to revenue uplift and cost reduction). Effective management involves executives, business leads, and IT in governance (e.g., steering committees and clear data steward roles). It ties every phase to strategic priorities, secures ongoing sponsorship, and prevents the project from becoming an “IT-only” exercise that loses funding when results lag.
4. Mitigates standard failure modes
   Studies and industry reports highlight that many DW failures stem from:
   • Lack of clear objectives or weak sponsorship.
   • Inadequate change management and user adoption.
   • Poor data quality/governance without oversight.
   • Treating it as a pure tech project instead of a business transformation. Realistic management addresses these head-on with risk assessment, stakeholder communication, training, and continuous feedback loops.
5. Maximises long-term ROI and adoption
   A well-managed DW becomes a trusted asset for self-service BI, analytics, and AI. Unrealistic or hands-off management leads to underused systems, shadow IT, or abandonment. Appropriate oversight ensures ongoing tuning, data quality monitoring, scalability planning, and evolution with business needs, delivering sustained value over the years.

In short, data warehousing is as much a change and expectations management challenge as a technical one. Appropriate and realistic management turns high-risk, high-reward initiatives into reliable strategic enablers, avoiding the classic pitfalls of sunk costs, distrust, and “technically perfect but unused” warehouses. Without it, even the best architecture fails to deliver business impact.

Knowledgeable, experienced and aligned team members

Having knowledgeable, experienced, and aligned team members is one of the most critical success factors in data warehousing (DW) projects. These initiatives are complex, high-risk, multi-disciplinary endeavours involving data integration, modelling, quality, governance, and business alignment—where even minor missteps lead to delays, overruns, or outright failure (with historical failure rates often cited at 50-80% for DW/BI projects).

Why it’s so important:

1. Charts complexity and avoids common pitfalls
   DW projects involve intricate challenges: poor source data quality, mismatched schemas, performance bottlenecks, scope creep, and integration across disparate systems.
   Knowledgeable and experienced members (e.g., seasoned data architects, ETL experts, modellers with Martin/Jones/Kimball/Inmon exposure) recognise patterns from past projects, anticipate issues early (like data quality traps or scalability limits), and apply proven best practices, preventing rework that can double costs or timelines.
2. Delivers high-quality, business-relevant outcomes
   Experience ensures sound decisions on grain, conformed dimensions, handling of slowly changing dimensions, and prioritisation of key business processes.
   Without it, teams build technically “correct” but practically useless warehouses (e.g., models that don’t support critical KPIs or force users into convoluted queries). Knowledgeable teams bridge technical excellence with business value, turning data into actionable insights.
3. Ensures alignment across diverse stakeholders
   Aligned team members share a common vision, clear roles, and a mutual understanding of priorities, preventing silos between IT, business analysts, data engineers, and executives.
   Misalignment causes “reporting wars,” conflicting requirements, duplicated efforts, or projects drifting from strategic goals. Aligned teams foster collaboration, effective communication, and quick resolution of conflicts, keeping the project focused on delivering measurable ROI (e.g., faster decisions, cost savings, revenue uplift).
4. Boosts efficiency, adoption, and long-term success
   Experienced members accelerate delivery through efficient design, automation, and risk management, often achieving more with fewer resources.
   Alignment promotes high motivation, reduces turnover, and supports self-service BI adoption (users trust and use the DW when it meets their needs). This creates sustained value: the warehouse evolves with the business instead of becoming legacy debt.
5. Mitigates high failure risks
   Many DW failures stem from inadequate skills/knowledge (e.g., a lack of expertise that leads to poor data modelling or integration), low team motivation/participation, or misalignment (e.g., poor communication or competing interests).
   A strong, cohesive team directly counters these. Studies and practitioner reports emphasise that access to skilled, experienced professionals and cross-functional alignment are key to overcoming technical, organisational, and leadership hurdles.

In short, data warehousing isn’t just a tech project; it’s primarily a business transformation that requires deep expertise to manage complexity, experience to avoid costly mistakes, and alignment to ensure everyone pulls in the same direction toward real value. Without knowledgeable, experienced, and aligned team members, even the best tools and plans often fail to deliver. With them, projects become reliable drivers of competitive advantage.

Requirements gathering artefacts

Iteration-linked artefacts

Building a new data warehouse iteration (e.g., expanding an existing enterprise data warehouse with new subject areas, sources, or capabilities in an iterative/agile manner) or a new data mart (a focused subset for a specific business area, often dimensional) requires a core set of artefacts, project items, and documents. These ensure alignment, traceability, quality, governance, and successful delivery.

Modern approaches favour iterative/incremental development (e.g., agile/Scrum adapted for data, or Disciplined Agile DW/BI), so artefacts are lightweight where possible but still comprehensive for enterprise contexts. The list below draws from standard best practices (Kimball dimensional, Inmon normalised/hybrid, Data Vault influences, and agile/iterative/SAFe DW lifecycles).

Core project management and governance artefacts (Common to both DW iteration and new data mart). These establish scope, alignment, and control:

• Project Charter / Initiation Document – High-level objectives, business case, success criteria, stakeholders, scope boundaries, assumptions, and high-level timeline/budget.
• Business Requirements Document (BRD) or User Stories / Use Case Backlog – Prioritised business needs, key questions/metrics/KPIs to answer, reporting/analytics use cases.
• Project Plan / Roadmap / Release Plan – Phases/sprints, milestones, dependencies, resources, risks/issues log.
• Risk Register & Issue Log – Identified risks (e.g., data quality, source system changes), mitigation plans.
• Change Management / Governance Log – Tracks scope changes and approvals.
• Stakeholder Register & Communication Plan – Who needs what updates and how.

Data-Focused Artefacts & Documents

These form the technical backbone:

1. Data Analysis
   • Business and technical catalogue of data items (fact and dimension attributes) required as part of the data warehouse/data mart iteration.
   • Draft business term caralogue covering data items, measures and indicators for the iteration.
2. Source System Analysis & Inventory
   • List of source systems/databases/files/APIs.
   • Data profiling reports (volume, quality, cardinality, nulls, duplicates).
   • Data lineage/source-to-target traceability matrix (critical for audits/compliance).
3. Requirements Artefacts
   • Business process models or subject area descriptions.
   • Focused business term glossary linked to the corporate business term glossary
   • Conceptual data schema / business data model
   • Key performance indicators (KPIs, OKRs), measures, dimensions, hierarchies.
   • Report/dashboard mock-ups or wireframes (to drive requirements).
4. Data Architecture & Modelling Deliverables
   • High-level architecture diagram (layers: a) staging/raw b) relational c) integration/enterprise d) presentation/semantic/data marts).
   • Conceptual / Logical Data Model (ER diagram for normalised/Inmon style or high-level entities).
   • Dimensional Model ✨ How To: Dimensional Modelling
     • Fact tables (grain/granularity defined).
     • Dimension tables (including conformed/shared dimensions).
     • Star schema/snowflake schema diagrams.
   • Conformed Dimensions Matrix (bus matrix) – Shows which facts share dimensions (essential for scalability/integration).
   • Physical Data Model / DDL scripts (tables, indexes, partitions, views). Sparx EA, ERWin, PowerDesigner, etc.
5. ETL / Data Integration Artefacts
   • Source-to-target mapping document (detailed field-level mappings, transformations, business rules). ✨ How To: Source-to-target mapping
   • ETL design specifications/patterns (incremental/full loads, CDC, error handling).
   • Data flow diagrams (high-level and detailed).
   • Staging area design (raw/persistent staging if using Data Vault or modern ETL/ELT).
6. Data Quality & Governance Artefacts
   • Data quality rules/profiling expectations.
   • Data dictionary/business glossary (definitions, owners, stewards).
   • Security & access model (roles, row-level security, masking).
   • Metadata repository entries (if using a tool).
7. Testing & Validation Deliverables
   • Test plan/strategy (unit, integration, UAT, regression).
   • Test cases/scripts (data completeness, transformation accuracy, reconciliation counts).
   • Reconciliation/validation reports (source vs. target row counts, sums, sample checks).
8. Deployment & Operations Artefacts
   • Deployment/runbook (migration scripts, rollback plan).
   • Monitoring & alerting plan (data freshness, load success, anomalies).
   • Operations guide/support handover document.
9. End-User & Adoption Deliverables
   • User guide/training materials.
   • Semantic layer definitions (if using tools like Power BI semantic models, dbt models).
   • Sample reports/dashboards or self-service setup guide.

Roles and Responsibilities in Requirements Gathering and Management

Data warehouse iterations or new data marts form the foundation of successful projects. In analytical environments like these, requirements focus on business questions, KPIs, data grains, dimensions, hierarchies, and analytical processes rather than transactional workflows. This phase must balance business priorities with technical feasibility, data availability, and long-term scalability—especially in hybrid, agile, or modern lakehouse setups standard in 2026.

What follows is a clear breakdown of the key roles, their primary responsibilities, and how they interact during requirements gathering and ongoing management.

1. Business Sponsor / Executive Sponsor

Owns the overall business value and strategic alignment.

Defines high-level objectives: What key decisions or outcomes will the DW iteration or data mart enable? (e.g., improved revenue forecasting, churn reduction, compliance reporting).

Approves scope, priorities, significant changes, and trade-offs (e.g., data freshness vs. quality).

Provides funding, resources, and visibility to prevent drift.

Ensures ongoing commitment, many projects falter when sponsors disengage after kick-off.

2. Business Stakeholders / Subject Matter Experts (SMEs)

Represent the end-users and domain experts (e.g., finance analysts, marketing leads, operations managers).

Define detailed business needs: analytical questions, KPIs/OKRs/measures, dimensions, hierarchies, reporting use cases, and exceptions (e.g., “exclude test accounts,” “handle late-arriving data”).

Participate in workshops, interviews, and validation sessions.

Review and approve mock-ups, prototypes, and deliverables to ensure they accurately reflect real-world processes.

Provide ongoing feedback in iterative cycles.

3. Product Owner (or Business Product Owner)

Maintains and prioritises the requirements backlog (e.g., epics, user stories: “As a sales analyst, I need conformed customer and product dimensions to analyse LTV by cohort”).

Drives prioritisation based on business value, ROI, dependencies, and feasibility.

Makes decisions on scope, timing, and acceptance criteria.

Represents business interests in sprint planning, reviews, and demos.

In modern DW projects, it often owns semantic layer definitions (e.g., in tools such as dbt and Power BI).

4. Business Analyst (BA) / Data Analyst (Bridge Role)

Leads lead generation by facilitating workshops, interviews, and brainstorming sessions.

Documents and refines requirements into clear, testable artefacts (e.g., user stories, BRD, KPI definitions, source-to-target gaps).

Performs initial data profiling to ground discussions in reality (e.g., null rates, duplicates).

Ensures traceability: Links every requirement to business need, source, transformation, and owner.

Bridges business and technical teams to avoid ambiguity.

5. Data Warehouse / Data Architect

An expert, not a fan!

Assesses feasibility and architectural fit during requirements sessions.

Advises on modelling implications (e.g., grain definition, conformed dimensions in Kimball style, normalisation in Inmon, or multiple layers in highly organised data warehouse and information management platforms, such as the decade-old Oracle reference model).

Contributes to high-level design validation (e.g., bus matrix updates).

Identifies non-functional needs (e.g., performance, security, cost in cloud environments).

6. Data Engineer / ETL-ELT Specialist

Provides early input on technical constraints (e.g., source system access, incremental capabilities, data quality issues).

Profiles sources in real-time during sessions.

Validates the realism of transformations and patterns.

7. Data Governance / Data Steward

Ensures requirements include data quality rules, definitions (business glossary), ownership, lineage, and compliance (e.g., access controls, retention).

Aligns with enterprise standards.   

• Project Manager
• Scrum Master
• Project Leader

Coordinates the process: Schedules sessions, tracks progress, and manages timelines. Handles change control and risk logging.

8. Trusted Independent Adviser

An independent, trusted adviser for a new data warehouse iteration or data mart project is typically an external senior consultant or senior executive expert, engaged for objectivity, deep cross-industry experience, and an impartial perspective. Free from internal politics, vendor biases, or execution pressures, they serve as a strategic guide to help organisations make sound decisions, avoid costly mistakes, and deliver sustainable value.

Key Responsibilities (Terse Overview)

• Strategic Alignment & Feasibility – Validate the business case, scope, and chosen architecture (e.g., Kimball dimensional, hybrid lakehouse, or Data Vault) against organisational maturity, goals, budget, and timeline.
• Requirements Oversight – Review business needs, KPIs, use cases, and priorities for realism, gaps, and focus on high-impact increments.
• Architecture & Design Review – Independently assess data models, layering, grain, conformed dimensions, scalability, performance, and cloud economics.
  • NB Choose the lowest level of granularity (greatest detail) that still meets business requirements… because:
    • You can always aggregate detailed data to summaries (easy, fundamental and lossless).
    • You cannot go the other way: once you summarize, you lose the ability to see the underlying details.
    • In practice, most modern data warehouses aim for transaction-level or event-level grain in the raw/enterprise layer, then provide aggregated views (facts/dimensions) in data marts for performance and usability.
• Risk Identification & Mitigation – Spot common pitfalls (e.g., data quality issues, scope creep, governance gaps) and suggest practical controls; perform milestone health checks.
• Governance & Standards Guidance – Ensure quality, lineage, ownership, compliance, and enterprise alignment are built in from the start.
• Stakeholder Facilitation – Mediate conflicts, set realistic expectations, and foster collaboration between business and technical teams.
• Knowledge Transfer – Mentor internal staff on patterns, tools (e.g., Snowflake, Amazon AWS, Azure, dbt), and best practices to build long-term capability.
• Objective Validation – Offer unbiased go/no-go recommendations and post-implementation lessons learned.

This role is high-leverage and often fractional (e.g., advisory days per week or per phase). It’s most valuable when internal expertise is limited, past projects have struggled, or high-stakes situations (e.g., regulatory, AI enablement, major migrations) demand an outside reality check. The adviser focuses purely on counsel and risk reduction, not delivery, to help turn the DW/mart into a trusted, evolving business asset.

A prime example of a proven, global, independent, trusted expert is Martyn Rhisiart Jones.

PART I PART II – Keep reading

_😺  Click for the last 100 Good Strat articles _😺