01 — A technical change can also be a product change.
Changing a supplier, API, or architecture can alter behavior even when the interface barely changes.
CASE / 01
Credit bureau migration
Data, business rules, and product decisions during a structural change.
A credit bureau migration can look like a supplier replacement.
In practice, changing the data source also meant reviewing the structures, classifications, processing, and rules supporting different product behaviors.
During Foregon's migration to a new credit-data structure with Quod, I helped understand and organize the impact of that change, connecting Product, Engineering, and Business discussions.
CONTEXT
Changing the source meant changing the system.
Some Foregon products and services depended on credit-bureau information.
Over time, product behaviors had been built around the previous source's structure and rules.
The change was more than replacing an API. We needed to understand what would remain available, how data would be structured, stored, and refreshed, and which parts of the product depended on it.
CHALLENGE
Receiving data did not mean knowing what to do with it.
The new source could return different financial categories.
Technically receiving that information was only one part of the problem.
The product still needed to define how each record should be interpreted, when it should count as a pending issue, and how new information would replace previous data.
“Data only gains meaning inside a product when rules can interpret it.”
MY ROLE
Design inside a technical discussion.
My role was not to define the software architecture.
It was to understand its product implications, organize relationships, question behaviors, and help Product, Engineering, and Business build a shared view of the problem.
SYSTEM / 01
Making the system visible.
Information did not move directly from the bureau to the product.
It passed through ingestion, storage, processing, rule application, and consumption by different services.
Visualizing this path made dependencies visible that had previously been scattered across teams and people.
Separating source, ingestion, storage, processing, rules, and consumption clarified where each decision needed to happen.
SOURCE → INGESTION → STORAGE → PROCESSING → RULES → CONSUMPTION
SYSTEM BEHAVIOR
When architecture changes, product behavior can change too.
Part of the processing would happen asynchronously.
That meant accounting for intermediate states: a refresh could be processing, previous data could remain stored, or an external dependency could fail.
People did not need to know about an SQS queue, but they would feel its consequences through information availability and reliability.
SYSTEM / DATA
Data also has a lifecycle.
Scores and pending issues were not necessarily static information.
We needed to discuss when to query again, when to persist new data, when to keep previous records, and when an update should trigger other events.
Does this behavior still make sense in the new structure?
The migration also revealed that some existing rules were consequences of how the previous provider worked.
The goal should not be to reproduce current behavior inside a new architecture.
The change created an opportunity to question which assumptions should continue to exist.
COLLABORATION
Decisions formed a network, not a sequence.
A Business decision could change a Product rule.
That rule could alter technical processing.
A limitation found by Engineering could require Product to revisit a decision.
The work advanced through dependencies and continuous review.
OPEN QUESTIONS
Not every answer was available from the start.
Some decisions depended on the real integration, others on validation with Quod or Business definitions.
Making those uncertainties explicit prevented temporary assumptions from silently becoming permanent rules.
“Documenting what we still do not know can be as important as documenting what has been decided.”— this is still a hypothesis.
OUTCOME
A new structure with more explicit assumptions.
The migration structured the transition to a new credit-data source and required a review of dependencies across integration, storage, processing, and product rules.
More than replacing a supplier, the work made assumptions from the previous structure explicit and helped decide which ones still made sense.
Separating data source, processing, interpretation, and product behavior clarified where each problem needed to be solved and which teams belonged in the decision.
REFLECTION
What stayed with me.
02 — Not every Design problem starts with an interface.
Mapping dependencies, organizing uncertainty, and building shared understanding are also part of the work.
03 — Making the problem visible improves decisions.
Maps, flows, and documentation can build a shared view among people who see different parts of the system.
“Design also happens in the decision structure that determines what a product can do.”
