By Rob Klopp
This article is reposted from CIO.gov; the original post can be found here.
It seems that the second Modernizing Federal IT post on the Gravity of IP, which was originally posted on cio.gov in January of 2016, has been overlaid in the archive by the text from the third post. So… I’ll try to recompose the main points here and provide a complete rewrite. Those points are:
- Sometimes you get stuck to your legacy by the weight, the gravity, of the intellectual property you have developed in that legacy. This idea runs counter to the prevailing attitude that your legacy systems are operated and maintained by a bunch of old dogs who refuse to learn new tricks…and this cultural resistance to change is what ties you down.
- There is giant gravity on the modern side of your universe…but you need to find a couple of projects with that gain escape velocity to start leveraging the value there. I’ll suggest a strategy to gain this escape velocity.
- Once you escape a couple of times, the pull of modern IT technology will take hold and your team will gravitate towards building modern systems naturally.
Figure 1 Arc 1 describes the state government agencies find themselves facing.
They are attracted to the idea of modern, cloud-native, open-source, systems…but they have to engineer new features as fast and as cheap as possible. Engineers understand that working on the legacy side generates technical debt, but in a world of extremely tight government budgets they often must choose short-term gains over long-term cost of ownership.
Figure 1. The Gravity of Intellectual Property
Your engineers may believe they should be building services deployed in the cloud; but those services must call, or be called, by applications that run on legacy infrastructure. Those services can often be developed faster by leveraging intellectual property (IP) that resides in your legacy. In other words, given short-term constraints your engineers make exactly the right engineering decision when they choose to stay with legacy infrastructure. Arc 1 represents a scenario where the weight of your legacy IP pulls you back and you continue to develop software laden with technical debt with short-term benefits that will cost in the future.
Let me be transparent here. There are lots of engineering managers who have declared that they are a “blue” shop or a .Net shop or an Oracle shop. There are lots of engineering managers who really do not want to learn new tricks. It was and is my opinion that these skilled staff should be respected. However, it is my opinion that they cannot be allowed to set a course that keeps your IT program bound to your 10-40 year old infrastructure. You have to start the break-out even if it requires bold leadership.
In my next post I’ll describe how to break-out by discussing what Gartner has called Bi-Modal IT. Arc 2 represents this break-out where a couple of projects add IP to the modern side.
Soon, and sooner than you might think, you will find your staff leveraging modern services and moving business functionality from the legacy side to the modern systems. Arc 3 shows this trend. But Arc 4 is worth mentioning as well.
On the modern side are huge libraries of open sourced software. Some of this software are open source products, like PostgreSQL, which can often replace commercial products. But much of the open source software provides functions and capabilities designed to be embedded in custom applications developed by your development staff. In other words, building modern business applications is about borrowing and extending and integrating existing software services. It is not about writing from scratch. Arc 4 depicts the case where the weight and gravity of open source IP is as, or more, effective than the gravity of your legacy IP.
There you have it. Your legacy systems contain IP that can make it less expensive in the short run to stay in the legacy. In addition, you likely have staff who are comfortable in the legacy and are unwilling to move to more modern practices. They may even be in denial over the value of modern practices. The modern side has some gravity as well and as a leader you need to start moving towards modernity. Further, if you buy the argument about adoption from the last post (here), some bold leadership is required to catch up and keep up with the technology curve.
In the next post I will deviate from the original series to talk about how to get started…and then resume the original line of thinking.
About the Author: Rob Klopp is a CIO with a deep technical background. As the CIO at the Social Security Administration, Rob started and led an IT modernization program that influenced the entire Federal IT space. Before moving East, Rob held technical leadership positions at SAP, EMC, and Teradata; he consulted to several technology companies along the way. Currently, Rob is consulting to the State of California and is again helping to start initiatives to modernize legacy IT systems.