Not Just Data: How To Deliver Continuous Enterprise Data

Not Just Data is an easy-to-read management novel that describes the story of a team building and then evolving a continuous enterprise data pipeline.

What is a continuous enterprise data pipeline, you ask? Let’s work toward a definition:

  • Continuous enterprise data is up-to-date enterprise data that is available on an as-needed, when-needed basis, reflecting the changing needs of data consumers.
  • Enterprise data is fit-for-purpose data derived from multiple sources across the organization.
  • Fit-for-purpose data is high-quality data provided to the right data consumers at the right time and in the right way.

Therefore, a continuous enterprise data pipeline delivers up-to-date, high-quality data from across the organization to the right data consumers on an as-needed, when-needed basis, while reflecting their changing needs over time. That’s a mouthful, which is why I started with the above definitions.

This team was formed because their organization requires continuous enterprise data to support data-informed decision-making and their corporate artificial intelligence (AI) projects. This initiative begins immediately after a visible, multi-year failure that followed a traditional/predictive strategy for building an enterprise data warehouse. The team adopts a Disciplined Agile® (DA) strategy, starting with a Scrum-based way of working (WoW) and eventually evolving it into a lean, continuous-delivery WoW. This enables them to best-respond to the changing needs of their stakeholders. They also adopt a Data Vault 2 (DV2)-based architecture because they require a future-proof, scalable, extensible, and auditable pipeline.

What is a Management Novel?

The approach taken in this book is referred to as creative non-fiction or narrative non-fiction. The book is written as a novel – along the same lines as The Goal and The Phoenix Project – describing the experiences of a data warehousing team tasked with providing continuous enterprise data to their organization.

The setting is BigFinCo, a large financial institution offering banking, insurance, and wealth management services. This is an established organization with an existing technical infrastructure, an existing culture, and competing internal priorities. It isn’t the simple environment of a start-up company where you’re starting from scratch.

The storyline is based on an amalgam of my own experiences and, in some cases, those of my colleagues, helping organizations improve the WoW and WoT around their data activities. Data activities include data profiling, data design, data cleansing, data security, and many more. The plot reflects what I’ve seen happen on real teams; it doesn’t rely on luck, and in fact, a few unfortunate things happen along the way. In other words, a typical IT initiative. Having said this, the usual legal weasel-words still apply: This is a work of fiction, any similarities to real-world organizations or real-world people are mere coincidences, I accept no liability, and if anything goes wrong it’s completely and utterly your fault. Yeah, I think that’s how lawyers word that sort of warning.

Who Is This Book Written For?

This book is written for senior data team members, team leaders, business stakeholders who work with them, and leaders who govern/oversee them. For our purposes, a “data team” may be focused on data warehousing (DW), business intelligence (BI), data analytics, a data product, or a data platform. The team in this book is a DW/BI team. It is written as a management novel to increase its consumability for this audience.

