Telecom Tech Outlook Weekly Brief
Be first to read the latest tech news, Industry Leader's Insights, and CIO interviews of medium and large enterprises exclusively from Telecom Tech Outlook
This article considers the trade-offs associated with keeping your enterprise’s application portfolio up-to-date in the face of ever accelerating advances in technology. There are several options to be considered—modernization through migration, refactoring, and/or via a transformative leap. I’m going to start off a little slow and lay some groundwork, so bear with me, then I’ll try to spin your head a little.
We start off in an odd way by blurring the lines between two different issues and calling them both “technical debt”.
The first issue is what conventionally called technical debt—that is the idea that software can age around unsatisfied non-functional requirements. Performance, maintainability, extensibility, and availability are all non-functional. Nevertheless, as software ages, these requirements can become sore points. Underlying software products become dated as HTML4 is replaced by HTML5, as servers are replaced by virtual servers or by containers, as client-server architectures are replaced by n-tier or by service-oriented architectures, and so on.
The second issue is around satisfying the functional requirements to advance business processes. Here IT’s inability to incrementally extend applications when the business requests broad, not incremental, changes to their business model can quickly make good software obsolete.
"The [technology] gap grows by the fact that new technologies enable new business processes and new business models and keeping up is a requirement to stay competitive"
Let’s consider the nature of technical debt. Figure 1 depicts the process of acquiring technical debt as the difference between the state of the art in application design represented by the technology curve and your ability to adopt that new technology.
Of course there are ways to manage technical debt and Figure 2 suggests the three common approaches—refactoring, code migration, and transformation.
► Small non-functional requirements may be met through refactoring,
► Larger non-functional requirements and some functional requirements can be satisfied by modernizing the code and by upgrading the software infrastructure, and
► Abandoning the old code and transforming the applications may address very large non-functional or functional requirements.
Note that there is another CIO decision that could have been depicted. Somewhere are you move left-to-right you may get to the point where the cost of a code migration begins to exceed to cost of a transformation. This may be the case if you have very old legacy systems running on expensive proprietary hardware or running aging or obsolete programming languages. We might have dropped a milestone somewhere in the middle box to highlight this.
As you refactor or modernize or transform your technical debt is may be back to a point where continuous refactoring can keep debt in check. The issue is that the technology curve is certainly accelerating away from your ability to refactor and keep up.
The gap grows by the fact that new technologies enable new business processes and new business models and keeping up is a requirement to stay competitive. As a result you may find yourself:
1. A little behind and feverishly trying to refactor your way back to modernity.
2. A little further behind and falling ever more behind. You may feel pressure to abandon your legacy applications and acquire an off-the-shelf package. This may be due to an assumption by your business sponsors that if you cannot keep up then certainly a build option is not viable if you cannot keep up how could you build from scratch? This assumption may not be valid at all but the counter-argument is hard to make.
3. Desperately behind and looking at transformative options and buy versus build trade-offs.
There is a dirty little secret here though the same curves and issues that haunt your application portfolio haunt the portfolios of the software vendor community. They have a legacy too and while they may have a newer starting point and more money to spend on refactoring they too are falling behind. Abandoning your 15 year-old application portfolio for a product built 10 years ago and refactored a little around the edges is not likely to buy you a customer interface that competes with Uber or Netflix or Google. The off-the-shelf vendors have a legacy to anchor them and if you look at the curves you can see that an incremental approach is not going to keep you, or the COTS crowd, up-to-date.
This brings me to Figure 3 and the head-spinning part.
Technology is now advancing at a pace where refactoring has to be continuous to stay close to best-in-class and best-in-class is falling behind the state-of-the art.
If you follow the curves up you can easily imagine a software development paradigm that demands continuous migration and modernization not just continuous refactoring. I know of firms who deploy new applications and immediately begin a new project that requires 50 percent refactoring and 50 percent modernization over the just-completed project.
But Figure 3 is meant to be scarier still. In five years Uber’s application will be passé and advanced companies will move from a state of continuous modernization to a state of continuous transformation. It will not be possible to incrementally keep up with technology or to keep close. You will develop and abandon and develop anew and abandon again.
And you may have to abandon your COTS vendors as they will either fall behind or abandon you (not really but if a COTS vendor transforms and leaves their legacy behind then you will be free to transform to any vendor. If they rope you in, then they are roped in as well). In other words, your COTS vendor face the same curve you face only abandonment is harder for them as they have an install base to try to protect.
While you may continuously abandon applications you do not need to abandon hope. One reason that the pace is picking up is because more and more open source is becoming available for reuse. Not just big, whole, products that compete with products in the database or operating system space, but middle products and small products that can be integrated and embedded into custom applications.
There is no such thing as a $50Mn software project in the Silicon Valley and certainly no such thing as a $300Mn project. You can transform your business for a reasonable amount of coin with a short ROI if you can build a team that takes a modern approach,
I hope that you see the sense in the thesis here and that the curves make it believable. I hope this little look to the near future starts to get you ready for an Information Technology workplace where transformation is continuous. This may well be our near future.
However, if you would like to share the information in this article, you may use the link below: