CGI ETSNext Financial Management Strategy Options 12-9-22 Final-Revised-1.pdf

Confidential

Financial Management Interface/ Integration Strategy for E-Gov Travel Services (ETS) Next Generation Service (ETSNext)

Financial Management Strategy Options FINAL - Revised

December 7, 2022

Delivered by CGI Federal

FINAL - Revised | Financial Management Strategy Options |

Confidential 1

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

Contents

1 Introduction ___________________________________________________________ 4

1.1 Objectives of FM Strategy Options Deliverable _______________________________________ 5

1.2 Document Organization _________________________________________________________ 5

2 Application Program Interface (API) Strategy (SOW 3.5.2) _____________________ 7

2.1 Technical Strategy _____________________________________________________________ 7

2.1.1 Decentralized with Multiple Travel Vendors __________________________________________ 7

2.2 Architecture Considerations ______________________________________________________ 8

2.2.1 Agencies Adopting ETSNext in a Centralized Delivery Model ____________________________ 8

2.2.2 Agencies Adopting ETSNext in a Decentralized Delivery Model _________________________ 10

2.3 Considerations for Centralized vs Decentralized and Single vs Multiple Travel Vendors ______ 10

2.3.1 Decentralized with a Single Travel Vendor _________________________________________ 10

2.3.2 Centralized (Single Travel Vendor) _______________________________________________ 11

2.3.3 Centralized (Multiple Travel Vendors) _____________________________________________ 11

2.4 Other Considerations __________________________________________________________ 11

2.4.1 Cloud vs On Premise __________________________________________________________ 11

2.4.2 Timeline ____________________________________________________________________ 11

2.4.3 Talent ______________________________________________________________________ 12

2.4.4 COTS vs Custom _____________________________________________________________ 12

2.4.5 Product vs Open Source _______________________________________________________ 12

3 Feasibility and Value of Incorporating an Integration Platform (SOW 3.5.3) ______ 13

4 Phased Approach (SOW 3.5.4) ___________________________________________ 15

5 Investment Assessment (SOW 3.5.5) _____________________________________ 18

5.1 Assessment of Leveraging DOD GEX Approach _____________________________________ 18

5.2 Assessment of Leveraging FM QSMO Approach ____________________________________ 18

5.2.1 Assessment of Ability to Leverage FM QSMO Investment _____________________________ 19

5.2.2 Assessment of Ability to Leverage FM QSMO Approach_______________________________ 20

5.2.3 Assessment of Ability to Leverage FM QSMO Lessons Learned ________________________ 20

6 Governance (SOW 3.5.6) ________________________________________________ 23

6.1 ETSNext Proposed Governance Bodies ___________________________________________ 25

6.1.1 GSA ETSNext Program Office ___________________________________________________ 25

Confidential 2

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

6.1.2 ETSNext Change Control Management Board (CCMB) _______________________________ 25

6.2 Definition of Roles and Responsibilities ____________________________________________ 26

7 Cost-Benefit Analysis (SOW 3.5.7) _______________________________________ 28

7.1 Centralized Benefits ___________________________________________________________ 28

7.1.1 GSA Benefits ________________________________________________________________ 28

7.1.2 Agency Benefits ______________________________________________________________ 28

7.2 Decentralized Benefits _________________________________________________________ 29

7.2.1 GSA Benefits ________________________________________________________________ 29

7.2.2 Agency Benefits ______________________________________________________________ 29

7.3 Cost Attributes _______________________________________________________________ 30

7.3.1 Centralized Model with a Single Travel Vendor ______________________________________ 30

7.3.1.1 GSA Costs of a Centralized Model with a Single Vendor_______________________________ 31

7.3.1.2 Agency Costs of a Centralized Model with a Single Vendor ____________________________ 31

7.3.2 Centralized Model with Multiple Travel Vendors _____________________________________ 32

7.3.2.1 GSA Costs for a Centralized Model with Multiple Travel Vendors ________________________ 32

7.3.2.2 Agency Costs for a Centralized Model with Multiple Travel Vendors ______________________ 32

7.3.3 Decentralized Model with a Single Travel Vendor ____________________________________ 33

7.3.3.1 GSA Costs for a Decentralized Model with a Single Travel Vendor ______________________ 33

7.3.3.2 Agency Costs for a Decentralized Model with a Single Travel Vendor ____________________ 33

7.3.4 Decentralized with Multiple Travel Vendors _________________________________________ 34

7.3.4.1 GSA Costs for a Decentralized Model with Multiple Travel Vendors ______________________ 34

7.3.4.2 Agency Costs for a Decentralized Model with Multiple Travel Vendors ____________________ 34

7.4 Cost Estimate WBS Reference List _______________________________________________ 34

7.5 Centralized Cost Estimates and Analysis ___________________________________________ 36

7.6 Decentralized Cost Estimates and Analysis _________________________________________ 40

7.7 Summary of Centralized vs Decentralized Cost Estimates _____________________________ 42

8 Risk Analysis and Mitigation Recommendations (SOW 3.5.8) _________________ 44

8.1 Centralized Risks _____________________________________________________________ 44

8.2 Key Risk Attributes in a Centralized Model _________________________________________ 44

8.2.1 Centralized with a Single Travel Vendor ___________________________________________ 44

8.2.2 Centralized with Multiple Travel Vendors ___________________________________________ 46

8.3 Decentralized Risks ___________________________________________________________ 47

8.4 Key Risk Attributes in a Decentralized Model _______________________________________ 48

8.4.1 Decentralized with a Single Travel Vendor _________________________________________ 48

Confidential 3

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

8.4.2 Decentralized with Multiple Travel Vendors _________________________________________ 49

8.5 Cost Risk Analysis with Risk Drivers ______________________________________________ 49

8.6 Risk Summary _______________________________________________________________ 51

9 Notional Schedule/ Key Tasks (SOW 3.5.9) _________________________________ 53

9.1 Plan and Schedule ____________________________________________________________ 53

9.1.1 Pre-Award Transition __________________________________________________________ 53

9.1.2 Post-Award Interface/Integration Development ______________________________________ 54

10 Appendix ____________________________________________________________ 55

10.1 Updated Initial Assessments Document ____________________________________________ 55

10.2 Updated BIE Analysis Spreadsheet _______________________________________________ 55

10.3 FM QSMO Data Management Lessons Learned _____________________________________ 55

10.4 Cost Risk Analysis Appendix ____________________________________________________ 55

10.5 MITRE Study Referenced (Related to Risks) ________________________________________ 56

11 Next Steps ___________________________________________________________ 57

Confidential 4

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

1 Introduction

GSA’s Federal Acquisition Service, Office of Travel, Employee Relocation, and Transportation partnered with CGI

Federal (CGI) to provide federal financial management (FM) process, policy, and technology expertise to validate that GSA has a clear path forward for how they will transition to E-Gov Travel Services (ETS) Next Generation

Service (ETSNext). GSA has been collaborating with Treasury’s Office of Financial Innovation and Transformation

(FIT), the FM Standards Committee Working Group, and the FM Quality Service Management Office (QSMO) to create viable, easy to follow standards that will improve travel and expense (T&E) to FM integration services for travelers, agencies, and GSA oversight. While this collaboration will continue, the recent task was to develop an updated T&E standards repository and agree on the T&E to FM data exchange processes, data element mapping, transaction sets, and business rules. This initial three-month phase of the ETSNext project focused on obtaining agency impacts of the new standards and validating the latest Travel, Relocation, and Transportation Federal

Financial Management Business Information Exchange (TRT-FFM BIE) to confirm Executive Branch agencies will be able to prepare for, update, and conform to the standards upon ETSNext’s implementation.

As stated in the Initial Assessment deliverable, accepted by GSA on September 30, 2022, the first part of this base contract was to provide an initial assessment of a validation process for the standards. Interviews were conducted with the following nine (9) agencies:

• Treasury Bureau of Fiscal Services (BFS) Administrative Resource Center (ARC)

• Department of Transportation/Federal Aviation Administration (DOT/FAA)

• U.S. Department of Agriculture (USDA)

• Department of Homeland Security (DHS) Customs and Border Patrol (CBP)

• Department of Justice (DOJ)

• Department of Labor (DOL)

• Department of State (DOS)

• General Services Administration (GSA)

• Department of Veterans Affairs (VA)

Note: Department of Homeland Security (DHS) Immigration and Customs Enforcement (ICE) was part of the original list of agencies to be included in this project, but ICE did not submit their information in time to be utilized in the analysis.

GSA, in concert with CGI support, selected the agencies as a representative sample for a combination of their FM solution (i.e. Momentum, Oracle, and SAP Financials) and current ETS2 providers (i.e. CWTSatoTravel’s E2

Solutions and SAP Concur’s ConcurGov). The goal of the assessment was to:

• Determine agency readiness for transition from ETS2 to ETSNext based on business process and technical environment maturity;

• Identify areas of unique travel requirements and processes to support these requirements;

• Confirm current business processes and best practices leveraged across different technical environments;

• Identify variances or custom processes across agency implementations;

• Identify best practices and current operations that should be carried forward in future versions of the travel solution;

• Identify items requiring resolution for ETSNext transition

Confidential 5

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

CGI covered each of these topics in the Initial Assessment deliverable and this FM Strategy Options document continues where the Initial Assessment concluded.

