Reconstructing a certificate-monitoring process

Replacing an inherited certificate-monitoring mechanism turned out to be more than rewriting code. The mechanism did more than the scope of the task suggested — from data synchronisation to reports, notifications and tickets — and its success message said nothing about whether the result was correct.

Its results were unreliable in both directions: errors reported after a correct run, and success reported with incomplete data. Simply rewriting the logic would have carried these errors into the new implementation.

I based the new implementation on four principles:

• Reconstructing how the process really works — establishing the data flow, functions and dependencies between components before writing the new implementation.
• Data-completeness control — incomplete data is not read as an absence of problems, and technical failures are kept separate from business results.
• Reconciling data with the source — data held in dependent systems is reconciled with the source, and elements that other processes may use are not removed without confirmation.
• Diagnosing dependencies before changing data — each integration is checked separately, and the rollout proceeds in stages before the solution starts modifying data.

From the existing code I reconstructed the data flow and dependencies of the whole process and identified the sources of the incorrect results.

I designed and deployed a new implementation with reconciliation against the source, completeness control, separation of technical failures from business results and diagnostics for individual integrations. The solution keeps the business functions of the existing process — reporting, notifications and tickets — does not report the same certificate repeatedly and closes stale alerts.

The solution runs in production without incidents, unnecessary alerts or night-time support calls. I reduced external software dependencies from seven to one library that was already available.

Value: a finished run is no longer taken as proof of a correct result — the process distinguishes technical failures from expiring certificates, keeps data consistent with the source and allows each integration to be diagnosed separately.