Governing 30 Apps After a Production Incident

Start with separation of duties and a single production path. Keep Development, Test, Staging, Production; no direct Development-to-Production path for shared modules or any app. Create LifeTime teams per product, with developers who can deploy to Test, release managers who can deploy to Staging and Production, and platform admins who manage environments. Remove Deploy to Production from the 26; grant it to named release managers and a documented emergency approver. Every production deployment uses a deployment plan with a tag, an approved change record, evidence of Test and Staging, and a rollback plan. Code review is mandatory for shared modules and any security-relevant change; use compare and merge with a second reviewer. Emergency changes are allowed but require after-the-fact review within one business day and a reason code. Business fusion teams keep autonomy in Development but not in production. This is minimum because it addresses the actual failure: unauthorized shared-module change, not all code quality issues.

Create a platform team with ownership of shared modules. Freeze new duplicate utility modules: new shared logic goes through a request and review. Use Architecture Dashboard to rank duplicates by number of consumers and change frequency; consolidate the top two first, not all six. For InventoryUtils, assign an owner, add tests, document its public actions, and require a versioned release. Migrate consumers one at a time with a compatibility layer; do not change all nine in one deployment. For the Forge component, determine whether the vulnerability is exploitable in this usage; if yes, patch or replace in a staging proof, then roll out by app risk. Add a software bill of materials for Forge components and a quarterly review. Track exceptions with expiry dates. Do not block feature delivery for cleanup; reserve 15-20% of platform capacity for debt. Report progress by risk reduced, not modules merged.

Use a small scorecard: deployment frequency, lead time, change failure rate, MTTR, percentage of production deployments with code review and Test/Staging evidence, number of emergency changes, open governance exceptions past expiry, and shared-module incidents. Review monthly at a platform council with IT and business representatives; quarterly with the CIO. Automate what can be automated: deployment plan checks, mandatory review flags, and Forge vulnerability alerts. Publish the scorecard so teams see the effect, not just the rule. Set thresholds that trigger action, for example two emergency changes in a month or any shared-module incident. Keep the policy short and publish an exception route with a 48-hour decision. The test of the model is whether delivery speed holds while shared-module incidents fall; if lead time doubles, simplify the approval, not the safety controls.