Learning Objectives
By the end of this lesson you will be able to:
- Define a Configurable Item and explain why version control is essential in data migration
- Define a Release in the PDM context and explain how releases are planned and delivered
- Distinguish between Release Cycles and Agile sprints
📦 The DHGS Story - Episode 3: Drawing the line with HAL. With HAL appointed, DHGS now draws the DMZ - the contractual boundary that sets who owns which data decisions, and where the fixed-price perverse incentive could bite. To keep analysis feeding the build rather than blocking it, DHGS chooses a blended waterfall/agile approach and governs delivery through the release structures in this module.
The Kelsey Pit data-quality issues from Module 03 don’t disappear here - they become items inside the release plan the team is about to run.
Configurable Items
A Configurable Item is any project deliverable that should be version controlled.
In a data migration, configurable items include not just code (which developers routinely version) but also the analytical and governance documents that define what the code should do:
- LDS list and associated documentation
- Mapping documents
- ETL code
- DQR forms and the DQR process itself
- Data requirements documents
- Business Transformation Realisations
- Reports and dashboards
- Release documents
- The Conceptual Entity Model and other data models
The version control requirement extends to business documents precisely because a mapping that was correct in Release 2 may need to be changed when DQR0012 is resolved in Release 5. If the mapping is not versioned, it is impossible to know which version of the logic produced which output.
Configuration management failure is present on almost every failing data migration project. It is rarely cited as the cause - but version confusion, contradictory mapping documents, and disputed releases are its symptoms.
What Is a Release?
A Release in PDM is defined as:
A collection of configurable items that together deliver a coherent ETL.
Releases are named and documented. Each release brings together a specific set of mapping rules, ETL code, data requirements, and DQR resolutions into a coherent package that can be executed, tested, and - if needed - rolled back.
Key features of releases:
- Coherent: A release is not a random collection of changes; it is a planned set of items that work together
- Repeatable: The same release can be re-run (for training, testing, or fallback)
- Versioned: The release document records the exact version of every configurable item it contains
- Fortnightly: Releases are planned and delivered in fortnightly cycles
Release Cycles vs. Agile Sprints
Release Cycles are similar to Agile sprints but with an important difference:
| Feature | Release Cycles | Agile Sprints |
|---|---|---|
| Cadence | Fortnightly | Typically 2 weeks |
| Planning mechanism | ”Push” - planned by governance (DQR Board + MSG) | “Pull” - planned by the delivery team |
| Who decides content | DQR Board with business stakeholders | Scrum team with product owner |
| Rollback mechanism | Previous release can be re-run | Varies |
| Multiple simultaneous | Yes - training and development releases can coexist | No - one sprint at a time |
The “push” vs. “pull” distinction is significant. In PDM, the release content is determined by the DQR Board - which includes business stakeholders - not by the delivery team in isolation. This keeps the business in control of what gets migrated and when.
Agile scrum teams can organise themselves to deliver within the release cycle - how they do their work within the sprint is up to them. But the external commitment (what this release will deliver) is planned by the governance structure.
Release Forking
Releases can be forked: parallel versions of a release can exist simultaneously for different purposes. Common scenarios:
- A development release with the latest DQR resolutions being tested
- A training release with a stable data set used to train business users
- An emergency fix release correcting a problem in a live release while development continues
Each fork is a separately versioned release. The release management process tracks which fork is in use for which purpose.
Release Management in the DQR Module
Release Management is a sub-module of DQR - it sits there because it uses the same tools and techniques (see Chapter 16 of the book). It is the mechanism by which the project’s governance structures (the DQR Board, programme management) maintain control over what gets built and when.
The practical implication: a DQR item that is resolved outside of the release management process - a developer who quietly fixes a mapping without going through a release - creates uncontrolled state. When the migration runs, the fix may or may not be present, and nobody can be certain.
Key Takeaways
- A Configurable Item is any project deliverable subject to version control - including business documents, not just code
- A Release is a named, versioned collection of configurable items that delivers a coherent ETL
- Release Cycles are fortnightly, “push” (governance-planned), and support multiple simultaneous releases
- Configuration management failure is a leading cause of migration project confusion - it may not be blamed but its symptoms (version conflicts, disputed outputs) are ubiquitous
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 16 - Release and Configuration Management