When organizations replace their systems without changing the capabilities that made replacement necessary.
A fresh start
An organization has reached technical bankruptcy. Its systems still work, but maintaining and adapting them has become prohibitively expensive, risky, or slow. Years of accumulated technical debt have made replacement more attractive than continued evolution.
Management launches a transformation program. Old applications will be replaced, business processes redesigned, and the application landscape modernized. Finally, an opportunity to leave the technical debt behind.
Or is it?
Déjà vu
The transformation begins. New technologies, new architectures, new applications.
But familiar problems soon emerge. Requirements are unclear. Architectural decisions are postponed. Testing starts too late. Delivery deadlines take precedence over quality. Shortcuts are accepted to keep the program moving. Technical debt starts accumulating before the new systems have even entered production.
The organization is replacing technically bankrupt systems while already creating the debt of their successors.
New systems, old capabilities
Perhaps the problem was never primarily technical.
The old systems accumulated debt because the organization struggled to manage requirements, architecture, quality, knowledge, and long-term product sustainability.
Now it is attempting a transformation using essentially the same organizational capabilities. Hiring experienced consultants, establishing a program organization, and introducing new processes may compensate for capability deficiencies without actually resolving them.
When the program ends, the organization inherits new systems, along with the technical debt accumulated during their development. And potentially the same capability deficiencies that contributed to the previous bankruptcy.
Transformation isn’t capability development
A transformation program is an intervention. Often an enormous and expensive one. It changes systems, technologies, processes, and sometimes organizational structures. But that doesn’t necessarily develop the capabilities needed to sustain them.
Which capabilities were insufficient before the transformation? How did those deficiencies contribute to the deterioration of the old systems? And what is being done to prevent the same problems from recurring?
These questions should be part of the transformation itself, not merely lessons learned afterwards. Otherwise, the organization may successfully replace its products without improving its ability to sustain them.
Breaking the cycle
A transformation provides an opportunity to do more than replace technically bankrupt systems. It provides an opportunity to develop the organizational capabilities needed to prevent the next technical bankruptcy.
That means treating capability development as an explicit objective, alongside delivering the new systems. Not simply asking whether the new solution works, but whether the organization will be capable of sustaining it.
Otherwise, the organization may transform its technology without transforming its capabilities.
And the next technical bankruptcy may already be underway.
Leave a Reply