1.1 Objectives of FM Strategy Options Deliverable

The objective of the FM Strategy Options deliverable is to utilize the information collected and updated in the Initial

Assessment to provide:

• Approaches for an ETSNext application programming interface (API) strategy and related contract considerations (i.e. single or multiple award outcomes and centralized versus decentralized delivery);

• A feasibility study of the value of incorporating a standard integration platform, and its key attributes if this option is chosen by GSA;

• Options for a phased approach for implementing and transitioning agencies to ETSNext based on common FM integrations;

• An assessment of how the government can leverage its existing investments in DoD Global Exchange (GEX) and FM QSMO marketplaces for ETSNext;

• A proposed definition of governance, roles, and responsibilities for configuration and change management within GSA and related stakeholder organizations such as Office of Shared Solutions and Performance

Improvement (OSSPI), FM QSMO, customer agencies, and vendor providers;

• A cost benefit analysis and risk analysis with an accompanying notional schedule for implementation and

Operations and Maintenance (O&M)

This document covers each of these topics. Section 1.2 describes the document’s organization.

1.2 Document Organization

The purpose of this section is to provide the overview of this deliverable.

Section 2, “API Strategy” provides an explanation of the options related to awarding the T&E contract (to one or multiple vendors) and the delivery model (centralized or decentralized delivery). This section discusses the technology solutions related to the centralized model specifically (whether a single or multi-vendor award) by providing a detailed description of the factors GSA will need to consider for an API Gateway, including:

• A comparison of providing the ETSNext service in the cloud versus on-premises;

• Whether to build or buy the gateway;

• Whether to purchase the software and licenses from vendors or rely on open source options for the software products;

• Whether to purchase COTS products or create the components in-house as custom-built software;

• The third-party and in-house talent required to provide a centralized approach successfully for ETSNext commercial and government best practices

Section 3, “Feasibility and Value of Incorporating an Integrated Platform” provides information to identify the feasibility and value of incorporating an integrated platform defined by services. Services are a relatively new architectural pattern to assist with latency, security, and communication between client applications. They assist users with complex technological interactions by creating a user friendly front end for scheduling travel and allowing technology to accomplish complex back end transactions without user intervention.

Confidential 6

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

Section 4, “Phased Approach” provides a review of possible opportunities to group similar FM configurations and develop a phased approach for future development and transition planning for ETSNext.

Section 5, “Investment Assessment” provides a detailed evaluation of whether utilizing existing capabilities such as an Enterprise Service Bus (ESB) architecture already created within the government or a model like the FM

QSMO would provide efficiency and cost savings for ETSNext.

Section 6, “Governance” provides a proposed complete and sustainable governance model by which to manage and evaluate progress towards program milestones while also maintaining program alignment with policies for travel and financial management. A structured governance model supports alignment with government-wide standards, agency needs, and performance objectives and confirms changes are vetted thoroughly before implementation.

Sections 7, 8, and 9, “Cost Benefit Analysis,” “Risk Analysis and Mitigation Recommendations,” and

“Notional Schedules/Key Tasks” provides information related to the costs, benefits, and risks of the centralized and decentralized options as well as notional schedules for possible implementation. This information includes details to assist GSA in determining a way forward for ETSNext by estimating and comparing costs and assessing associated benefits and risks connected by work breakdown structure (WBS) elements to establish Rough Order of

Magnitude (ROMs) of the four (4) options.

Section 10, “Appendix” provides the updated Initial Assessment document and data element mapping spreadsheet between ETS2 and ETSNext data requirements used to provide a complete analysis of the nine (9) agencies’ T&E and FM system configurations, including current customizations and new requirements. This analysis can be leveraged to:

• Support successful agency implementations of ETSNext;

• Provide the basis for an ETSNext solution that it is thorough and easy to use;

• Establish requirements for ETSNext that incorporate modern travel capabilities.

Section 10 also includes other attachments relevant to this document.

Section 11, “Next Steps” provides a discussion of areas of focus for GSA in the coming months in relation to

ETSNext. These steps will support the ETSNext program as it continues on its path for successful implementation by June 2027 when the ETS2 contract expires.

Confidential 7

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

2 Application Program Interface (API) Strategy (SOW 3.5.2)

This section discusses the technical strategy, architecture considerations, centralized verses decentralized delivery considerations, single verses multiple solution vendors, and other considerations. As GSA considers these ideas for future activities, best practices based on industry standards and prior engagements are also included.

2.1 Technical Strategy

The ETSNext program needs a strategy that leverages industry best practices, simplifies the traveler experience, and has a flexible architecture to accommodate future needs.

For the past two decades, APIs have become the standard in modern computing. The internet, mobile devices, social media, and leading commerce companies leverage APIs to share information among systems.

