Architecture rework

What it means

Architecture rework includes replacing a boundary, reversing a dependency choice, migrating a contract, or undoing a platform decision. It can be necessary learning rather than waste, so teams should distinguish planned evolution from avoidable correction. Measuring the work helps expose recurring decision and validation gaps.

Example

A service split is followed by a consolidation because operational ownership was underestimated. The team records the rework, compares the assumptions with production evidence, and updates its decision process.

Limitations

Counting rework is difficult when architecture changes are mixed with feature work. A large migration may deliver value even while changing structure. Use explicit labels and review the reason for the change.

How to use the signal

Separate planned evolution from avoidable correction so a migration is not labeled waste merely because its design changed.

Weave can connect architecture rework to pull request history, review depth, and delivery delays. It does not determine whether the change was avoidable, so retain the decision rationale.