Turn EDI transformations from custom code into a configurable system

Context

Evergreen handled a large volume of EDI data exchange across a very broad range of business domains.

Systems for finance, assets, POS, shipping, and other domains each had their own data structures and exchange formats.

At the time, many EDI jobs were implemented by engineers writing transformation logic field by field:

A field in Table A of System A → Maps to a field in the EDI format → Then handles type, format, or special transformation

Every new data exchange introduced another set of mapping code.

The problem was not merely the volume of code.

The real difficulty was that:

large amounts of code repeatedly described which field mapped to which other field.

My Decision & Action

I began to ask:

If the only real difference between EDI jobs was field mapping, did those differences need to be written as line-by-line transformation programs at all?

I therefore extracted field mappings from the program flow.

Java annotations described EDI mapping rules on entity fields, and reflection parsed that metadata.

At transformation time, a shared mapping mechanism dynamically obtained source and target fields, then performed get/set operations and data conversion.

Originally:

Each EDI format → Write a dedicated set of mapping code

Gradually became:

Entity field → Annotation describes mapping → Reflection parses it → Shared transformation mechanism executes it

When adding an EDI format, the focus shifted from writing another transformation process to describing how the data maps.

Outcome

A single mechanism could handle the previously duplicated field-transformation logic.

What each EDI job truly needed to maintain gradually converged into its mapping definition instead of being scattered through large amounts of custom code.

When an exchange format or field changed, it was also easier to locate the place that actually described the difference.

Reflection

This formed one of my earliest engineering intuitions:

If many programs differ only in their data, perhaps the difference itself should be described as data instead of by continuing to duplicate code.

At the time, I did not yet call this config-driven architecture.

Looking back, from EDI mapping and ERP/MES UI patterns to a no-code framework, I had consistently been addressing the same kind of problem:

extract recurring differences and leave the truly stable rules in the system.