The application mentality has changed from building large monolith systems to breaking the systems into front end and back end capabilities. Furthermore, the back end is broken out into services

(e.g., web services and microservices). The idea is to create modular capabilities that are easier to scale, easier to secure, and easier to maintain. These services are exposed either internally within an organization to support horizontal integration (e.g., HR system interfacing with financial system) and/or exposed externally for vertical integration (e.g., a hardware store application’s front end that uses the back end of a supplier to check inventory). These services are callable and are decoupled from the infrastructure. Therefore, an impacted service does not affect other services and minimizes the impact on the end user. In addition, the services allow for the implementation of subset capabilities. For example, the DOJ leverages two FM systems, but only one of the systems receives travel vouchers from ETS2. If there was a service for vouchers, DOJ could leverage it for either FM system, eliminating redundancies. This approach provides several benefits, including reducing the number of point-to-point interfaces, simplifying maintenance, and standardizing data.

The industry has a number of API management tools with key components, including the API gateway, which primarily manages and monitors API traffic. For the purposes of the discussion, this document will refer to the collective use of these as the “API management approach” and walk through the considerations below.

2.1.1 Decentralized with Multiple Travel Vendors

This decentralized delivery approach with multiple travel vendors would be very similar to the status quo in which

GSA supports multiple travel vendors, primarily managing the master contract but allowing each agency to contract and manage their own implementation of the travel solution directly. While this model provides the agencies with the flexibility to choose a vendor, it creates additional complexity in terms of implementing standards. In addition, it creates many point-to-point interfaces that require individual agency investment to build and maintain unique integrations. This approach does not offer the true benefits of a “shared service,” such as scaling, cost consolidation, streamlined maintenance, and standardization of data and reporting.

The API management approach is a widely used and proven approach in the industry and is the best approach for the GSA ETSNext program based on

GSA’s desired outcomes. The sections below provide key considerations that GSA should examine to achieve the best results for this approach.

Confidential 8

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

2.2 Architecture Considerations

The architecture should consider the rolling nature of agency adoption of an ETSNext delivery approach, for either a centralized or decentralized delivery model.

2.2.1 Agencies Adopting ETSNext in a Centralized Delivery Model

In a centralized delivery model, GSA provides the agency’s travel needs as a single service. This service includes the technology, as well as contractual and pricing aspects involved. Each agency would have its own tenant within the GSA service offering. The agency could choose a GSA offered travel vendor without dealing with the travel vendor directly. The following are the key elements of this model:

• Travel and Expense Technology Services will be a “one stop shop” for federal travelers that can be developed by leveraging GSA’s heritage of human centered design (HCD) capabilities. GSA’s HCD roots, from the early days of 18F to the U.S. web design system, make GSA perfectly suited for driving an omni-channel

(e.g., desktop and mobile) capability. By implementing techniques in which the user is central to each action, this front end can create an advanced experience with features that are self-evident and reduce the need for training. In addition, this provides a standardized experience regardless of the agency with which a user is associated while masking the travel vendor. The ability to configure the front end user portal may be part of the selected travel solution, but if multiple vendors are selected, a unique front end solution may be developed to provide a consistent user experience.

• APIs (red dots in

• Figure 1 below) exist in each service to share data, including travel vendors, agencies, and ETSNext modules.

• Reporting Service is a solution to capture data and develop standard reporting, and other cross-agency functions.

• Rules Service is a solution to manage and apply business rules to the data such as holding transactions during continuing resolutions (CRs).

• Data Sets store performance and aggregate data that can enable reporting and potential future capabilities such as advanced analytics and AI. Data sets also provide the ability to store cross-agency data such as the traveler ID.

• Standard Integration Data and Service Crosswalk will translate agency data to a standard API format.

Section 4, “Phased Approach”, discusses this concept further.

• API Gateway sits between the Travel Portal and the system of APIs on the back end. The ETSNext program will build and maintain these APIs. The API Gateway will handle common tasks used to manage the various

APIs in the system. In addition, it will provide security controls, monitoring, and statistics of the APIs and will support API deployment.

Confidential 9

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

Figure 1: Notional ETSNext Architecture for a Centralized Delivery Model

Figure 2 below describes the key elements of the centralized delivery model with a brief description of key functionality that the GSA ETSNext program would have to build and maintain. This functionality could be built and maintained either in-house with GSA resources or be contracted out. (Please note that in a single award model, the

Travel and Expense Technology Services would be part of the Travel Vendor’s solution.)

Confidential 10

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

Figure 2: Key Elements of the Centralized Delivery Model Provided by the GSA ETSNext Program

2.2.2 Agencies Adopting ETSNext in a Decentralized Delivery Model

