The data problem nobody sees until SIT
System test usually keeps real data out on purpose, so data defects and new scenarios first surface in SIT. An early first cut finds them at the start.
6 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). System test comes before SIT, but the system integrator (SI) runs it on controlled datasets, so the defects your real data carries, and the scenarios nobody scripted, are still waiting when SIT begins.
By then the build is finished and the whole programme is mobilised. Data migration sits on the critical path, so while the defects are traced and the solution's gaps closed, 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. Keep it there with iterative data cuts, and run validation and reconciliation as gates on every load. 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.
System test keeps real data out on purpose. The SI is testing the software, and a controlled dataset gives each test a clean answer that data defects and unscripted scenarios would cloud. That is a sound choice, and it leaves the first full load of real, converted data to SIT.
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 system test.
The solution design has the same blind spot. A controlled dataset holds the scenarios someone thought to write down, so system test can pass while the solution still has gaps that real data would show on its first load.
In SIT the data defects and the solution gaps arrive together, in the phase with the least schedule left to absorb them. Each one costs programme time and money as soon as it is found. 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, ideally before the solution design workshops begin, and then again in iterative data cuts. Each cut runs code printed from the same mappings, with the last cut's fixes and any new scope added. Validation and reconciliation run on every load as gates, and a load that fails them does not advance, so defects are isolated at the earliest and cheapest possible time. Where scope allows, elfware lands a first cut in as little as 3 days, with data prototypes in about 3 weeks.
The cuts are cheap to repeat because elfware configures the migration flows and mappings rather than writing or changing code, and prints the code from them. Run as often as the programme needs, they also validate the solution design and its integrations against real data while change is cheap.
The cuts can run alongside the SI's system test, feed its datasets, or both, because elfware configures the data scope and filters for each activity from its requirements. Started ahead of the solution design workshops, they show the data defects before system test and SIT, so those defects can be filtered out of the test datasets reliably while the records are cleansed or enriched in parallel. SIT then tests the integrated system on data the programme has already loaded, reconciled and designed against.
The usual plan
- Configure and specify
- Build
- Unit test on samples
- System test on controlled datasets
- 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 iterative data cuts run
elfware reuses existing adaptors to accelerate the first cut.
The first cut can be close to the full dataset, with records that fail validation filtered out of the load. Those records are reported, and each one returns on a later cut once it is fixed, in the mapping or by cleansing or enriching the source. A near-full first cut lets the solution design workshops run against the business's real data in the target system, so the business sees its solution early, without weeks and months of workshops.
Each cut re-runs the same way. A changed result points to a change in the data, the mappings or the target. Every load is validated against business rules mapped to the data model, with sample sizes and error limits set, and source and target are reconciled for both correctness and completeness.
Mappings are self-documenting, so when a load fails, a single analyst takes the fix from request to deployment without a chain of intermediate artefacts and developers, and the next cut proves it.
What a first cut finds in merchandising data
Take a hypothetical department store moving its merchandising onto Oracle Retail. In the default plan, items, suppliers, prices and stock meet the new system in SIT, after system test has passed on a controlled set of items. With an early first cut, close to the whole item master goes in at the start, with its suppliers, prices and stock, and the records that fail validation are filtered out.
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 is fixed in the mapping. In the design workshops, the merchandising team works through its own items in the target and finds consignment ranges the design never provided for. By the time SIT starts, the merchandising data will have passed the gates on every cut since the first.
What the programme has before SIT
Real data in the target from the first cut. The mappings that produced it, and code printed from them, as the cutover code will be. A validation and reconciliation result for every load and a report of the records each cut filtered out, with execution and quality data trended across environments, so the steering committee sees the state of the data at each cut instead of hearing about it in SIT.
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, and iterative data cuts keep real data in the target from then on. That leaves a question for the next wave: does it keep the mappings and checks those cuts proved, or rebuild them by hand?
If you want to see your own data through a first cut, reconciled, talk to us.