Learning Objectives
By the end of this lesson you will be able to:
- Explain what the DMZ is and why it exists in PDM
- Describe the commercial risks that the DMZ is designed to manage
- Identify the questions that must be resolved when establishing the DMZ
What Is the DMZ?
The DMZ - Demilitarised Zone - is the contractual and operational boundary between the client organisation and any external supplier on a data migration project.
The name comes from the military concept of a neutral zone between opposing forces. In data migration, the “opposing forces” are the client’s interest in getting clean data migrated at minimum cost, and the supplier’s interest in being paid well for any work they do.
The DMZ defines:
- What data flows across the client-supplier boundary and in what form
- Who owns data quality issues on each side of the boundary
- What commercial treatment applies to each category of work
Why the DMZ Matters
Without a clearly defined DMZ, data quality work becomes commercially contentious. Consider a common scenario:
- The client’s legacy data has significant quality issues
- The supplier discovers these during the ETL build
- The supplier claims the issues are out of scope and requests a change order
- The client believes the supplier should handle data quality as part of the migration
- Neither side is entirely wrong
This dispute is resolved not by negotiation after the fact, but by clear DMZ definition before the work begins. The DMZ document specifies which side owns which type of data quality issue, and what the commercial treatment is.
Questions the DMZ Must Answer
When establishing the DMZ, the project must resolve:
On data quality work:
- Who is responsible for running data profiles on the legacy systems?
- Who provides DQR metrics reporting? (Is this the client’s team or the supplier’s?)
- What amount of in-flight data correction is allowed for in the contract? (i.e. how much transformation work is in scope for the supplier?)
- What support for the DQR process is contractually provided by the supplier?
On physical data exchange:
- In what format and frequency does legacy data cross the DMZ?
- Who is responsible for securing the data in transit?
- Where does physical exchange happen? (The DMZ is sometimes a literal file transfer point - files dropped to a shared drive or transferred via secure API)
On commercial treatment:
- Are data quality issues that delay the supplier treated as client-side variations?
- What is the escalation path when a dispute arises?
- Does the contract include explicit data quality milestones?
The DMZ and Fixed-Price Contracts
The interaction between the DMZ and fixed-price contracts is particularly important.
In a fixed-price contract, any work on the supplier’s side that is attributable to the client’s data quality becomes a potential change order. If the DMZ is not precisely defined, the supplier can attribute almost any problem to client-side data quality.
PDM recommends that the DMZ document be developed before the contract is signed - or, if that is not possible, that the contract include explicit provisions for DMZ negotiation as a project deliverable in the first phase of work.
The DMZ in Embedded PDM
In an embedded PDM engagement - where PDM is being run by the client team within a supplier-led programme - the DMZ has additional significance. The supplier may have its own methodology for data migration, and the PDM processes (DQR Board, BTR interviews, release management) may sit awkwardly with the supplier’s programme governance.
Establishing the DMZ in this context includes agreeing how PDM processes interface with the supplier’s processes: who chairs the DQR Board, how BTR outputs feed into the supplier’s design work, how release management relates to the supplier’s development schedule.
Key Takeaways
- The DMZ is the contractual and operational boundary between client and supplier on a data migration
- It must specify data quality ownership, data exchange format and frequency, and commercial treatment of quality issues
- Without a defined DMZ, data quality disputes become commercial disputes - expensive and damaging to the project relationship
- The DMZ should be defined before the main contract is signed, or as an explicit first-phase deliverable
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 06 - Demilitarised Zones