In a decentralized delivery model, GSA manages only a portion of the service, primarily the contractual and pricing aspects, but the agency is responsible for the technology components associated with interfacing directly with the travel vendor. For agencies that have determined they either cannot, from a timing standpoint or for security reasons, engage in the centralized delivery model, the decentralized delivery model would allow them to achieve some pricing benefits, as GSA could negotiate based on the scale of multiple agencies. The agency would need to build and maintain the necessary translation of data to support the interactions with the travel vendor’s (or vendors’) systems and support integration with the GSA solution. This would include, but is not limited to, establishing a memorandum of understanding (MOU) to access the GSA data sets and create their own reporting capabilities.

2.3 Considerations for Centralized vs Decentralized and Single vs Multiple Travel Vendors

A key consideration in the design of the architecture is to be centralized (i.e. GSA establishes and oversees the infrastructure for the “middleware” between the travel vendor(s) and the agency being served) versus being decentralized (i.e. GSA manages the contractual aspects but the travel vendor and the agency develop the interface directly between themselves). Another consideration is support for a single travel vendor versus multiple travel vendors. Figure 3 shows the various scenarios and the outcomes for each scenario.

Figure 3: Scenarios for Centralized versus Decentralized and Single versus Multiple Vendors

Confidential 11

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

2.3.1 Decentralized with a Single Travel Vendor

This decentralized delivery approach with a single travel vendor would be a streamlined version of the status quo. It would simplify GSA’s management activities because GSA would only deal with one vendor. GSA would continue to manage the master contract and enable a direct interface between the agency and travel vendor. This model places addition burden on agencies that are not currently using the vendor selected, requiring additional development cost to switch vendors and essentially create a new interface. The agencies would lose the flexibility to choose a vendor and could potentially create downstream problems such as “vendor lock”, creating a single point of failure. In addition, it creates many point-to-point interfaces that require individual agency investment to build and maintain unique integrations. This approach does not offer the true benefits of a “shared service,” such as scaling, cost consolidation, streamlined maintenance, and standardization of data and reporting.

2.3.2 Centralized (Single Travel Vendor)

In a centralized delivery approach with a single travel vendor, an API management approach is appropriate.1 The

API management approach allows GSA to capture the benefits of a shared service as it offers a single infrastructure to maintain (instead of many point-to-point interfaces), is built to scale over time, features simplicity in its design and therefore reduces maintenance costs, and has more standardized data sets and reporting. This will also allow sharing of aggregate data and support for simplified cross-government functions such as a unique, non-

PII traveler ID.

2.3.3 Centralized (Multiple Travel Vendors)

With a centralized model, using an API management approach remains largely the same when using one vendor, two vendors, or multiple vendors (except for contractual aspects). With additional travel vendors, each would provide their respective APIs, and consideration would need to be given to ensure a unified front end approach.

The centralized approach allows GSA to capture the benefits of a shared service, as it offers a single infrastructure to maintain (versus many point-to-point interfaces), is built to scale over time, features simplicity in design and therefore reduced maintenance costs, and has more standardized data sets and reporting. This approach will also allow sharing of aggregate data and support for simplified cross-government functions such as a unique, non-PII traveler ID. With multiple travel vendors, it is possible that increased competition will drive down cost and increase innovation; however, there is an increased cost of the recommended travel and expense technical services front-end capabilities necessary to unify the user experience.

1 While not in the scope of this document, GSA could leverage the ETSNext API management approach government-wide to enable future shared services (e.g., grants and acquisitions management).

Confidential 12

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

2.4 Other Considerations

The following sections provide other considerations that GSA should examine and prepare for as planning occurs for future activities with ETSNext.

2.4.1 Cloud vs On Premise

While the cloud provides strong inherent capabilities such as seamless scaling, cost efficiencies, ability to mine and analyze data, and leverage automation and AI capabilities, the realization is that this may not initially be viable for all components in the solution. As such, GSA can choose to implement the API management approach discussed in this document either on premise or in the cloud. If implemented on premise, GSA will benefit greatly by establishing a plan for migration to the cloud prior to the implementation. This will set the expectations for stakeholders and enable the consideration of migration costs up front.

2.4.2 Timeline

Another variable that GSA will have to consider is the period during which an agency is onboarded to the FM

QSMO standards. While the end goal is for the desired agencies to onboard and use the future-state standards, the reality is that agencies will adopt the standards at different times. This will require GSA to support agencies on

ETS2 solutions as well as agencies that have adopted ETSNext.

2.4.3 Talent

