The federal government maintains some IT systems that are over 50 years old and replaces others with ground-up rewrites after 5 years. There are always trade-offs to be made, but some approaches better fit the uniquely long-lived missions that are served by federal IT systems.
At a certain point, a whole-sale rewrite is the best option for replacing the stale, decaying software that leads to major headaches and eventual catastrophe. Big rewrites have big risks and big failures. Because of the stability and enduring mandates of the federal government, long-term investments in IT systems pay off and give room for smart maintenance strategies.
Rather than engaging in an intense modernization effort following by years of minimal maintenance, a better alternative often is modernizing a system continuously, balancing operations, maintenance, and renovation. Ideally you can improve, update, and upgrade the software system one piece at a time while it continues to operate, avoiding feature freezes and scary cut-overs.
Slides from presentation given at the NDIA Agile in Government Summit 2019: https://ndia.dtic.mil/2019/agile/2019agile.html
2. excella.com | @excellaco
Long-Lived Federal IT Systems
Federal IT systems include critical enterprise
functions:
• System of record
• Implementation of mandate
• Accomplishing the mission
These frequently evolve over time, but rarely go away.
3. excella.com | @excellaco
Long-Lived Federal IT Systems
Federal IT systems include critical enterprise
functions:
• System of record
• Implementation of mandate
• Accomplishing the mission
These frequently evolve over time, but rarely go away.
4. excella.com | @excellaco
Long-Lived Federal IT Systems
Federal IT systems include critical enterprise
functions:
• System of record
• Implementation of mandate
• Accomplishing the mission
These frequently evolve over time, but rarely go away.
10. excella.com | @excellaco
Long-Lived Federal IT Systems
Federal systems serve uniquely long-lived missions.
Short-term thinking often leads to risks and waste
that have long-term consequences.
11. excella.com | @excellaco
Long-Lived Federal IT Systems
Federal systems serve uniquely long-lived missions.
Short-term thinking often leads to risks and waste
that have long-term consequences.
26. excella.com | @excellaco
Technical debt is a metaphor for the shortcuts,
onerous designs, and outdated technology that make
modifying the system difficult and risky.
Like financial debt it compounds and accumulates
over time and has ongoing costs until it is paid off.
Technical Debt
27. excella.com | @excellaco
Technical debt is a metaphor for the shortcuts,
onerous designs, and outdated technology that make
modifying the system difficult and risky.
Like financial debt it compounds and accumulates
over time and has ongoing costs until it is paid off.
Technical Debt
28. excella.com | @excellaco
Technical debt is a metaphor for the shortcuts,
onerous designs, and outdated technology that make
modifying the system difficult and risky.
Like financial debt it compounds and accumulates
over time and has ongoing costs until it is paid off.
Technical Debt
39. excella.com | @excellaco
Technical debt is worse than financial debt.
• Not fungible; unique to the system.
• Cannot outrun; must fix or replace.
• Does not have predictable costs.
It is compounding risk.
Technical Debt
40. excella.com | @excellaco
Technical debt is worse than financial debt.
• Not fungible; unique to the system.
• Cannot outrun; must fix or replace.
• Does not have predictable costs.
It is compounding risk.
Technical Debt
41. excella.com | @excellaco
Technical debt is worse than financial debt.
• Not fungible; unique to the system.
• Cannot outrun; must fix or replace.
• Does not have predictable costs.
It is compounding risk.
Technical Debt
42. excella.com | @excellaco
Technical debt is worse than financial debt.
• Not fungible; unique to the system.
• Cannot outrun; must fix or replace.
• Does not have predictable costs.
It is compounding risk.
Technical Debt
43. excella.com | @excellaco
Technical debt is worse than financial debt.
• Not fungible; unique to the system.
• Cannot outrun; must fix or replace.
• Does not have predictable costs.
It is compounding risk.
Technical Debt
45. excella.com | @excellaco
The bad
old system full of
technical debt.
Legacy
System
Legacy Modernization
Modernization Modern
System
46. excella.com | @excellaco
The bad
old system full of
technical debt.
Legacy
System
Legacy Modernization
Modernization
The replacement
that will make all
of our dreams
come true.
Modern
System
47. excella.com | @excellaco
The bad
old system full of
technical debt.
Legacy
System
Legacy Modernization
Modernization
The replacement
that will make all
of our dreams
come true.
Modern
System
48. excella.com | @excellaco
The bad
old system full of
technical debt.
Legacy
System
Legacy Modernization
Modernization
The replacement
that will make all
of our dreams
come true.
Modern
System
95. excella.com | @excellaco
• Long-term investment
• In daily use
• Needs maintenance
• Renovate as needed
• Make it safe to renovate with girders, braces,
shoring, & jacks
The “Home” Metaphor
96. excella.com | @excellaco
It is one thing to build a new house, but to build a
new house in the same exact spot?
The “Home” Metaphor
98. excella.com | @excellaco
The “Home” Metaphor
This is critical to
the enterprise.
Moving out for a
year is a costly
and risky option.
Live On-Site
99. excella.com | @excellaco
The “Home” Metaphor
This is critical to
the enterprise.
Moving out for a
year is a costly
and risky option.
Live On-Site Maintain
Prevention over
cure. Don’t save
money now at
the risk of
catastrophe later.
100. excella.com | @excellaco
The “Home” Metaphor
This is critical to
the enterprise.
Moving out for a
year is a costly
and risky option.
Live On-Site Maintain
Drastic changes
may include
remodeling,
additions, and
major retrofitting.
Renovate
Prevention over
cure. Don’t save
money now at
the risk of
catastrophe later.
101. excella.com | @excellaco
Demolition and rebuilding may be the right option,
although usually because of unaddressed
deterioration.
The “Home” Metaphor
102. excella.com | @excellaco
Demolition and rebuilding may be the right option,
although usually because of unaddressed
deterioration.
The “Home” Metaphor
103. excella.com | @excellaco
Demolition and rebuilding may be the right option,
although usually because of unaddressed
deterioration.
The “Home” Metaphor
106. excella.com | @excellaco
Maintain & Renovate
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
107. excella.com | @excellaco
Maintain & Renovate
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
108. excella.com | @excellaco
Maintain & Renovate
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
109. excella.com | @excellaco
Maintain & Renovate
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
110. excella.com | @excellaco
Maintain & Renovate
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
111. excella.com | @excellaco
Technical Debt is a huge topic.
• Lack of process or understanding
• Tightly-coupled components
• Lack of a test suite
• Lack of documentation
• Lack of collaboration
• Parallel development
• Delayed refactoring
• Lack of alignment to standards
• Lack of knowledge
• Lack of ownership
• Poor technological leadership
“As an evolving program is continually changed, its
complexity, reflecting deteriorating structure, increases
unless work is done to maintain or reduce it.”
— Meir Manny Lehman, 1980
Reduce Technical Debt
112. excella.com | @excellaco
Technical Debt is a huge topic.
• Lack of process or understanding
• Tightly-coupled components
• Lack of a test suite
• Lack of documentation
• Lack of collaboration
• Parallel development
• Delayed refactoring
• Lack of alignment to standards
• Lack of knowledge
• Lack of ownership
• Poor technological leadership
“As an evolving program is continually changed, its
complexity, reflecting deteriorating structure, increases
unless work is done to maintain or reduce it.”
— Meir Manny Lehman, 1980
Reduce Technical Debt
113. excella.com | @excellaco
Technical Debt is a huge topic.
• Lack of process or understanding
• Tightly-coupled components
• Lack of a test suite
• Lack of documentation
• Lack of collaboration
• Parallel development
• Delayed refactoring
• Lack of alignment to standards
• Lack of knowledge
• Lack of ownership
• Poor technological leadership
“As an evolving program is continually changed, its
complexity, reflecting deteriorating structure, increases
unless work is done to maintain or reduce it.”
— Meir Manny Lehman, 1980
Reduce Technical Debt
114. excella.com | @excellaco
Technical Debt is a huge topic.
• Lack of process or understanding
• Tightly-coupled components
• Lack of a test suite
• Lack of documentation
• Lack of collaboration
• Parallel development
• Delayed refactoring
• Lack of alignment to standards
• Lack of knowledge
• Lack of ownership
• Poor technological leadership
“As an evolving program is continually changed, its
complexity, reflecting deteriorating structure, increases
unless work is done to maintain or reduce it.”
— Meir Manny Lehman, 1980
Reduce Technical Debt
115. excella.com | @excellaco
Technical Debt is a huge topic.
• Lack of process or understanding
• Tightly-coupled components
• Lack of a test suite
• Lack of documentation
• Lack of collaboration
• Parallel development
• Delayed refactoring
• Lack of alignment to standards
• Lack of knowledge
• Lack of ownership
• Poor technological leadership
“As an evolving program is continually changed, its
complexity, reflecting deteriorating structure, increases
unless work is done to maintain or reduce it.”
— Meir Manny Lehman, 1980
Reduce Technical Debt
118. excella.com | @excellaco
• Every piece of work should result in equal or
reduced technical debt.
• Boy Scout Rule: leave it better than you found it.
• Refactor as you go.
• Fix defects ASAP.
Stop the Bleeding
119. excella.com | @excellaco
• Every piece of work should result in equal or
reduced technical debt.
• Boy Scout Rule: leave it better than you found it.
• Refactor as you go.
• Fix defects ASAP.
Stop the Bleeding
120. excella.com | @excellaco
• Every piece of work should result in equal or
reduced technical debt.
• Boy Scout Rule: leave it better than you found it.
• Refactor as you go.
• Fix defects ASAP.
Stop the Bleeding
121. excella.com | @excellaco
• Every piece of work should result in equal or
reduced technical debt.
• Boy Scout Rule: leave it better than you found it.
• Refactor as you go.
• Fix defects ASAP.
Stop the Bleeding
123. excella.com | @excellaco
• Software development teams usually feel
pressure to deliver new functionality rapidly, both
explicit and implicit.
• Paying down technical debt, including major re-
writes, should be supported, rewarded, and
celebrated.
• Educate stakeholders about the effort: these
systems are long-term investments.
Create Time and Space
124. excella.com | @excellaco
• Software development teams usually feel
pressure to deliver new functionality rapidly, both
explicit and implicit.
• Paying down technical debt, including major re-
writes, should be supported, rewarded, and
celebrated.
• Educate stakeholders about the effort: these
systems are long-term investments.
Create Time and Space
125. excella.com | @excellaco
• Software development teams usually feel
pressure to deliver new functionality rapidly, both
explicit and implicit.
• Paying down technical debt, including major re-
writes, should be supported, rewarded, and
celebrated.
• Educate stakeholders about the effort: these
systems are long-term investments.
Create Time and Space
126. excella.com | @excellaco
• Software development teams usually feel
pressure to deliver new functionality rapidly, both
explicit and implicit.
• Paying down technical debt, including major re-
writes, should be supported, rewarded, and
celebrated.
• Educate stakeholders about the effort: these
systems are long-term investments.
Create Time and Space
127. excella.com | @excellaco
Adding test coverage, applying updates, and
rewriting portions of the code should be celebrated
as much as adding new functionality.
• Metrics that emphasize adding functionality, such
as the usual velocity charts, are dangerous.
• Imagine if bridge infrastructure was only
measured by number of miles added!
Create Time and Space
128. excella.com | @excellaco
• Adding test coverage, applying updates, and
rewriting portions of the code should be
celebrated as much as adding new functionality.
• Metrics that emphasize adding functionality, such
as the usual velocity charts, are dangerous.
• Imagine if bridge infrastructure was only
measured by number of miles added!
Create Time and Space
129. excella.com | @excellaco
• Adding test coverage, applying updates, and
rewriting portions of the code should be
celebrated as much as adding new functionality.
• Metrics that emphasize adding functionality, such
as the usual velocity charts, are dangerous.
• Imagine if bridge infrastructure was only
measured by number of miles added!
Create Time and Space
130. excella.com | @excellaco
• Adding test coverage, applying updates, and
rewriting portions of the code should be
celebrated as much as adding new functionality.
• Metrics that emphasize adding functionality, such
as the usual velocity charts, are dangerous.
• Imagine if bridge infrastructure was only
measured by number of miles added!
Create Time and Space
131. excella.com | @excellaco
Adding test coverage, applying updates, and
rewriting portions of the code should be celebrated
as much as adding new functionality.
Metrics that emphasize adding functionality, such as
the usual velocity charts, are dangerous.
• Imagine if bridge infrastructure was only
measured by number of miles added!
Create Time and Space
132. excella.com | @excellaco
• Imagine if bridge infrastructure was only
measured by number of miles added!
If you target a metric, you will likely improve it,
although at some cost elsewhere.
I want to drive on bridges where the key metric is
on-time inspection and maintenance.
Create Time and Space
133. excella.com | @excellaco
• Imagine if bridge infrastructure was only
measured by number of miles added!
• If you target a metric, you will likely improve it,
although at some cost elsewhere.
I want to drive on bridges where the key metric is
on-time inspection and maintenance.
Create Time and Space
134. excella.com | @excellaco
• Imagine if bridge infrastructure was only
measured by number of miles added!
• If you target a metric, you will likely improve it,
although at some cost elsewhere.
• I want to drive on bridges where the key metric is
on-time inspection and maintenance.
Create Time and Space
135. excella.com | @excellaco
How can we support software caretakers as they
maintain the system and do high-quality work, but
produce less new functionality?
Just do it.
Inspect the code and create metrics around
maintenance to be done.
Set aside time & capacity for maintenance.
Track maintenance and refactors the same as
PBIs/User Stories/etc.
Create Time and Space
136. excella.com | @excellaco
How can we support software caretakers as they
maintain the system and do high-quality work, but
produce less new functionality?
• Just do it.
Set aside time & capacity for maintenance.
Track maintenance and refactors the same as
PBIs/User Stories/etc.
Inspect the code and create metrics around
maintenance to be done.
Create Time and Space
137. excella.com | @excellaco
How can we support software caretakers as they
maintain the system and do high-quality work, but
produce less new functionality?
• Just do it.
• Set aside time & capacity for maintenance.
Track maintenance and refactors the same as
PBIs/User Stories/etc.
Inspect the code and create metrics around
maintenance to be done.
Create Time and Space
138. excella.com | @excellaco
How can we support software caretakers as they
maintain the system and do high-quality work, but
produce less new functionality?
• Just do it.
• Set aside time & capacity for maintenance.
• Track maintenance and refactors the same as
PBIs/User Stories/etc.
Inspect the code and create metrics around
maintenance to be done.
Create Time and Space
139. excella.com | @excellaco
How can we support software caretakers as they
maintain the system and do high-quality work, but
produce less new functionality?
• Just do it.
• Set aside time & capacity for maintenance.
• Track maintenance and refactors the same as
PBIs/User Stories/etc.
• Inspect the code and create metrics around
maintenance to be done.
Create Time and Space
141. excella.com | @excellaco
Psychological safety: re-writes can be risky.
Risks can be reduced in many ways.
Learn about them and use what makes sense.
Testing, especially automated testing, is huge.
Blue/green deployments & shadowing (running new
code in parallel with the old) can be even more
effective.
Ensure Safety
142. excella.com | @excellaco
• Psychological safety: re-writes can be risky.
Risks can be reduced in many ways.
Learn about them and use what makes sense.
Testing, especially automated testing, is huge.
Blue/green deployments & shadowing (running new
code in parallel with the old) can be even more
effective.
Ensure Safety
143. excella.com | @excellaco
• Psychological safety: re-writes can be risky.
• Risks can be reduced in many ways.
Learn about them and use what makes sense.
Testing, especially automated testing, is huge.
Blue/green deployments & shadowing (running new
code in parallel with the old) can be even more
effective.
Ensure Safety
144. excella.com | @excellaco
• Psychological safety: re-writes can be risky.
• Risks can be reduced in many ways.
Learn about them and use what makes sense.
• Testing, especially automated testing, is huge.
Blue/green deployments & shadowing (running new
code in parallel with the old) can be even more
effective.
Ensure Safety
145. excella.com | @excellaco
• Psychological safety: re-writes can be risky.
• Risks can be reduced in many ways.
Learn about them and use what makes sense.
• Testing, especially automated testing, is huge.
• Blue/green deployments & shadowing (running
new code in parallel with the old) can be even
more effective.
Ensure Safety
172. excella.com | @excellaco
Continuous Modernization
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
173. excella.com | @excellaco
Continuous Modernization
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
174. excella.com | @excellaco
Continuous Modernization
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.
175. excella.com | @excellaco
Continuous Modernization
Treat long-lived Federal IT systems like homes.
Avoid demolition and rebuilding.
Pay down technical debt.
Steadily invest in modernizing the system.