Learning Objectives
By the end of this lesson you will be able to:
- Define Landscape Analysis in the PDM context
- Explain why Landscape Analysis should start early and run as a Super Smart Task
- Describe the structure and essential elements of an LDS list entry
📦 The DHGS Story - Episode 2: The system nobody declared. As DHGS runs its Landscape Analysis, discovery surfaces a store nobody put on the official list: a spreadsheet running the Kelsey Pit extraction equipment, owned by production manager Whit Bissell - who resents IT “touching his systems”. The data-quality problems hiding in that spreadsheet become DQR entries the team tracks to resolution, and the Business Transformation work in this module is what turns Whit from blocker into a signed-off stakeholder.
Remember the Logia-vs-HAL decision from Module 02? The mapping work now has to deliver what that contract promised - and Kelsey Pit is where it first gets hard.
What Is Landscape Analysis?
Landscape Analysis (LA) is defined in PDM as:
The systematic discovery, review and documenting of the Legacy Data Stores including their linkages.
The key word is systematic. LA is not the informal process of asking IT what systems are in scope. It is a structured programme of discovery that uses multiple channels - IT inventory, interviews, DQR discoveries, and testing - to build the most complete possible picture of where the legacy data lives.
Why Start Early?
Landscape Analysis should begin as soon as the project is initiated - before the target system is fully defined, and before the ETL team starts work. The reasons:
-
Elapsed time for semantic resolution - when you discover a legacy data store with a field called “customer status” that means something different in every business unit, resolving that takes time. Time that cannot be compressed by starting later.
-
Super Smart Task opportunity - the discovery process is an ideal early engagement with the business. Asking a business unit to help you understand their systems is far less threatening than asking them to fix their data quality. It builds the relationship before the difficult conversations.
-
Timeline pressure relief - every LDS discovered late is a compressed analysis and mapping exercise under deadline pressure. Discoveries made in the first month have many months to be resolved. Discoveries made in the final two months create crises.
The Rule: If You’re Not on the List, You’re Not Coming In
One of the most important principles in LA is that the LDS list is under change control. Once established, anything not on the list is potentially out of scope - and bringing it in later requires a formal change.
This is not bureaucratic obstruction. It is the mechanism that prevents the migration from expanding indefinitely as new stores are discovered. The phrase in PDM is: “If you ain’t on the list, you ain’t coming in.”
This principle also creates an incentive for business units to come forward early. A late-discovered LDS that misses the list is a risk to the business unit’s own migration.
Conducting LDS Discovery
The initial LDS list comes from the Migration Strategy Document. It will be incomplete. To extend it:
- Broadcast an amnesty - communicate to all business units that any legacy data store, no matter how small, should be declared. Reassure them that declaring a store is not a commitment to migrate everything in it.
- Follow the interfaces - systems that interface with known LDS often contain derivative or copied data that also needs to be assessed.
- Use DQR discoveries - data quality issues often reveal previously unknown stores (“we keep a separate spreadsheet for that because the system doesn’t handle it properly”).
- Listen in LA interviews - when talking to a Data Owner about their main system, ask what else they have.
The LDS List: Essential Elements
Each LDS in the list requires at minimum:
| Field | Description |
|---|---|
| LDS Name | Name of the system or store |
| Function | Business function it supports |
| Key Data Stakeholder (KDSH) | The Data Owner responsible for it |
| System Retirement Plan | Reference to the SRP for this LDS |
| Topography | Where it sits in the network, how it connects to other LDS |
| Scale | Volume of data (records, size) |
| Entities | The data entities it contains (from the Conceptual Model) |
| Access | How the project can access the data |
| Format | File type, database type, API, etc. |
| Data Origin | Is the data mastered here, derived, or copied from elsewhere? |
| Quality | Initial assessment of data quality |
The LDS list is a living document. It will extend as new stores are discovered. It should be made public within the project - transparency prevents surprises.
Beyond Systems: Reports and External Interfaces
A landscape is more than the systems and spreadsheets that hold data. Two things are easy to miss and expensive to discover late:
- Reports the business depends on - especially mandatory or statutory reporting (regulators, government returns, industry bodies). If the target cannot reproduce a report the business is legally required to file, that is a migration blocker, not a nice-to-have. Capture every report a legacy store feeds, who consumes it, and whether it is discretionary or mandated. Note: seeking reports during LA should not break the principle that it is the supplier’s responsibility to design, build and test the target solution. Discovering what reports exist is the migration team’s job. Rebuilding those reports in the target is the supplier’s. If the target cannot support a report, the migration team can raise a DQR against the supplier, but it is up to the supplier how they handle the request. The migration team will not be building production reports or altering data structures to support them.
- Interfaces to external and national systems - feeds to and from systems you will not migrate but must keep working: payment gateways, national or industry registries, partner data exchanges, regulator portals. You don’t move them, but the migration must preserve the interface and the data it depends on.
For DHGS this matters concretely: gravel extraction is regulated, so there are statutory extraction-volume returns to capture; and DHGS has live external interfaces - the online-retail payment gateway and fleet telematics - that survive the migration and constrain it.
Migration Model
When multiple LDS contain versions of the same entity (e.g. Customer in three different systems), the project needs a Migration Model - a single reference model against which all three are analysed.
The Migration Model is not the target model (which is the target system’s responsibility). It is an intermediate analytical tool, built to a level 0 or level 1 of detail, sufficient to identify inconsistencies and plan the mapping.
Typically the Migration Model starts from the most structured or dominant LDS and is extended to accommodate the other LDS.
Key Takeaways
- Landscape Analysis is the systematic discovery and documentation of every legacy data store - not just the obvious ones
- Starting early creates time to resolve semantic issues and builds early business engagement
- The LDS list is under change control: late discoveries carry a cost
- Each LDS entry captures function, KDSH, topography, scale, entities, access, format, data origin, and quality
- When the same entity appears in multiple LDS, a Migration Model is built to consolidate analysis
- The landscape includes more than systems and spreadsheets - capture the reports the business depends on (especially mandatory/statutory reporting) and the interfaces to external systems you won’t migrate but must keep working
Book Reference
Practical Data Migration by Johny Morris (BCS, The Chartered Institute for IT):
- Chapter 10 - Landscape Analysis