GSA should also consider talent availability. While there are a number of technologies that support the movement of data between systems, the availability of talent with such skills is worth considering. API technologies are adopted broadly, and the marketplace has a relatively large skilled workforce. Moreover, individuals with a developer background (regardless of programming language) are well suited to pick up the API concepts and can ramp up development efforts quickly. Within the API product space, many vendors provide solutions (e.g., Mulesoft and Apigee). As GSA approaches the product selection process, GSA should consider the availability of skilled talent as a factor in the selection to alleviate future concerns.

2.4.4 COTS vs Custom

Most of the components of the API management approach presented in this document are available for purchase as a COTS product or can be custom developed using native programming capabilities. Beyond capabilities, GSA should consider which features come out of the box with COTS products (e.g., logging, auditability, performance monitoring, and reporting). In addition, GSA should examine its future workforce (both employees and contractors) and the prevailing trends to verify they have the proper talent to meet those trends. For example, if the workforce is shrinking and therefore the ability to support custom code is diminishing, technical debt for future generations is created.

2.4.5 Product vs Open Source

Most of the components of the API management approach presented in this document are available for purchase as a product from vendors or obtainable as open source solutions. GSA should examine factors such as the level of support needed from a vendor versus what is available in the open source community. GSA should also consider the product roadmap and predictable software releases that a vendor provides versus the “ad hoc” nature of open source releases. As cybersecurity is a rising concern, GSA should also consider the supply chain and from where the software originates, who maintains it and where that occurs, and how its integrity will be protected in the future.

Confidential 13

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

3 Feasibility and Value of Incorporating an Integration Platform (SOW 3.5.3)

An API management approach is middleware that sits between an API endpoint and back end services, transmitting client requests to an appropriate service of an application. It is also an architectural pattern that was created initially to support services. This lightweight and decoupled model makes it highly suitable for federal agencies which consume a number of existing technologies and workforces.

In the past, applications were built mainly using the monolith approach, meaning that the components were interconnected, so when a client wanted to retrieve data, they would make one API call. A tool called a load balancer would then route the traffic it received between different instances of an application and return the response to the client. Because of the complexity of updating and implementing new technologies, the monolith started being replaced by a new architectural pattern: services.

The services architecture physically separates different services in a system, making them independent and autonomous. Unlike the monolith approach, each service has a different public endpoint, so a client makes requests directly to the required service.

The key attributes include:

• Service Oriented Architecture (SOA) - the approach of exposing business functionality and enabling communications through APIs. SOA enables abstracting application complexity and focuses on providing business functionality.

• Application Programming Interface (API) - software that enables two or more components (e.g., applications, software program, and services) to communicate directly with each other using a standard set of definitions and protocols.

• Software as a Service (SaaS) - capability of delivering applications over the internet as a service. Instead of installing and maintaining software, a client can simply access it via the internet, freeing themselves from complex software and hardware management. SaaS applications run on SaaS provider’s servers. The provider manages access to the application, including security, availability, and performance.

• API Manager/API Management Platform - broad set of capabilities with business-focused software created to maintain, publish, and manage APIs throughout their life cycle. Such platforms combine three core functions:

• API gateway - a software component that performs technical functions to manage APIs, including responsibility for API deployments, routing, security, and other technical tasks;

• Developer portal - where APIs are documented and become discoverable for users; and

• API metrics and analytics - a component for collecting API data from gateways and presenting it on a dashboard.

• Service Contract - a document that captures how the API is designed (e.g., structure, protocol, version, and methods) and can be used for setting up agreements between service providers and service consumers.

The common form of creating API contracts is OpenAPI-Specifications. The benefit of documenting these contracts in code is so both humans and systems can interpret the specifications. Service providers can also receive test procedures from the service consumers, to enable testing to validate whether the service breaks.

https://oreil.ly/cZ9De

Confidential 14

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

• Service Registry - a tool that maintains a list of the APIs, and stores critical API information in a central repository, which promotes reuse of services and avoids API proliferation.

• Service Discovery - a component that allows a client to track the API network location, its health status (e.g., availability and response time), version numbers, and number of consumers.

By leveraging the components and approach described above, GSA can achieve the following value:

• Simplifying the back end – APIs can connect systems relatively simply, allowing access to data, even when it is buried deep within legacy IT systems, quickly and repeatedly. This allows GSA to simplify and automate tasks and speed development.

• Personalization – data aggregation and on-demand reporting through APIs can enable the delivery of personalized services, such as user authentication, fraud management, or finding frequent flyer numbers.

• Ecosystem of innovation and engagement – the connective capability of APIs allows GSA to access new value outside the organization. API developers, for example, can create innovative products and services that tie into existing systems. Advanced API capabilities allow developers to create a richer customer experience by pulling together a deeper array of data sets (rather than simply scraping data). This can drive future innovative capabilities for the government traveler.