Table of Contents

  • Chapter 1: The Postmortem
    • Introducing the Team
    • The Need for Continuous Data
    • BigFinCo Faces Real Challenges
    • Lean, Non-Invasive Governance
    • Lessons Learned From Utopia
      • #1: We Need a Fit-For-Purpose Data Architecture
      • #2: Deliver Business Value Regularly
      • #3: Act on Changing Stakeholder Needs
      • #4: Converge Will Be a Governed Self-Organizing Team
      • #5: Modern Problems Require Modern WoW
  • Chapter 2: Forming the Team and Selecting Initial WoW
    • What Do We Need to Accomplish?
    • Identifying Potential Team Members
    • Choosing Their WoW
    • Will An Agile WoW Work for Data?
    • Governance?  Really?
  • Chapter 3: Getting Going In The Right Direction Part 1
    • Agreeing To Our Overall Goals
    • Exploring the User Experience
    • Capturing Usage Requirements
    • Acceptance Tests as Executable Requirements Specifications
    • Identifying Business Concepts
    • Capturing Technical Requirements
    • Agile Envisioning
    • Concluding The Morning Modelling Session
  • Chapter 4: Getting Going In The Right Direction Part 2
    • How Architecture Envisioning and Planning Will Work
    • Exploring the Business Architecture
    • Identifying Data Sources
    • Exploring the Technical Architecture
    • Supporting Better, Data-Informed Decisions
    • Revisiting The Technical Requirements
    • Initial Planning and Guesstimation
    • Evolving the Vision
    • Agreeing To Our Stakeholder Vision
    • Initiation is More Than Envisioning
  • Chapter 5: Ensuring High-Quality Data
    • Defining Data Quality
    • The “Data is the New Water” Metaphor
    • Data Vault 2.1 Data Quality Strategies
    • Data Quality Strategies for Development
    • Validation Against Functional Requirements
    • Verification Against Quality of Service (QoS) Requirements
    • Parallel Independent Testing
    • Automating Data Quality Development Practices
    • Agile Quality Gates
    • Data Quality Strategies for Fixing Legacy Sources
    • Data Quality Techniques for the Organization
    • Measuring Data Quality
    • Moving Forward
  • Chapter 6: Addressing Risk Early
    • Proving the Architecture with Working Code
    • We Face Common Risks
    • Streamlined Milestone Reviews
    • Sprint Planning
    • Implementing the Walking Skeleton
    • The Proven Architecture Milestone review
  • Chapter 7: How Enterprise Data Flows Through the Pipeline
    • The Demo
    • The Design Review
    • The Persistent Staging Area (PSA)
    • The Raw Vault
    • Implementing Change Data Capture (CDC)
    • The Sparse Business Vault
    • Supporting Better Decision Making
    • Capturing Data Lineage
    • Evolving Our Enterprise Metadata
    • Detecting and Reporting Data Quality Issues
    • Design Reviews and Agile
  • Chapter 8: Working In Disciplined Sprints
    • How the Team Currently Works
    • Look-Ahead Data Analysis
    • The Definition of Ready (DoR)
    • Sprint Planning
    • Data Engineering
    • Parallel Independent Testing
    • The Definition of Done (DoD)
    • Sprint Wrap Up
    • Dropping Coordination Meetings
    • Oversight and Governance via Radical Transparency
    • Is the Problem with Sprints?
  • Chapter 9: Supporting Better-Informed Decision Making
    • End User Support
    • Quality In, Quality Out
    • Enabling Data Fluency
    • Shared Vocabulary
    • Effective User Interface (UI) Design
    • Designing for Performance
    • Better-Informed Decisions
  • Chapter 10: Deploying Into Production
    • Do We Have Sufficient Functionality?
    • Luckily, We Planned for This
    • Luckily, We’ve Been Deploying Internally
    • Are We Production Ready?
    • The Team Commits to a Release Date
    • The First Release is Always Rough
    • Did We Delight Our Stakeholders?
    • Sprinting Towards Continuous Deployment
  • Chapter 11: Supporting Artificial Intelligence. 149
    • Lessons Learned from Our AI Pilots
    • Building AIs
    • Question Stories for AI
    • Fulfilling AI Stories
  • Chapter 12: Continuous Enterprise Data Warehousing
    • Agile/Scrum Was a Great Start
    • From Project to Product
    • Agile/Scrum is Too Clunky Now
    • We Need to Stop Working in Sprints
    • From Scrum to Continuous Delivery
    • DataOps and Continuous Delivery
    • Improving Our Analysis Strategy
    • Why Do We Want to Deploy Quickly?
    • What If Our Stakeholders Don’t Want Releases This Often?
    • Why Didn’t We Do This Sooner?
  • Chapter 13: Measures of Success
    • Metrics in Practice
    • Measuring the Converge Team
    • Measuring the Converge Product
    • Measuring Data Quality Improvement
    • The Metrics Vault
    • What Gets Measured Pragmatically
  • Chapter 14: A Continuous Enterprise Data Pipeline
    • Organizational Success Factors
    • An Expected Journey
    • The Fellowship of the Team
    • One Data Strategy to Support Them All
    • You Can Do This Too

Why You Want To Read This Book

There are many reasons why you should read this book:

  • Continuous enterprise data supports data-informed decision-making.
  • Continuous enterprise data supports corporate artificial intelligence (AI) initiatives.
  • You need pragmatic ways of working (WoW) with enterprise data to address the increasing BANI/VUCA in your environment.
  • Continuous enterprise data makes your data an asset, rather than a liability.
  • You want a pragmatic, realistic example of how a data team can overcome the technical and organizational challenges that they face.

What People Are Saying

TBD – Praise quotes to come

Where to Buy the Book

TBD – Link to Amazon page

Other Important Stuff

Formats: Paperback and Kindle

ISBN: 979-824-3119-21-4

Published: February 28, 2026

Current Status: Coming soon!

Artificial intelligence (AI) statement: This book contains no AI-generated text nor images. AI-enabled features of my writing tools, in particular Microsoft Word and Grammarly, were used to spell-check and grammar-check my writing.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.