The Application
Rationalization
PLAYBOOK
An Agency Guide to Portfolio Management
Application Rationalization Playbook Page 1
Table of Contents
Table of Contents 1
Introduction to Version 1.1 3
Introduction to the Playbook 3
Key Terms 4
Disclaimer 4
A Six-Step Process for Application Rationalization 5
Step 1: Identify Needs and Conduct Readiness Assessment 7
1.1 Conduct Readiness Assessment 7
1.2 Identify Requirements 8
1.3 Develop a Questionnaire 8
Step 2: Inventory Applications 10
2.1 Send Questionnaire 10
2.2 Validate Responses 10
2.3 Create Application Onboarding Process 10
Step 3: Assess Business Value and Technical Fit 11
3.1 Review Business Value and Technical Fit Responses 11
3.2 Determine Application Dependencies 11
3.3 Identify Application Duplication 11
Step 4: Assess Total Cost of Ownership 12
4.1 Determine Current-State TCO 12
4.2 Identify Cost Outliers 13
Step 5: Score Applications 15
5.1 Develop a Consistent Scoring Methodology 15
5.2 Review Application Scores 15
5.3 Engage Program Offices for Transparency and Feedback 15
Step 6: Determine Application Placement 17
6.1 Group Applications Based on Application Scores 17
Application Rationalization Playbook Page 2
6.2 Assess Future-State TCO and Hosting Options 18
6.3 Analyze Hosting Alternatives for On-Premise Applications 18
6.4 Develop Migration Strategy and Change Management Plan 20
Conclusion 23
Appendix 24
Appendix 1 - Example Inventory Sources 24
Appendix 2 - Policies and Guidelines 24
Appendix 3 - Business Value Sample Questions 26
Appendix 4 - Technical Fit Sample Questions 28
Appendix 5 - The Application Rationalization Data Dictionary 29
Application Rationalization Playbook Page 3
Introduction to Version 1.1
The Application Rationalization Playbook is designed to be an iterative document that
evolves over time to reflect agency learning and a changing federal information technology
(IT) landscape. Since the Playbook’s original release, many agencies have kicked-off their
own application rationalization efforts, stress-tested the plays at their agencies, and
provided ample feedback and suggestions to improve the Playbook. This updated version
incorporates feedback and input based on agency experience, sharpens and clarifies
concepts, and removes redundant or unnecessary language. Specifically, there is added
focus on the principles of Organizational Change Management (OCM), new agency case
studies and lessons learned, and updates based on new Office of Management and Budget
(OMB) policy and Administration guidance. It also includes information on the Application
Rationalization Data Dictionary, which aims to help agencies strategically and systematically
identify business applications and determine which should be kept, replaced, retired, or
consolidated.
Introduction to the Playbook
This playbook is a practical guide for application rationalization and IT portfolio
management. Application rationalization is the effort to strategically identify business
applications across an organization to determine which should be kept, replaced, retired, or
consolidated. This includes developing a detailed inventory, with attributes and functionality,
determining business value and total cost of ownership (TCO), and then comparing or
rationalizing that inventory of applications as a whole to eliminate redundancies, lower
costs, and maximize efficiency. Application rationalization helps Portfolio Managers improve
their agency’s approach to IT modernization. There is no one-size-fits-all application
rationalization process, rather agencies should tailor their approach to fit mission, business,
technology, human capital, and security needs.
Application rationalization drives improved IT portfolio management capabilities, empowers
leaders to make better decisions, and enhances the delivery of key mission and business
services. Successful application rationalization efforts require buy-in from critical
stakeholders across the enterprise, including senior leaders, IT staff, cybersecurity experts,
mission and program owners, financial practitioners, acquisition and procurement experts,
and end user communities. Rationalization efforts rely on leadership support and continual
engagement with stakeholders to deliver sustainable change. This playbook provides
simplified steps that break application rationalization down into component parts and it
addresses challenges and opportunities for IT leaders approaching application rationalization
for the first time.
This playbook is designed to be iterative, and agencies are encouraged to collaborate and
share best practices and lessons learned from their own application rationalization
experiences. For more information, please join the Cloud and Infrastructure Community of
Practice (C&I CoP). To learn and engage with C&I CoP, please email the Data Center and
Cloud Optimization Initiative (DCCOI) Program Management Office (PMO) at [email protected]ov
with your request to join.
Application Rationalization Playbook Page 4
Key Terms
Definitions of key terms used throughout this document.
● Application - A software program used directly or indirectly to support the program
office in delivering on a business or mission function; includes mobile applications
● Application owner - The individual or group within the program office that directly
oversees an application
● Business value - Qualitative and quantitative measures of an application’s value
● Component - A discrete unit within a federal agency, such as a bureau or
department
● Enterprise - An entire agency, including program offices and components
● Portfolio Manager - The individual or office responsible for executing application
rationalization for the entire organization
1
● Program office - The office or organization within the agency that owns or operates
an application that delivers a business or mission function
● Technical fit - A measure of an application’s technological health
Disclaimer
This playbook was developed by the Chief Information Officer (CIO) Council and the Cloud &
Infrastructure Community of Practice (C&I CoP), with input from key federal IT practitioners
and industry representatives. This document does not provide authoritative definitions of IT
terms and should not be interpreted as official policy or mandated action. Rather, this
playbook supplements existing federal IT statutes and policies, and builds upon the key
components of the Cloud Smart
2
strategy.
1
Per FITARA and EO 13833, the CIO must be involved in ”all management, governance, and oversight processes
related to IT.” At some agencies, portfolio managers are senior members of the Office of the Chief Information
Officer (OCIO), such as the chief enterprise architect, while other agencies identify other stakeholders to lead their
application rationalization efforts. While agencies are free to include other stakeholders, the CIO, or a designee,
must be included in the process.
2
See https://cloud.cio.gov/.
Application Rationalization Playbook Page 5
A Six-Step Process for Application Rationalization
The six-step process outlined below is a structured, iterative approach to application
rationalization for IT Portfolio Managers. The six steps provide discrete actions for
agencies to consider when undergoing application rationalization. Agencies are encouraged
to tailor these steps to meet organizational structures, unique requirements, and mission
needs.
Step 1: Identify needs and conduct readiness assessment.
Work with critical stakeholders, such as the agency OCIO, to conduct an application
rationalization readiness assessment, develop the application questionnaire, and create a
baseline inventory.
Step 2: Inventory applications.
Conduct an Environmental Scan to identify applications not in the Baseline Inventory and
send the Questionnaire to the stakeholders to capture relevant data pertaining to each
application.
Step 3: Assess the business value and technical fit
For each application in the application inventory, analyze and validate business value and
technical fit data captured in the Questionnaire. Engage program offices ensure data quality.
Review the application inventory to identify dependencies and duplication.
Step 4: Assess the total cost of ownership (TCO)
Assess each application’s TCO captured in the Questionnaire. Compare TCO in the current-
state against estimated TCO in future-state architectures.
Step 5: Score applications
Based on the business value, technical fit, and TCO, score all applications and determine
whether each should be reviewed, rewarded, removed, or refreshed.
Step 6: Determine application placement
Based on the application scores, develop and execute a change management and
application migration strategy for future iterations.
Application Rationalization Playbook Page 6
Figure 1: Application Rationalization Six-Step Process
Figure 1 shows application rationalization as an ongoing best practice for good IT portfolio
management. The speed of technological change means there is constant investment in new
applications, decommissioning legacy IT, and refactoring applications to reflect changing
technology and business environments. Agencies must routinely update and rationalize their
portfolios to enable IT managers to make informed business decisions. Application
rationalization uncovers issues such as application duplication, siloed business units, and
unnecessary IT costs, so agencies can address them head-on.
Application Rationalization Playbook Page 7
Step 1: Identify Needs and Conduct Readiness
Assessment
Determine the scope and set governance for the application rationalization effort, then
develop a standardized questionnaire and templates for all resources shared with program
offices during the application rationalization effort.
1.1 Conduct Readiness Assessment
Before jumping into application rationalization, agencies should complete an application
rationalization readiness assessment.
Link to Application Rationalization Readiness Assessment Toolkit
This Readiness Toolkit leverages organizational change management (OCM) best practices
and provides templates to make the readiness assessment easy and straightforward. As
part of this readiness assessment, agencies should assign an accountable portfolio manager,
set up the application rationalization team (team) responsible for application rationalization
and IT portfolio management in the future, establish a business case for application
rationalization, engage OCIO and executive leaders from across the enterprise to ensure
buy in for the effort, and conduct an environmental scan of existing application inventories
using automated discovery tools or existing inventories as a baseline application inventory
to start from. A good place to start when developing the baseline application inventory is
with the agency's Disaster Recovery and Continuity of Operations Plans (DR/COOP), which
must take into account contingency planning and backups for critical applications and
services. An example of existing inventories can be found in Appendix 1.
OMB Software License Management Policy
OMB policy M-16-12: Improving the Acquisition and Management of Common Information
Technology: Software Licensing
3
requires agencies to appoint a software manager
responsible for managing agency-wide commercial and commercial off-the-shelf (COTS)
software service agreements and licenses. Furthermore, M-16-12 specifically mentions
Software Asset Management (SAM) tools, Software License Optimization (SLO) tools,
Continuous Diagnostics and Mitigation (CDM) tools, Continuous Monitoring as a Service
(CMaaS), network management tools, and finance and accounting systems to report on
software inventory, prices, and usage. Many agencies already have mature software
license management practices and inventories in place. Application rationalization can
leverage this work as a starting place when building the baseline application inventory.
3
OMB Memo for M-16-12 for Category Management Policy 16-1 Improving the Acquisition and Management of
Common Information Technology- Software Licensing. https://hallways.cap.gsa.gov/app/#/doclib?document=8496
Application Rationalization Playbook Page 8
1.2 Identify Requirements
Ensure the application rationalization effort aligns to current legislation, agency mission
priorities, relevant OMB policies (e.g., CPIC budget guidance, Software Category
Management), and other agency initiatives. See Appendix 2 for a list of relevant
government-wide legislation and policy. Additionally, determine the scope of the application
rationalization effort in this step of the process. Many agencies, especially large, federated
agencies, choose to down-select their initial application inventory to a component or
subcomponents to more easily manage and refine the application rationalization process.
1.3 Develop a Questionnaire
Develop a questionnaire that will be sent to each application owner in Step 2 of the
application rationalization process. The questionnaire is the primary data collection tool that
will be used to compare applications across the enterprise. The questionnaire should, at
minimum, capture business value, technical fit, and total cost of ownership (TCO) for each
application. The questionnaire should also provide clear instructions to ensure uniform
completion by respondents.
Questions related to business value should assess the following factors for each application
(See Appendix 3 for additional Business Value question examples):
● Effectiveness - the extent to which an application is a solution for the goal agencies
are trying to achieve;
● Mission criticality - the degree to which an application is critical in supporting and
executing the agencies’ mission;
● Utilization - usage data for the application. Inventory tools can help agencies
measure usage without relying solely on requirement information provided by an
application owner;
● Complexity - the customization, unique features and functions enabled by the
application. Applications with greater complexity typically require unique skills to
develop and maintain, satisfy more technically difficult requirements, or pull from
multiple data sources; and
● Usability - how easy it is for the user or customer to operate or learn.
4
Questions related to technical fit should assess the following factors for each application
(See Appendix 4 for additional Technical Fit question examples):
● Technical requirements - what levels of storage, bandwidth, data, maintenance,
and support are needed to make an application run;
● Software and hardware version control - how often is an application updated
and how much marginal effort does each update require from administrators and
4
For information on usability, use the system usability scale to measure customer experience. Visit
https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html for more information.
Application Rationalization Playbook Page 9
users;
● Dependencies and interoperability - to what degree do other applications or
systems depend on this application to run, and what disruptions in other applications
would affect it;
● Scalability and adaptability - can an application be scaled to onboard new users
and can it be augmented to fit the needs of new user groups; and
● Security standards - is an application vulnerable to security attacks and does it fit
into agency risk tolerance models.
Application Rationalization Playbook Page 10
Step 2: Inventory Applications
In Step 1 of the application rationalization process, agencies conduct a readiness
assessment, develop a questionnaire that teases out relevant application information, and
create a baseline application inventory. In Step 2 of the process, agencies deploy the
questionnaire to application owners and program offices to collect relevant information on
each in-scope application.
2.1 Send Questionnaire
Send the questionnaire to application owners or program offices for each in-scope
application. This ensures uniform and reliable data collection, allowing the team to compare
across applications.
2.2 Validate Responses
Review Questionnaire responses for completion and accuracy, then compare them with
existing inventory sources. Follow up with the application owner or program offices if there
are discrepancies between the responses provided on the questionnaire and information
from existing inventory sources. The team now has an authoritative application inventory.
2.3 Create Application Onboarding Process
Work with the relevant stakeholders within the OCIO and other program offices to ensure
new applications and services are added to the authoritative application inventory going
forward. This ensures the application inventory is continuously updated and provides value
in the future. Application rationalization is not a one-time exercise but should become part
of normal business operations within the agency.
Application Rationalization Playbook Page 11
Step 3: Assess Business Value and Technical Fit
In Step 2 of the application rationalization process, agencies inventory applications by
sending the questionnaire to each application owner and program manager, validate those
responses, and develop a process for maintaining the application inventory in the future. In
Step 3, compile the responses to the questionnaire and assess the business value and
technical fit for each application relative to all the applications in the inventory.
3.1 Review Business Value and Technical Fit Responses
The questionnaire developed in Step 1 should, at minimum, collect information related to
the business value and technical fit of each application. Often legacy applications are used
past their support horizons, which increases operating costs and the risk of security
vulnerability. Weigh the business value and technical fit responses based on unique
business and mission needs. For example, an application’s ability to perform core mission
services, such as a legislative mandate, administration priority, or leadership objective, is
often the most important factor when assessing business value and technical fit. There is no
one-size-fits all application assessment methodology.
3.2 Determine Application Dependencies
The questionnaire should determine dependencies for each application in the inventory.
Identifying upstream and downstream dependencies is critical for application rationalization
because applications with many dependencies are often more challenging and costly to
refactor, migrate, or decommission. Many systems and applications share code, databases,
and functionality. Applications with many dependencies tend to have higher business value
and applications. Although there are several commercial tools available to identify
application dependencies, not all dependencies are easily discoverable with automated tools.
Some dependencies, such as applications for training users or knowledge dependencies
cannot be readily mapped with automated tools. Therefore, the questionnaire should still be
used to validate dependencies in the application inventory.
3.3 Identify Application Duplication
Review the application inventory for duplication. If components are using different
applications to perform similar, standardized software functions, there is likely a good
business case for an enterprise solution or intra-agency shared service. It’s common for
components to be uncoordinated when purchasing applications, which leads to redundant
purchases.
Application Rationalization Playbook Page 12
Step 4: Assess Total Cost of Ownership
In Step 3 of the application rationalization process, agencies assess the business value and
technical fit of each application. Step 4 of the process builds off Step 3 and looks at each
application’s total cost of ownership (TCO). Often agencies cite TCO as the most challenging
part of application rationalization because there are often hidden or unknown costs. In this
step of the process, agencies will assess TCO information from the questionnaire, identify
cost outliers in the inventory, and provide IT investment recommendations based on agency
priorities and current spend.
4.1 Determine Current-State TCO
The questionnaire provides TCO information for each application in the inventory. Often,
agencies struggle to determine the exact cost of ownership for each application because of
hidden costs, considerations around projected future costs, depreciated value, how to
accurately account for cost savings and avoidances, convoluted service level agreements
(SLAs) and terms of service, and other unknown costs.
This playbook suggests agencies simplify the complex process of determining to the penny
the total cost of ownership for each application. Rather, the questionnaire sent to
application owners and program offices in Step 2 should prompt respondents to provide cost
estimates for their applications within given ranges. The precise cost of ownership is less
important than the approximation of that cost with the added context of the application’s
business value and technical fit all relative to the agency's mission and business priorities.
Technology Business Management (TBM) helps address some of the issues in accounting for
IT costs. TBM is a great place to start when trying to understand all the costs associated
with hosting, securing, and providing service to existing applications. However, there may
be non-IT costs that aren’t accounted for in TBM, such as costs associated with retraining or
reskilling the agency’s workforce to use new tools and applications. To learn more about
implementing TBM at your agency, please refer to the TBM Playbook found on gsa.gov.
5
5
https://tech.gsa.gov/playbooks/tbm/
Application Rationalization Playbook Page 13
Figure 2: The TBM Taxonomy
4.2 Identify Cost Outliers
Work with application owners and program offices to ensure the most accurate and
complete current-state TCO information is captured in the questionnaire, especially in the
event that outliers are identified, such as COTS business applications that far outpace the
cost per user compared to similar projects on the market and within the agency. Cost
outliers that don’t have corresponding high business value or technical fit are good
candidates for review.
Case Study: DOJ Application Rationalization Experience
In 2019, the U.S. Department of Justice (DOJ) used this playbook to pilot application
rationalization at their agency. Of the DOJ’s 26 components, DOJ selected the Antitrust
Division (ATR) to conduct the pilot and to provide the rest of the Department with lessons
learned and a roadmap for full-scale application rationalization across the DOJ. DOJ
shared those lessons with the Cloud and Infrastructure Community of Practice and some
of the lessons are included below. Overall, agencies are encouraged to tailor process steps
contained in this playbook to meet their individual agency’s needs. DOJ and ATR provided
the following lessons learned around how ATR adapted the playbook to meet ATR’s
specific application rationalization needs:
1. Define what applications are included in the inventory collection. A formalized
definition should be documented and provided to all components participating in
the application rationalization efforts to ensure all components and stakeholders
Application Rationalization Playbook Page 14
are in agreement with the scope applications in play. Furthermore, each question
in the questionnaire should have specific definitions and directions to ensure, to
the greatest extent possible, that applications are being assessed and considered
using the same methodology.
2. Streamline questions related to total cost of ownership (TCO) for simplicity and
create a standardized algorithm for calculated TCO to eliminate subjectivity and
guesswork across components and programs. ATR determined that, as currently
outlined, determining TCO for each application is prohibitively time consuming.
3. Tailor questions related to Business Value to meet agency specific needs. For ATR,
most end users are litigating attorneys who did not have availability to participate
in this effort. This made it difficult to accurately determine the Business Value for
each application as the questionnaire is currently written.
4. Include a question for applications that are hosted in a physical, on-premise
environment to determine whether they are eligible, or have been previously
considered, for migration to the cloud. ATR suggested this was a relevant data
point to determine the most appropriate future-state hosting environment for their
applications.
5. ATR estimated the level-of-effort (LOE) to distribute and collect responses for the
148 applications in their inventory to be about 200 hours total. This number
reflects ATR’s decision not to request the TCO for each application because, ATR
determined, this activity would be prohibitively time consuming.
6. ATR recommended that inventory collection and analysis should occur in an
iterative manner. The first phase gathers general information to categorize
applications, and the second phase gathers more detailed information to assess
applications’ Business Value, Technical Fit, and TCO. Following this two-phased
approach can reduce reporting burden, because some applications may not need to
provide such detailed information and can improve the quality of the data set.
7. ATR recommended DOJ should have a single system of record for the application
inventories. ATR used a single Microsoft Excel Workbook that was sent to various
ATR sub-organizations that subsequently engaged several application owners. A
single system would overcome problems related to version control, redundant
touchpoints, and data consolidation while, simultaneously, vastly simplifying the
application rationalization process.
Application Rationalization Playbook Page 15
Step 5: Score Applications
In Steps 3 and 4 of the application rationalization process, agencies assess the business
value, technical fit, and TCO for each application in their inventory based on the application
rationalization questionnaire responses. Step 5 of the process compiles this data into a
single score for each application that can be used to easily and succinctly compare
applications to each other.
5.1 Develop a Consistent Scoring Methodology
To score each application, develop a consistent scoring methodology that is applied to all
applications. This methodology should weigh factors relevant to each agencies’ specific
business and mission needs. A consistent scoring methodology ensures scores are unbiased
and clear. The case study at the end of this section goes into greater detail about how one
agency modified an existing scoring methodology to meet the agency’s needs.
5.2 Review Application Scores
Review the application scores for each application in the inventory to ensure consistency.
The application score should incorporate the business value, technical fit, and TCO factors
collected in the application rationalization questionnaire sent to application owners and
program offices. There is no single framework or template for scoring applications because
the score should be weighted based on the specific requirements and priorities of the
agency.
5.3 Engage Program Offices for Transparency and Feedback
Agencies cite clear and open communication with application owners and program teams -
throughout the application rationalization process - as a key to successful implementation
and adoption. At this point in the process, after each application owner and program office
has completed the questionnaire and provided additional information for the applications
and systems they manage, it is important to re-engage these stakeholders to make sure
they understand how the data they provided will be used. To that end, the team should:
● Develop a communications strategy that enables stakeholders to learn about the
scoring process, understand how information will be shared, and provide feedback;
● Share application scores with all program offices and application owners, to provide
transparency into how applications perform across the enterprise;
● Promote internal discussions around solutions to better meet business or technical
requirements;
● Refine the scoring methodology based on stakeholder feedback and input;
● Anticipate that some program offices will be reluctant to share information on their
Application Rationalization Playbook Page 16
applications. To mitigate resistance and promote collaboration, be proactive in
soliciting feedback from the program offices;
● Host office hours for application owners to talk to the application rationalization
team;
● Create FAQs about the scoring process and the rationale behind the questionnaire;
and
● Conduct workshops for program offices to demonstrate how to score an application,
to familiarize staff with the process.
Regular, ongoing communication can foster trust in the application rationalization process
and make stakeholders more willing to engage the team in future steps and iterations of the
application rationalization effort. The more iterative, agile, and collaborative the process,
the more likely program offices are to support the effort.
Application Rationalization Playbook Page 17
Step 6: Determine Application Placement
In Step 5 of the application rationalization process, agencies compile information related to
each application's business value, technical fit, and TCO to come up with an application
score that can be used to compare applications. Step 6 of the process incorporates relevant
information to determine the best placement for each application in the inventory
6.1 Group Applications Based on Application Scores
Group applications into the appropriate categories and develop a structured process to
assess the hosting options for each application. In the template, applications are grouped
into four categories: review, reward, refresh, or remove.
● Review - applications with low business value and high technical fit. These
applications are candidates to maintain current funding levels, explore opportunities
to enable greater business value, and consider lower-cost alternatives.
● Reward - applications with high business value and high technical fit. These
applications are candidates for increased investment, enhanced functionality, and
expanded use across the enterprise.
● Refresh - applications with high business value and low technical fit. These
applications are candidates for increased investment to ensure the same high-level
business value is delivered by more modern and secure systems.
● Remove - application with low business value and low technical fit. These
applications are good candidates to decommission or to consolidate their functions
within another application.
Figure 3, which uses dummy data, shows a visual on how applications can be scored.
Consider modifying the parameters of the scoring quadrants to best meet your agency’s
needs.
Application Rationalization Playbook Page 18
Figure 3: The application matrix. Applications with a greater TCO per user will appear as larger circles. Determine
the appropriate point to delineate between applications to review, reward, refresh, and remove based on agency
needs and available resources, and the relative sizes of each quadrant.
6.2 Assess Future-State TCO and Hosting Options
Future-state TCO is an important factor in assessing hosting options, but improved service
delivery and customer satisfaction are major goals as well. Just because a hosting option
saves money does not necessarily mean it is the option agencies should choose. Hosting
options should be compared by costs, resiliency, reliability, agility, security, and service
delivery and weighted in a manner consistent with agency business and mission goals. For
example, the agency whose primary mission involves working with classified or otherwise
sensitive information may have to weigh security considerations more heavily than other
factors. Similarly, cost may eventually become a primary consideration for agencies that
face budget constraints that would otherwise hamper their primary mission objectives.
While there is no one method of weighing these factors, the process of assigning weights
should be conducted in a transparent manner, with input from major stakeholders across
the enterprise.
6.3 Analyze Hosting Alternatives for On-Premise Applications
When migrating from an on-premise solution to a new hosting environment, there are up-
front costs associated with:
● Assessing the current-state;
● Planning for migration;
● Getting stakeholder buy-in;
● Running parallel systems;
Application Rationalization Playbook Page 19
● Vendor management;
● Training and reskilling; and
● Refactoring and replatforming existing applications if necessary.
Agencies will often experience a “migration bubble” caused by the increased up-front costs
of migrating, followed by cost savings and avoidances in the future. These cost savings can
be brought about by increased worker productivity, greater scalability, or more operational
resiliency in the new hosting environment. This establishes a new cost baseline resulting in
eventual O&M and DM&E cost savings.
Figure 4: The Migration Bubble. This figure illustrates up-front cost increases caused by running current-state and
future-state systems in parallel. While the future state shows a rebaselining of costs below the current-state costs,
the actual cost of operating future-state systems depends on how many servers and support systems can be
decommissioned or consolidated as part of the application rationalization effort and whether the future-state
hosting environment is more efficient than the current-state.
Hybrid solutions, where applications or systems are run in the cloud and on-premise
simultaneously, can greatly increase the size of this migration bubble. In such cases, the
technological solution has to be weighed against the increase in costs.
Many applications cannot be effectively lifted-and-shifted into cloud environments without
significant refactoring and modernization. Lift-and-shift is the least mature cloud migration
option, so agencies are unlikely to realize all of the benefits of cloud until they consider, for
example, a containerization or serverless model. It is important to keep in mind that beyond
a certain point, marginal improvements in service delivery from advanced cloud services
may not realize the cost savings described in Figure 3 or the benefits described above.
As automation and abstraction capabilities mature, agencies can focus more on mission and
service delivery while also streamlining their business functions. Automation can increase
productivity as staff members are freed from low-level maintenance on applications and can
spend time innovating or focusing on other high-priority issues.
Application Rationalization Playbook Page 20
6.4 Develop Migration Strategy and Change Management Plan
To achieve the benefits of application rationalization, agencies require cultural buy-in from
across the organization. Successful IT migration strategies require:
● Buy-in from senior leadership, the CIO, and the CFO to provide funds and backing for
the migration effort;
● A communications strategy to inform and continually engage stakeholders;
● A vendor management plan to ensure contracts align to migration strategy;
● A workforce development plan to help end users adapt to the new environment; and
● A migration timeline and workflow map to execute migration strategy.
Workforce development is a critical part of Cloud Smart and is essential to a successful
application rationalization and migration strategy. Agencies must not only train their staff on
how to migrate into the new environment, but they must have enough competency to use
the tools to make key decisions regarding future modernization plans. Agencies that
outsource O&M or DM&E risk losing significant institutional knowledge when contracts end
or new vendors are added.
Application Rationalization Playbook Page 21
Case Study: Application Placement
Since migrating to a new environment is both a technical and cultural challenge,
successful migration plans must account for both. A small component of a much larger
agency successfully migrated its applications to the cloud by strategically addressing
the following technical and cultural parts of migration:
● Cloud roadmap
The roadmap documented the objectives of the cloud migration effort, identified
key stakeholders, and developed a project plan to execute the migration. The
purpose of the roadmap was to document the current environment and to map
future-state vision. The component ensured all IT staff provided input on the
roadmap and briefed senior leadership to establish executive buy-in.
● Network mapping
The agency fully mapped its network topology to understand application and
data connections. This information allowed the agency to move to migrate to the
cloud environment and quickly identify the cause of service outages as they
arose. Engaging network service providers and incorporating agency’s network
experts early in the migration process were critical success factors.
● Training
Ensuring federal and vendor IT personnel could continue to support applications
in the new environment allowed the component to keep costs low because new
talent did not need to be brought in. It also increased cost savings because the
remaining component staff could take advantage of cloud benefits. The
component hosted formal training supported by vendors; ran virtual labs; and
posted information on internal chat rooms, internal blogs, and LinkedIn for
staff’s convenience, in addition to encouraging attendance at external trainings.
The component also hosted pilots with vendors where staff could experiment in
the new environment. Training was a key component in driving the cultural
changes needed for a successful migration because it demystified the cloud for
staff and gave them the confidence to operate in that new environment.
● Lift and shift, refractor, rehost
Before moving any application into the cloud, the component had to determine
which method it would use to deploy applications. Depending on their business
value, costs, and technical capabilities, the component determined that certain
applications were ready for lifting and shifting into the new environment while
Application Rationalization Playbook Page 22
others needed code updates to operate in the cloud. Because the component
recognized that different applications needed to be treated differently, the
method of delivery also required application-specific resources and planning. In
the long term, the component is going through a major system modernization
effort to update their application architecture and take better advantage of cloud
services.
The above characteristics should be captured in any agency’s migration plan. Compared
to the larger agency, the component had a smaller universe of stakeholders to
collaborate with and satisfy. This made developing and implementing the migration
simpler than an enterprise-wide migration, but the practices are still applicable to any
size organization. Constant and clear communication between the mission, IT, and
business sides of the enterprise ensures buy-in for any migration strategy and
guarantees the right information is shared, regardless of which environment an
application is moved.
Application Rationalization Playbook Page 23
Conclusion
Application rationalization is integral to portfolio management and IT modernization. The
six-step application rationalization process provides a structured approach that agencies are
encouraged to use for future portfolio management and cloud migration strategies. Agencies
that develop an authoritative application inventory will empower their leaders to make more
informed IT strategies, allow procurement offices to buy services more efficiently, and
enable users to deliver mission services to customers.
For some agencies, migrating on-premise applications to the cloud is prohibitively expensive
and does not enhance service delivery. For other agencies, the benefits of hosting
applications in cloud environments, such as increased productivity, scalability, agility, and
operational resilience, justifies the upfront costs. This playbook encourages agencies to take
a holistic view of the costs and benefits of migrating applications from on-premise to
different environments including the business value, technical fit, and TCO.
Designed to supplement the Federal Government’s Cloud Smart strategy, this playbook
reinforces the need to reskill federal employees to operate and deliver mission service in
any environment, compare security and backup costs in on-premise versus cloud
environments, and rethink procurement processes to make smarter buying decisions that
account for the TCO and work with existing CPIC guidance. Ultimately, application
rationalization is a component of a broader federal strategy to use IT and services in a way
that enables agencies to perform their missions faster and more effectively.
This playbook is intended to be a living document and is subject to future updates. Readers
are encouraged to provide feedback and engage with other IT practitioners across the
federal government. To provide feedback or learn more about potential collaboration
opportunities, email the Data Center & Cloud Optimization Initiative (DCCOI) PMO at
Agencies are encouraged to join the C&I CoP and the C&I CoP’s Application Rationalization
Working Group. The CoP is a forum for federal practitioners to collaborate with their peers
on cloud and IT infrastructure matters. The working group will serve as a dedicated space to
add to this playbook and to discuss other relevant application rationalization matters. C&I
CoP meetings are held on the first Wednesday of each month, except in August and
January. For more information on the C&I CoP, the Application Rationalization Working
Group, and to learn how to join either, email [email protected]v.
Application Rationalization Playbook Page 24
Appendix
Appendix 1 - Example Inventory Sources
Example inventory sources include:
● Capital Planning and Investment Control Reports (such as those submitted to OMB);
● Financial Reporting Tools;
● Authorization to operate lists & management tools;
● Cybersecurity assessment and management tools;
● Software license optimization (SLO) tools and inventories;
● Configuration management database (CMDB) tools;
● Continuous Diagnostics and Mitigation (CDM) tools;
● Continuity of Operations Plans (COOP) and disaster recovery (DR) plans;
● Data Center Infrastructure Management (DCIM) tools;
● Data management systems;
● Hardware tracking systems;
● Licenses and service level agreements;
● Security operations tools;
● Software asset management (SAM) Tools; and
● Virtualization management systems.
Appendix 2 - Policies and Guidelines
Below is a list of official policies and guidelines that can impact how agencies determine
their requirements in developing an application rationalization strategy.
Short Title and Link
Full Title
PMA
The President’s Management Agenda
MEGABYTE Act
Making Electronic Government Accountable By Yielding Tangible
Efficiencies Act of 2016 or the MEGABYTE Act of 2016
FITARA
Federal Information Technology Acquisition Reform Act
FITARA Scorecard
House Committee on Oversight and Government Reform (OGR)
Biannual IT Scorecard (See page 6)
FITARA Guidance
Templates, resources, and guidance to help agencies implement
FITARA
CAP Goals
Cross-Agency Priority Goals
FY20 IT Budget -
Capital Planning
Guidance
FY20 IT Budget - Capital Planning Guidance
Application Rationalization Playbook Page 25
Short Title and Link
Full Title
OMB Circular A-130
Managing Information as a Strategic Resource (See Appendix II:
Responsibilities for Managing Personally Identifiable
Information)
M-15-14
Management and Oversight of Federal Information Technology
M-16-02
Category Management Policy 15-1: Improving the Acquisition
and Management of Common Information Technology: Laptops
and Desktops
M-16-12
Category Management Policy 16-1: Improving the Acquisition
and Management of Common Information Technology: Software
Licensing
M-16-21
Federal Source Code Policy: Achieving Efficiency, Transparency,
and Innovation through Reusable and Open Source Software
M-17-22
Comprehensive Plan for Reforming the Federal Government and
Reducing the Federal Civilian Workforce
M-18-23
Shifting From Low-Value to High-Value Work
M-19-26
Update to the Trusted Internet Connections (TIC) Initiative
Application Rationalization Playbook Page 26
Appendix 3 - Business Value Sample Questions
● What problem was this application designed to address?
● List the business process(es) this application supports (e.g., quarterly reporting to
OMB, internal project management, order management transaction processing).
● When was this application originally developed?
● Who is paying for this application and how is it being funded?
● Which department business lines are using this application and where are they
located?
● Is this application used by customers outside of the department?
● What is the application's average annual utilization?
● Does the information within this application need to be kept and stored? If so, for
how long?
● Does the capability/functionality exist within another application? If yes, provide the
name of the application(s). If no, reply None.
● How are you training new users of the application?
● What is the strategic direction of this application? Is there documentation for this
plan?
● What is the importance of the application to the user’s duties?
● How satisfied are you with the features of the application?
● How satisfied are you with the usability of the application?
● What effect would a 24-hour, unplanned outage of this application have on your
organization?
● How well does this application meet its intended business requirements?
● Is this application an authoritative source/Exclusive Record of Origin (ROO) for the
data it stores?
● Does this application have security controls in place?
● Does this application have redundancies in place to ensure continuity of operations?
● Does this application interface with and/or depend upon other applications?
● Is the application stack aligned with supported versions, or do parts of the
application depend on obsolete technology?
● Does the application have maintenance issues that affect business operations?
● Is the application flexible and able to meet changing business requirements?
● Does this application require specialized expertise to maintain?
● Can this application quickly scale to handle greater transaction volumes and support
additional users (internal or external to your organization)?
Application Rationalization Playbook Page 27
● What impact does upgrading the application software version have on other
components of the application (e.g., custom features, permissions, etc.)?
● What is the timeline for this application to be sunsetted or retired?
● Can the application be moved to and run in a cloud efficiently?
● Does the application developer use the following modern development practices
(e.g., Continuous Development/Continuous Integration; Configuration as Code;
Version Control; Automated Testing; Agile, [including Scrum, Lean, SAFe])?
● How much data does this application store?
Application Rationalization Playbook Page 28
Appendix 4 - Technical Fit Sample Questions
● What office or component is responsible for the application’s IT
support/administration?
● List all contractor companies that support this application.
● Who is hosting this application? Is this application in the cloud?
● How many change requests do you receive per year?
● Does this application receive information from other applications?
● Does this application send information to other applications?
● What licenses are associated with the use of this application (if applicable)?
● Does this application have a valid ATO?
● Is the application web enabled? If yes, provide the URL.
● Is this application mobile enabled?
● How do users access/log in to this application?
● What databases does the application use?
● What reporting and analysis (BI) technology does the application use?
● What application and/or web server does the application use?
● What programming languages does the application use?
● What operating systems does the application use?
Application Rationalization Playbook Page 29
Appendix 5 - The Application Rationalization Data
Dictionary
The Application Rationalization Data Dictionary is a supplement to the Application
Rationalization Playbook to help agencies strategically and systematically identify business
applications and determine which should be kept, replaced, retired, or consolidated. This
resource establishes standards for data exchanges designed to manage application
rationalization. Utilizing input from interagency stakeholders in the federal IT community, it
establishes a data taxonomy and defines a technical schema for machine-readable data
interchanges. Agencies are encouraged to use Application Rationalization Data Dictionary in
tandem with current-state portfolio assessments to align IT assets with modernization
priorities, and to share best practices and lessons learned from their own application
rationalization.
For more information, please visit the GitHub repository, which includes the data dictionary,
technical schema, test data, and ReadMe.