The API management approach is highly feasible in a GSA setting. GSA has already started the journey and is currently in the process of establishing an internal API shared service. This service includes some of the components described above, including an API manager, establishing API specifications, utilizing cloud capabilities, managing authentication and authorization for internal GSA staff, and examining API metrics to manage throttling and throughput. The GSA ETSNext program may potentially be able to leverage parts or all of this existing service. The key challenge is that GSA is using the current service for internal GSA functions. In the event that the service cannot be used for external functions (i.e. travel vendors and agencies), the GSA Program

Office may still leverage the program for its established processes and body of knowledge gathered within the GSA setting, such as their playbooks. Vendors will also bring their own API solutions with their products, and these capabilities can be utilized out of the box.

Confidential 15

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

4 Phased Approach (SOW 3.5.4) The purpose of this section is to outline opportunities to group similar FM configurations and develop a phased approach for future development and transition planning. Complete analysis of the nine (9) agency interview responses and current data exchanges between the ETS2 and Core FS solutions identified a few similarities in the

FM data configuration that can be leveraged for ETSNext.

Agency line of accounting (LOA) information passes from ETS2 to FM systems in different ways, including accounting templates, short hand codes, segment mapping, and simply passing different elements.

Figure 4 below groups the agencies interviewed by their Core FS solution: SAP, Oracle, or Momentum. The top data row indicates the artifacts that serve as the basis for the analysis. The data call requested both data mappings and interface control documentation (ICD) but not every agency provided both pieces of information. Section 1 of the table shows the accounting dimensions for both Oracle- and SAP-based solutions. Each column for the representative agencies then shows the mappings of their LOA files to those solution dimensions. Section 2 of the table displays the Momentum solution accounting dimensions. The right hand columns under the Momentum heading within this section show the mapping of the representative agencies.

The agencies that provided only the short hand or accounting template show “Used” as the value in the respective cells.

Figure 4: Agency LOA Configurations2

2 CBP data reflects a speculation of the levered fields based on sample codes provided in the data layouts. The assumed derivation is presented or listed as ‘Undetermined.’ The code name provided in the layout is in parenthesis. The GCE developed solution currently used at DOL was developed based on Oracle Forms. The FAA’s and Treasury’s solutions utilized Oracle eBusiness Suite.

Confidential 16

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

The data reflects some commonality across the Momentum customers due to the definition of the COTS

Momentum accounting line, but a detailed analysis of the master data management structure of each agency’s

LOA dimensions will be required to validate that assumption.

As agencies move to an FM QSMO marketplace solution over time, they will adopt the service provider’s standard configuration to address the requirements of the BIE in a standard way. This will require data migration funding to convert historical and/or unliquidated or open obligations from the configuration they use today to the standard configuration recommended by the Core FS service provider. The FM QSMO marketplace encourages the standard configuration but also acknowledges the agencies’ roles in determining specific configuration needs. As stated in the June 2021 FM QSMO Marketplace vision, “Commercial Service Providers (CSPs) will determine the specific combination of software configuration, enhancements, and/or extensions needed to meet the Core Financial

System (FS) Baseline Solution standards.” The document continues, “Federal agency customers will be able to define additional requirements if needed to address agency-specific business needs. CSPs, Federal Shared

Service Providers (FSSPs), or Federal agency customers themselves can determine the specific combination of software configuration, enhancements, and/or extensions that are added to the Core FS Baseline Solution to provide the ‘Core FS Agency Solution’.”

Agencies will eventually adopt the standard configuration of the FM QSMO Core FS solution, but that will take time and funding as stated above. In addition, agencies will begin using systems compliant with the FM QSMO specifications at different times. Agencies have different contract terms (e.g., 5-year, 10-year period of performances) and they do not have to enter the FM QSMO marketplace until their next re-compete. Therefore, a

Standard Integration Data and Service Crosswalk concept is a recommendation to be included as part of the API

Gateway. Figure 5 depicts this concept below.

Figure 5: Standard Integration Data and Service Crosswalk Concept

The Standard Integration Data and Service Crosswalk allows each agency to define their mapping of the approved

TRT-FFM data elements to the current configuration of their Core FS solution, regardless of where they are in their acquisition strategy or alignment to FM QSMO marketplace. Any integration to the Agency Financial System should leverage the Standard Integration Data and Service Crosswalk. As agencies migrate to the standard configuration required by the approved FM QSMO Core FS providers, they need only update the crosswalk – the integration would not require further development.

The agency data provided for this analysis did not reflect configuration commonalities across Core FS solutions.

Further, interview responses indicated that agencies have available data elements to accommodate the new requirements of the TRT-FFM standard recommendations (e.g., event indicator code) in their current Agency

