Platform engineers discover aging ETL jobs, undocumented schemas, and brittle overnight feeds, but the roadmap only lists new cloud projects. What should architecture leadership add?
Select an answer to reveal the explanation.
Short Explanation
Debt you pretend is not there still charges interest every night the batch fails. Put data-platform tech debt on a real register and let it fight for roadmap slots like any other work.
Full Explanation
Aging ETL jobs, undocumented schemas, and brittle overnight feeds are data-platform technical debt that competes with new cloud projects for scarce municipal capacity. Architecture leadership should maintain an explicit technical-debt register that inventories liabilities, estimates risk and cost of delay, and informs roadmap prioritization alongside modernization initiatives. Without that register, roadmaps that only list new logos systematically underfund reliability work until batch failures, opaque schemas, and unsupported runtimes interrupt citizen services. A marketing brochure of new platforms with no inventory of known liabilities substitutes messaging for architecture management. A policy that forbids mentioning legacy jobs to protect morale hides operational risk from funding decisions and on-call reality. A rule that only greenfield builds may appear on roadmap slides creates perverse incentives to abandon workable remediation and to rebuild endlessly. Exam caveat: registering debt does not mean freezing innovation; it means sequencing remediation with capability delivery using transparent criteria rather than pretending legacy platforms are free. Operational check: list top fragile feeds with owner, blast radius, last successful run, and remediation option; score them; reserve a fixed roadmap capacity slice for debt retirement; and report monthly whether high-risk items are trending down before the next go-live.