The data problem nobody sees until SIT
Data defects surface in system test because that is where many plans first load real data. An early first cut moves the load, and the discovery, to the start.
5 min read
Ask when your programme's real data will first be loaded into the new system. On a typical ERP plan the answer is system integration test (SIT), and the defects that data carries have been waiting for that date.
By then the build is finished and the whole programme is mobilised. Data migration sits on the critical path, so while its defects are traced and fixed, the team keeps billing and the cutover date starts to move.
Put real data into the target at the start instead, as an early first cut, and run validation and reconciliation as gates on every load after it. The problems SIT would have found then surface while there is still time and budget to fix them.
Why real data reaches the target so late
The usual sequence is sensible on paper. The target system is still being configured, so there is nothing to load into. The mapping specification has to be written and signed off before anyone builds against it. Extracts depend on BAU teams whose first job is keeping the business running. So the migration is designed, built and unit tested on samples, and the first full load of real, converted data waits for the integrated test environment.
Mock loads help, but with hand-built migration code each one is costly to run and check, so plans keep them few and late.
Why the defects wait for SIT
A mapping specification can be reviewed, signed off and still be wrong, because nobody has run it against the data it describes. Records that are valid in the legacy system but break a rule the new one enforces. Reference data the specification assumed and nobody owned. All of it shows up the first time real data is loaded, and the default plan schedules that load after the build.
The defects arrive together, in the phase with the least schedule left to absorb them, and the questions they raise land on the same BAU people in the same weeks. Because the checks run late and largely by hand, the business first sees its migrated data as a list of defects, and doubts it from then on.
If it is SIT, the plan has already decided when your data problems will surface.
The early first cut
The early first cut changes the order. Real data goes into the target at the start of the programme, before the full build, and every later load runs code printed from the same mappings, with fixes and more scope added. Validation and reconciliation run on each load as gates. A load that fails them does not advance, so defects are isolated early, at the earliest and cheapest possible time.
That is affordable because the migration is code-printed. It re-runs the same way every time, so the gates can run on every load from the first cut onward.
Where scope allows, elfware lands a first cut in as little as 3 days, with data prototypes in about 3 weeks. SIT then has a different job. It tests the integrated system on data the programme has already loaded and reconciled.
The usual plan
- Configure and specify
- Build
- Unit test on samples
- First real data load in SIT
- Defects found late
Early first cut
- First cut of real data
- Validation and reconciliation on every load
- Fix in the mapping, run again
- SIT on reconciled data
How an early first cut runs
elfware reuses existing adaptors to accelerate the first cut. The code that moves the data is printed from the mappings, and the same toolchain prints that code from prototype through to cutover.
Because the same mappings produce the same output every time, each load can be compared with the one before it, and a change in the results points to something that changed in the data, the mappings or the target. Each load is validated against the business rules mapped to the data model, with sample sizes and error limits set. Source and target are reconciled for both correctness and completeness.
When a load fails, the fix goes into the mapping. Mappings are self-documenting, so a single analyst takes the change from request to deployment without a chain of intermediate artefacts and developers, and the next load proves it through the same gates. The business sees its own data in the new system early, without weeks and months of workshops.
What a first cut finds in merchandising data
Take a department store moving its merchandising onto Oracle Retail. In the default plan, items, suppliers, prices and stock meet the new system in SIT. With an early first cut, a slice of real items goes in at the start, with the suppliers, prices and stock that belong to them.
The first loads are where the documents meet the data. An item hierarchy that does not fit the target's. Prices whose effective dates the mapping flattened into one current value. Items that point at suppliers missing from the extract. Each one is fixed in the mapping, printed again and proved on the next load. By the time the integrated system is tested, the merchandising data will have passed the gates on every load since the first cut.
What the programme has before SIT
Real data in the target from the first cut. The self-documenting mappings that produced it. Code printed from those mappings, as the cutover code will be. A validation and reconciliation result for every load, with execution and quality data trended across environments, so the steering committee sees the state of the data at each load instead of hearing about it in SIT.
The data workstream's estimate then rests on loads that have already run.
When does your real data first meet the target?
Find the date your real data first meets the target system. If it is SIT, the plan has already decided when your data problems will surface.
An early first cut moves that date to the start. It leaves a second question: whether the checks that catch those problems are kept, or rebuilt by hand for every wave.
If you want to see your own data through a first cut, reconciled, talk to us.