Organizations often associate continuity with keeping systems, products, or capabilities running. Yet continuity can require the opposite: knowing when something can safely cease to exist.
A mature portfolio does not only make informed decisions about what to add. It also makes informed decisions about what to remove.
One provocative measure of product-portfolio maturity is therefore the number of systems an organization has been able to retire. The measure should not be taken literally—retiring more systems is not inherently better—but the reasoning behind it is revealing. Retiring a system confidently requires understanding what the system still contributes and what depends upon it.
Consider an old mainframe environment.
Over many years, applications may have been migrated elsewhere. New development has stopped. Most known business functionality has disappeared. The organization believes that the mainframe has effectively become redundant.
Yet it remains operational. Why? Because nobody is sufficiently confident that it can be switched off.
There might still be a batch process running somewhere. An obscure interface may still exchange data with another system. A business process performed only once a year may depend upon it. Some responsibility may have been assumed to have migrated but never actually did.
The organization does not know that the mainframe is necessary. It does not know that it is unnecessary. That distinction can keep an obsolete system alive for years. Loss of understanding can preserve obsolete realizations
This exposes an interesting inversion. Normally, understanding is associated with an organization’s ability to maintain and develop something. But understanding is equally important when deciding to stop maintaining it.
As organizational understanding disappears, the realization can become increasingly difficult to change or remove. Its known value may decrease while uncertainty about its unknown value increases.
Eventually the organization may preserve the realization not because it believes the realization is valuable, but because it cannot establish that removing it is safe.
Loss of understanding can increase the persistence of something whose value has already disappeared.
The resulting portfolio contains systems that survive through uncertainty.
They consume infrastructure, licenses, operational effort and scarce expertise. They may constrain architectural change and introduce security or operational risks. Yet attempts to remove them encounter the same question:
Are we absolutely sure nothing important still depends on this?
Without sufficient understanding, the organization cannot answer.
Retirement is an assessment problem
Retiring a system is therefore not merely a technical activity. It requires an assessment. The organization needs sufficient understanding of the system’s purpose, current contribution, dependencies, users, data, business processes and outcomes to form a justified judgment about what will happen when it disappears.
Evidence may need to be collected: usage information, interface traffic, batch execution, dependency analysis, business-process mapping, stakeholder knowledge or controlled interruption.
The question is not simply whether the system appears obsolete.
The question is whether there is sufficient evidence and understanding to justify the judgment that its removal is safe.
This connects retirement directly to Continuity.
Continuity does not mean preservation of the object
Continuity can easily be misunderstood as an argument for keeping things alive. It is not.
The continuity that matters is continuity of what remains significant: intent, outcomes, responsibilities, knowledge and necessary relationships. A particular realization may cease to be the appropriate way of providing them.
Sometimes maintaining Continuity therefore requires replacing a system. Sometimes it requires transferring responsibilities elsewhere. Sometimes the purpose itself has disappeared and nothing needs to replace it. And sometimes the correct decision is simply to switch the system off.
The ability to make that decision confidently depends on understanding.
Poor Continuity may not cause an old system to disappear. It may be precisely why nobody dares to switch it off.
The portfolio implication
This has consequences for portfolio management. Portfolio development is often associated with investment: selecting new products, approving initiatives and allocating resources to new opportunities.
But a portfolio also develops through subtraction. Removing redundant elements releases resources, reduces complexity and risk, and allows investment to concentrate on elements that continue to contribute to portfolio intent.
A mature portfolio-management capability therefore needs to understand its existing portfolio well enough to answer not only:
What should we add?
but also:
What can we safely stop?
This makes retirement capability an interesting indicator of portfolio understanding. An organization that continually adds new systems but cannot confidently retire old ones may not have a technology problem at all.
It may have accumulated understanding debt at portfolio scale.
And I think this one is particularly valuable because it produced a candidate generic insight for A:
Sufficient understanding is required not only to develop and assess a subject, but also to determine when it can safely cease to exist.
Leave a Reply