Financial Systems. Since ETSNext will be live prior to the agencies’ adoption of the FM QSMO standard

Confidential 17

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

configuration, the crosswalk can support the integration to the standard configurations at a later time as agencies adopt, but allow them to comply with the TRT-FFM standards agreed upon for the ETS2 to ETSNext transition.

A phased approach can be developed and leveraged for each agency based upon the Core FS solution in use.

Consideration of agency preference will further support the onboarding process. Onboarding agencies based upon their Core FS solution used today provides some economies of scale in configuring the API Gateway, testing, change management activities, and transition related communications. Special considerations will be necessary for agencies that have multiple Core FS accounting systems, such as the Department of Homeland Security (DHS), as well as for agencies migrating to a new Core FS solution, such as Veterans Affairs that are currently migrating to a new core FS solution.

Confidential 18

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

5 Investment Assessment (SOW 3.5.5)

This section discusses the ability to leverage existing government investments in both DoD GEX and the FM

QSMO approach and marketplace solutions.

5.1 Assessment of Leveraging DOD GEX Approach

The purpose of this section is to assess whether the GSA ETSNext program can leverage the investment, approach, or lessons learned related to the DoD GEX system. GEX is a DoD created system that is used to exchange data between logistics and administrative systems. While the DoD GEX architecture can support data bridge capabilities, the system poses some challenges for GSA use:

• The system was designed as an enterprise service bus (ESB), which was the prevailing model at the time of conception. This resulted in a tailored solution for the core architecture with a variety of technologies to support. Modern technologies, such as API management, perform many of the same capabilities in a more simplified manner, placing emphasis on maintaining the various API owners versus the core architecture.

• The DoD GEX system has a centralized architecture, which poses availability risks. Since DoD GEX is an ESB, it is reliant on the infrastructure to transport data between systems, whereas, the API management model exposes services of the system, irrespective of the infrastructure, to transport the data. This distributes the risk of availability across the nodes. If a node fails, it only affects that node, leaving the other parts of the system unaffected.

• The API management model can support a range of service areas enabling support for potential future capabilities beyond travel and expense management (e.g., grants management and acquisitions). The DoD

GEX application is designed for a single service area, and additional service area support would require extensive development effort.

As discussed in Section 3, GSA has already started the API management journey and is currently in the process of establishing an internal API shared service. This capability is more advanced than GEX, and GSA as well as many vendors, is already beyond GEX in terms of technology.

5.2 Assessment of Leveraging FM QSMO Approach

The purpose of this section is to assess whether the GSA ETSNext program can leverage the investment, approach, or lessons learned related to the FM QSMO marketplace. The Office of Management and Budget (OMB)

Memorandum M-19-16 first introduced the concept of designating agencies as QSMOs. As stated in the memo, the purpose of the QSMOs is to offer solutions that, over time, will standardize processes, reduce the technology footprint, and reduce government-wide operating costs. The memorandum mandated that the QSMO be responsive to customer agencies, employ best practices from both public and private sectors, offer competitive solutions that drive standardization, and provide high quality service offerings that are responsive and adaptable to agency business needs. The memorandum also documents the OMB governance and operating model, designating GSA’s OSSPI to lead program management of the QSMO marketplaces. On June 29, 2020, OMB designated the U.S. Department of Treasury as the QSMO for Core FM. OMB has since named other QSMOs for cybersecurity, grants management, and human resource management.

The GSA ETSNext program would not achieve substantial benefits by leveraging the DoD GEX approach as it is a tailored solution with dated architecture that poses availability risks.

Confidential 19

This report contains pre-decisional input (i.e., CGI-identified potential options) for ETSNext. Additional options may be identified in the future.

As stated in the FM QSMO Agency and Industry Collaboration Session on August 25, 2021, the FM QSMO took a human centered design approach along with market research tools and techniques to engage stakeholders in the design of the marketplace and in building agency partnerships. They focused on a positive customer experience, maximizing strategic value of data, and delivering progress in an agile way. Shared goals communicated were standardizing process and data, reducing operation and maintenance costs, modernizing and automating processes, and improving customer satisfaction.

The Federal Integrated Business Framework (FIBF) includes FM functions and activities, FM business use cases, FM business capabilities and FM business data elements. The GSA ETSNext program is already aligning with the

FIBF and is working with the Office of Government-wide Policy (OGP) to define the travel standards.

FM QSMO has three components of the marketplace: Core FS, other FM Solutions and Services, and Treasury

Centralized Services. For Core FS and other FM Services and Solutions, the marketplace allows each agency their choice of qualified providers. Providers are qualified to a Financial Management Capability Framework (FMCF).

The FMCF defines the aspects to which qualified providers must adhere, including service measures, BIE requirements, and…