The American Council for Technology (ACT) and Industry Advisory Council (IAC), collectively known as ACT-IAC, released a white paper in October aimed at helping the Federal Government address the challenges associated with modernizing legacy systems. To provide a sense of the scale of the modernization need and why ACT-IAC tackled this issue, according to the paper, “Of the $52 billion in Federal civilian IT spending planned for fiscal year 2017, approximately 71% ($37 billion) is classified as “legacy” IT spending.”
That’s big money with the potential for big benefits if we can improve our modernization efforts even a little.
I found some highlights in the paper, such as the emphasis on change management and communication, many of the “Keys to Successful Modernization” in the executive summary, and the U.S. Army Total Ammunition Management Information System (TAMIS) case study at the very end.
I’d also like to suggest some changes and additions to the paper in the interest of helping our government get better outcomes with its legacy system modernization efforts.
1. Modernization is a Continuous Activity — Not a Project That Starts and Stops.
Tell me if you’ve heard this story before. You’re responsible for a legacy system with outdated, unsupported technologies and you’re having a hard time responding to the business needs. So you decide to modernize. You select the architecture and technology stack you’d like to use and wait for approval. You make the business case for modernization and wait for approval. You wait for funding. You conduct a solicitation and wait for award. You finally start working to modernize the system with the architecture and technology stack you selected… three years ago. Meanwhile, the technical and architectural state of the art has passed you by and by the time you’re done with the modernization effort, it’s time for another modernization. The cycle repeats. This is the effect of a project-based approach to modernization.
Successful modernization is a continuous activity — changing the architecture, technology stack, and the business process iteratively and incrementally. Adrian Cockcroft, one of the leaders in the DevOps movement, said, “Do painful things more frequently, so you can make it less painful.” This principle applies to modernization, just like it applies to releases, deployments, testing, security, and every other painful thing associated with IT.
2. Make Value a (the) Primary Driver, Instead of Just Cost and Risk
The paper describes various modernization strategies and tactics and how they can reduce risk and cost. In fact, the paper infers in many places that driving down risk and cost are the primary reasons for modernization. I’d like to see more emphasis on increasing value as the driver for modernization. To be fair, this point does show up in spots, such as with the mention of increased agility and digitization. With modernization, there is an opportunity to reexamine what you do and how you do it — and even why you do it. If risk and cost are steering the ship, you’re at risk of paving cow paths and putting lipstick on pigs.
3. Emphasize Agility Over Planning
There is a trend in the Federal Government toward more agile approaches to IT, especially over the last five or six years. The paper has some “agility” language in it, such as in a couple of the “Keys to Successful Modernization” (e.g., #3, #7) in the executive summary. However, the paper also advocates a “Modernization Lifecycle” with significant up-front inventory, assessment, roadmap, and planning activities. Those activities hurt agility and are hallmarks of a waterfall approach that actually increase risk and cost.
We should be building agility by embracing the principles and mindsets associated with the Agile Manifesto, The Lean Startup’s Build, Measure, Learn cycle, Deming’s Plan-Do-Check-Act (PDCA) loop, and the DevOps movement. To get the best results from our modernization efforts, we don’t need to inventory, assess, or plan more. (Notice I didn’t say we didn’t need to do them at all.) To get the best results, we do need more agility.
4. Describe Architectural Patterns and Practices for Modernization
In the “Digitization through Modernization” section, the paper states, “Organizations can start by decomposing existing systems and breaking them into discrete components. This is far less disruptive than completely replacing an existing core legacy system, and it allows organizations to create new channels at scale. Additionally, gradual integration can be a less disruptive and easier approach to modernization than wholesale change.” Agreed! And this approach has a name: microservices. The use of microservices is an architectural practice that helps teams move fast without being dependent on one another. Yet microservices only got one minor mention in the paper. I think it deserved more attention given how important it is to agility.
There are also patterns to help guide modernization efforts. Patterns are general, reusable solutions to commonly occurring problems. They’re extremely helpful when trying to figure out how best to modernize complicated, highly coupled legacy systems. A couple patterns from Martin Fowler come to mind, like Strangler Application and Branch by Abstraction.
5. Address culture and its importance.
It’s tough to be successful with a modernization effort in an environment where cooperation is low, risk-taking is discouraged, and failure is punished. Peter Drucker, the famed management guru, said, “Culture eats strategy for breakfast.” The culture of an organization has a tremendous influence on the success (or lack thereof) of high change, high impact activities — like legacy system modernizations in the Federal Government. Using Dr. Ron Westrum’s culture typology, the Federal Government is the stereotypical bureaucracy at best, and pathological at worst. The Federal Government has few examples of Westrum’s generative culture — the culture that supports the best organizational outcomes.
The Federal Government needs to change its approach to modernization or it will find itself in the same position years from now — still relying “on decades-old, obsolete technologies to support critical mission programs, essential functions, and daily operations” and still failing to get the most value out of its IT systems. The only thing that will be different will be that the “decades-old, obsolete technologies” will be the ones it selects today.
None of these changes will be easy to accomplish. There are all sorts of policy, people, process, and technology challenges to overcome. But I believe these changes are necessary.