Why Knowledge Debt Grows Fastest Once an Application Reaches Steady State

This chapter explains why Knowledge Debt grows fastest after an Application settles into routine operation, and what to do about it.

What Steady State Means

In this document, Steady State refers to the period of an Application’s lifecycle, after its initial Production Deployment has stabilized, during which it supports normal business operations and changes only through routine, governed Releases. It corresponds to the Operations and Maintenance phase of the Systems Development Lifecycle (SDLC).

For most Applications, Steady State is by far the longest part of their lives. An Application may take months to build and then run for many years.

Why Knowledge Debt Accelerates in Steady State

During initial development, an Application’s knowledge is at its most concentrated and accessible. The team that designed and built it is assembled, decisions are fresh, and questions can be answered by turning to a colleague. Once the Application reaches Steady State, the forces that erode that knowledge all begin to act at once:

• The original team moves on. Designers, engineers, and testers are reassigned to new work, change roles, or leave the enterprise. Contractors and vendor consultants finish their engagements.

• Memory fades. Even the people who remain forget why decisions were made and how rarely used procedures work.

• Change continues in small increments. Routine Releases, patches, configuration changes, and workarounds each alter the Application slightly. Individually, none seems important enough to document; together, they make the original documentation steadily less accurate.

• Attention shifts elsewhere. A stable Application receives little management attention, so its documentation receives even less.

• The cost of finding information rises. Each year that passes makes it harder and more expensive to reconstruct what should have been written down.

The result is a familiar pattern: an Application that has run quietly for years suddenly needs urgent attention, because of an outage, an audit, a security vulnerability, a vendor end-of-support notice, or a replacement decision, and the enterprise discovers that almost no one understands it anymore.

Best Practice: Keep Application Documentation Current Throughout Steady State

Treat Steady State as the period of greatest documentation risk, not the period of least. Require that documentation be reviewed and corrected with every Release, however small, and periodically even when Releases are rare, so that it continues to describe the Application as it actually is. The chapter “Review and Correct Application Documentation with Every Release” describes how.

Benefits: Keeping documentation current throughout Steady State preserves the enterprise’s understanding of an Application across the many years in which the people who built it are no longer available. It means that when a long-stable Application suddenly needs attention, the knowledge required to act is already in hand rather than having to be rebuilt in a crisis.

Connections to Related IF4IT Practices and Inventories

The Systems Development Lifecycle (SDLC) Best Practices describes the Operations and Maintenance phase. The Release Management Best Practices describes the routine, governed Releases through which Applications change during Steady State.