Alliant 3 GWAC Draft Request for Proposal.pdf

Governmentwide Acquisition

Contract (GWAC)

Draft Request For Proposal (RFP)

Public Release Date: October 19, 2022

Public Notice, Disclaimer

The Alliant 3 Draft Request for Proposal (RFP) is publicized solely for market research purposes. As such, this document only contains sections of the intended contract for which the General Service Administration is seeking public comments and questions via A3draftRFP@gsa.gov. This document is not an official RFP from the Government and does not constitute a request for offers. All comments or questions received are on a voluntary basis. The Government will not reimburse any costs attributed to responses.

The Government will consider any comments or questions received prior to January

6, 2023 by 12 pm (noon) Eastern Standard Time (EST). The Government reserves the right to consolidate and/or select the questions and comments to respond to as a result of this draft RFP.

TABLE OF CONTENTS

SECTION B - SUPPLIES OR SERVICES AND PRICES/COSTS 1

B.4 Minimum Contract Guarantee and Maximum Contract Ceiling 1

B.11.5.1 Maximum Rates for Time-and-Material and Labor Hour

Contract Types 1

SECTION C - CONTRACT SCOPE OF WORK AND PERFORMANCE

WORK STATEMENT 2

C.1 SCOPE OF WORK OBJECTIVE 2

C.2 SCOPE OF WORK OVERVIEW 2

C.3 FOUNDATION OF THE SCOPE OF WORK 4

C.3.1 FEA Reference Model Detailed Descriptions 6

Overview of the Collaborative Planning Methodology (CPM) 8

Performance Reference Model (PRM) 9

Business Reference Model (BRM) 11

Data Reference Model (DRM) 12

Application Reference Model (ARM) 13

Infrastructure Reference Model (IRM) 15

Security Reference Model (SRM) 16

C.4 COMPONENTS OF AN IT SOLUTION 17

C.4.1 Infrastructure 18

C.4.1.1 Service Access and Delivery 19

C.4.1.2 Service Platform and Infrastructure 19

C.4.1.3 Component Framework 20

C.4.1.4 Service Interface and Integration 20

C.4.2 Application Services 20

C.4.2.1 Customer Services 21

C.4.2.2 Process Automation 21

C.4.2.3 Business Management 22

C.4.2.4 Digital Asset Services 22

C.4.2.5 Business Analytical Services 23

C.4.2.6 Back Office Services 23

C.4.2.7 Support Services 24

C.4.2.8 DoD IEA Mission Area Support 24

C.4.3 IT Management Services 25

C.4.3.1 Controls and Oversight 25

C.4.3.2 Risk Management and Mitigation 25

C.4.3.3 Regulatory Development 26

C.4.3.4 Planning and Resource Allocation 26

C.4.3.5 IT Security 27

C.4.3.6 System and Network Controls 27

C.4.4 Cloud Computing 27

C.4.5 Big Data & Big Data Analytics 29

C.5 ANCILLARY SUPPORT: SERVICES, SUPPLIES AND

CONSTRUCTION 30

C.6 CONTRACT SECURITY REQUIREMENTS 30

C.7 PERFORMANCE WORK STATEMENT (PWS) 30

C.7.1 Master Contract PWS 30

C.7.1.1 Master Contract PWS and Goals for Contractor

Engagement 31

C.7.1.2 Master Contract PWS for Small Business Subcontracting 32

C.7.2 Task Order PWS 32

C.8 INNOVATIVE SOLUTIONS 32

C.9 SERVICES NOT IN SCOPE 33

C.10 SCOPE REFERENCES AND RESOURCES 33

SECTION G - CONTRACT ADMINISTRATION DATA 36

G.22.1 Minimum Subcontracting Goals 36

SECTION L - INSTRUCTIONS, CONDITIONS, AND NOTICES TO

OFFERORS OR RESPONDENTS 38

L.1 FAR 52.252-1 SOLICITATION PROVISIONS INCORPORATED BY

REFERENCE (Feb 1998) 38

L.2 FAR AND GSAR PROVISIONS 39

L.2.1 FAR 52.216-1 Type of Contract (APR 1984) 39

L.2.2 FAR 52.216-27 Single or Multiple Awards (OCT 1995) 40

L.2.3 FAR 52.233-2 - Service of Protest (SEP 2006) 40

L.2.4 GSAR 552.217-71 Notice Regarding Option(s) (Nov 1992) 41

L.3 PROPOSAL SUBMISSION INSTRUCTIONS 41

L.3.1 Official Legal Offering Entity 43

L.3.2 Mergers, Acquisitions, Novations, and Change-of-Name

Agreements, as Applicable 43

L.3.3 Inverted Domestic Corporations 44

L.3.4 Proposal Due Date and Address Location 44

L.3.5 Solicitation Questions 44

L.3.6 Pre-proposal Conference 45

L.4 PROPOSAL FORMAT 45

L.4.1 Proposal Format Table 47

L.5 PROPOSAL CONTENT 58

L.5.1 VOLUME 1 - GENERAL 58

L.5.1.1 Standard Form (SF) 33 and SF-30 for Amendments 58

L.5.1.2 Document Verification and Self Scoring Worksheet 59

L.5.1.3 Individual Small Business Subcontracting Plan (Required for

Other than Small Business Offerors) 60

L.5.1.3.1 Payment Basis Reporting on eSRS 64

L.5.1.3.2 FAR 19.702 Statutory requirements 64

L.5.1.4 Meaningful Relationship Commitment Letters, if applicable 66

L.5.1.5 Existing Joint Venture or Partnership, if applicable 68

L.5.1.5.1 Claiming Relevant Experience from an Existing or Previous

Joint Venture or Partnership 70

L.5.1.5-Alt. Small Business Contractor Teaming Arrangements, If

Applicable 72

L.5.1.5.1-Alt Partnership or Joint Venture, if applicable 72

L.5.1.5.2-Alt. Proposed Small Business Subcontractors, If Applicable 74

L.5.1.5.3-Alt. Claiming Small Business Prime Contractor Relevant

Experience from an Existing or Previous Joint Venture or Partnership

(If Applicable) 76

L.5.1.6 Professional Employee Compensation Plan 77

L.5.1.7 Uncompensated Overtime Policy 77

L.5.1.8 Representations and Certifications 78

L.5.2 VOLUME 2 - RELEVANT EXPERIENCE 78

L.5.2.1 Relevant Experience Projects 78

L.5.2.2 NAICS Group Relevant Experience 80

Primary Relevant Experience NAICS Areas 81

L.5.2.2.1.1 Verification of Primary Relevant Experience Submission

(Federal Government Contracts) 82

L.5.2.2.1.2 Verification of Primary Relevant Experience Submission

(Non-Federal Contracts and Federal Government Subcontracts to

Small Business Entity) 84

L.5.2.2.2 Relevant Experience - Project Size 85

L.5.2.2.3 Demonstrating Experience with Multiple Federal

Government Customers (Federal Government Contracts Only) 86

L.5.2.2.4 Projects with Cost-Reimbursement (Federal Government

Contracts Only) 86

L.5.2.2.5 NAICS Group Relevant Experience - Fair Opportunity Task

Order Award Against a MA/IDIQ Contract 87

L.5.2.2.6 Location 88

L.5.2.3 Emerging Technology Relevant Experience 88

L.5.2.3.1 Emerging Technology Listing 89

L.5.2.3.1.1 Verification of Emerging Technology Relevant Experience

Submission 99

L.5.2.3.2 Breadth of Emerging Technology Relevant Experience 101

L.5.2.3.3 Small Business Emerging Technology Solutions Engagement

L.5.3 VOLUME 3 – PAST PERFORMANCE FOR RELEVANT

EXPERIENCE PROJECTS 105

L.5.3.1 Past Performance (When CPARS information exists) 105

L.5.3.2 Past Performance (When CPARS information does not exist)105

L.5.3.3 Negative Past Performance Narrative (Optional) 106

L.5.4 VOLUME 4 – SYSTEMS, CERTIFICATIONS, AND

CLEARANCES 106

L.5.4.1 Cost Accounting System and Audit Information 107

L.5.4.2 Approved Purchasing System 109

L.5.4.3 Forward Pricing Rate Agreements, Forward Pricing Rate

Recommendations, and/or Approved Billing Rates 109

L.5.4.4 Earned Value Management Systems (EVMS) 110

L.5.4.5 Acceptable Estimating System 110

L.5.4.6 Capability Maturity Model Integration (CMMI) Certification

L.5.4.7 ISO 9001:2015 Certification 111

L.5.4.8 ISO/IEC 20000-1:2018 Certification 111

L.5.4.9 ISO/IEC 27001:2013 Certification 112

L.5.4.10 Facility Clearance Level (FCL) 112

L.5.5 VOLUME 6 – RESPONSIBILITY 112

L.5.5.1 Financial Resources 113

L.5.6 VOLUME 5 – ORGANIZATIONAL RISK ASSESSMENT 115

L.5.6.1 Organizational Risk Assessment 115

SECTION M - EVALUATION FACTOR FOR AWARD 117

M.1 FAR 52.252-1 SOLICITATION PROVISIONS INCORPORATED BY

REFERENCE (FEB 1998) 117

M.2 BASIS FOR AWARDS 117

M.3 EVALUATION PROCESS 118

M.4 SCREENING PROCESS AND ACCEPTABILITY REVIEW 119

M4.1 Screening Process 119

M.4.2 Acceptability Review 119

M.4.2.1 The Offeror’s Individual Subcontracting Plan (Plan) must be determined Acceptable 120

M.5 TECHNICAL EVALUATION 120

M.5.1 Relevant Experience 120

M.5.2 Past Performance 121

M.5.2.1 Evaluation Ratings for Past Performance Submissions 121

M.5.2.2 Points Assigned to Past Performance Assessments 121

M.5.3 Systems, Certifications, and Clearances 122

M.5.4 Risk Assessment 122

M.5.4.1 Organizational Risk Assessment 122

M.6 Alliant 3 SCORING TABLE 123

M.7 RESPONSIBILITY 127

M.8 GSA ACQUISITION LETTER MV-16-04, CLASS DEVIATION TO

FAR 15.404-1(d)(2) PROPOSAL ANALYSIS TECHNIQUES 128

ATTACHMENT J-3 - ALLIANT 3 LABOR CATEGORIES AND BLS

SERVICE OCCUPATIONAL CLASSIFICATIONS 129

INDIVIDUAL LABOR CATEGORIES 130

ATTACHMENT J-4

CYBERSECURITY & SUPPLY CHAIN RISK MANAGEMENT (SCRM)

REFERENCES 147

Laws 147

Executive Orders and Presidential Directives 148

Policies of the Committee on National Security Systems 148

OMB Circulars and Memoranda 148

National Institute of Standards and Technology (NIST) 149

Cybersecurity and Infrastructure Security Agency 150

Cybersecurity Maturity Model Certification 150

Cloud Computing 150

Zero Trust 152

ATTACHMENT J-5.B - PERFORMANCE-BASED ACQUISITION (PBA)

SMALL BUSINESS SUBCONTRACTING EVALUATION PROGRAM

RATINGS 155

Acceptable Quality Level (AQL), Minimum Requirements Needed to Earn a Satisfactory Subcontracting Rating 155

Requirements Needed to Earn a Rating Above the Minimum AQL 155

Subcontracting Ratings, Rating Measurements, and Applicable Corrective

Actions 156

CPARS/PPR Annual Small Business Subcontracting Rating Guide and

Corrective Actions 156

GSA ALLIANT 3 UNRESTRICTED GWAC - DRAFT RFP

SECTION B - MAXIMUM CONTRACT GUARANTEE AND MAXIMUM CONTRACT CEILING

SECTION B - SUPPLIES OR SERVICES AND

PRICES/COSTS

B.4 Minimum Contract Guarantee and Maximum Contract Ceiling

(a) Minimum. The minimum guaranteed award amount for this IDIQ contract is $2500 dollars per Master Contract for the full term of the Master Contract. The exercise of the option period does not re-establish a minimum guaranteed award amount.

(b) The Government has no obligation to issue task orders to the Contractor beyond the amount specified in paragraph (a) of this section. Should the contract expire or be unilaterally terminated for convenience by the Government without the Contractor receiving the minimum guaranteed award amount, the Contractor may present a claim to the Contracting Officer (CO) for an amount not to exceed the minimum guaranteed award amount. The minimum guaranteed award amount is not applicable if the contract is terminated for default or is bilaterally canceled by the parties. Entitlement is waived if no claim is submitted to the CO within one year of contract termination or expiration.

(c) Maximum. There is no maximum dollar ceiling for the Master Contract or for each individual task order. An unlimited number of task orders may be placed for the term of Alliant 3, including the Option, if exercised. Ordering Contracting Officers (OCOs) will follow regulatory and agency requirements to establish maximum dollar ceilings at the task order level. (Pending deviation approval)

B.11.5.1 Maximum Rates for Time-and-Material and Labor Hour

Contract Types

a. Applicable to the Master Contract

Maximum Rates Definition: “Maximum Rates”, is a term that sets allowable labor rates for Standard IT Service LCATs for the Master Contract. The Master Contract is not subject to maximum rates. (Pending deviation approval)

Alliant 3 Draft Request for Proposal 1

SECTION C - CONTRACT SCOPE OF WORK AND PERFORMANCE WORK STATEMENT

SECTION C - CONTRACT SCOPE OF WORK AND

PERFORMANCE WORK STATEMENT

C.1 SCOPE OF WORK OBJECTIVE

The Alliant 3 GWAC will provide Federal Government agencies with integrated Information Technology (IT) solution services for evolving needs on a global basis. This Master Contract allows for the application of technology to meet business needs including the ability to perform all current, leading edge and/or emerging IT services required to satisfy all IT services requirements anywhere and anytime worldwide.

Integrated IT solutions may be composed of IT components as described in

Section C.4. Solutions may be tailored in Task Order Requests to meet agencies’ mission requirements. Work may be performed at Government or

Contractor facilities located throughout the world, as specified in each Task

Order, to provide a variety of IT solutions and support services. IT solution services within scope of this Master Contract include new, leading edge and emerging technologies that will evolve over the life of the Master Contract as supported by the Federal Enterprise Architecture (FEA), Department of

Defense Information Enterprise Architecture (DoD IEA) Reference Models, and associated reference models.

C.2 SCOPE OF WORK OVERVIEW

The Master Contract provides maximum flexibility in acquiring an IT service-based solution for any conceivable IT service-based requirement, driving government savings through efficiencies and improved reporting data with greater integrity, while maintaining an “Anything IT Anywhere” philosophy.

The Master Contract scope includes any and all components of an integrated

IT service-based solution, including all current leading-edge technologies and any new technologies, which may emerge during the Master Contract period of performance. All IT development methodologies, including Agile, are supported. The Master Contract scope also includes IT service-based support of National Security Systems, as defined in FAR 39.002. The Master Contract provides IT solutions through performance of a broad range of services, which may include the integration of various technologies critical to the services being acquired. The foundation of the Scope of the Master Contract is built on

Alliant 3 Draft Request for Proposal 2 the most current FEA and DoD IEA Reference Models. (See links under

Resources Section C.10). As the definition of IT changes over the lifecycle of the Master Contract with the evolving FEA and DoD IEA models, the scope of the Master Contract will be considered to coincide with the current IT definition at any given time.

By nature of the alignment to FEA and DoD IEA, the Master Contract includes any and all emerging IT components, IT services, and ancillary elements as they arise, as required, to successfully achieve the agency’s mission. Therefore, because technological advances over the term of this

Master Contract are inevitable, the scope of this Master Contract takes into consideration that Task Order Requirements are permitted to include any future IT services with their integral and necessary ancillary IT components and services as they arise during the entire term of this contract including any IT services solution as a service.

The scope of the Master Contract includes every conceivable aspect of IT

Services, including but not limited to:

● 3-D Printing Integration

● Agile Development

● Artificial Intelligence

● Biometrics /Identity Management

● Cloud Computing

● Context-aware Computing

● Critical Infrastructure Protection and Information Assurance

● Cyber Security

● Cyber Security Mesh

● Data Centers and Data-Center Consolidation

● Data Fabric

● Decision Intelligence

● Digital Government

● Digital Trust and Identity Integration and Management

● Digitization and Imaging

● Digital Process Automation

● Distributed Ledger

● Energy and Sustainability Measurement and Management

● Enterprise App Stores and Mobile Security

● Enterprise Resource Planning

● Integration Services

Alliant 3 Draft Request for Proposal 3

● Internet of Things

● IPV6 Migration & Upgrades

● IT Helpdesk, Operations, or Maintenance

● IT Services for Healthcare

● IT Services for Integrated Total Workplace Environment

● Mobile-Centric Application Development, Operations and Management

● Modeling and Simulation

● Network Operations, Infrastructure, and Service Oriented

Architecture

● Open-Source Integration and Customization

● Outsourcing IT Services

● Quantum Computing / Networking / Machine Learning

● Robotic Process Automation

● Secure Access Service Edge (SASE)

● Sensors, Devices and Radio Frequency Identification (RFID)

● Shared IT Services

● Software Development

● Virtualization

● Voice Over Internet Protocol (VOIP)

● Web Analytics

● Web Application & Maintenance

● Web Services

● Web Hosting

● XR (Extended Reality) - Virtual Reality (VR) / Augmented Reality (AR)

/ Mixed Reality (MR)

● Zero-trust Networks

C.3 FOUNDATION OF THE SCOPE OF WORK

Overview of Federal Enterprise Architecture Framework (FEAF) and

Department of Defense Information Enterprise Architecture (DOD IEA)

(1) Solutions to Integrated IT requirements are comprised of some or all components and functional areas associated with FEA and DoD IEA and may be tailored to meet agency needs. By aligning the scope of the Master

Contract to FEA/DoD IEA, users have access to the entire spectrum of current and emerging IT service, all ancillary services, products, and personnel required to successfully meet the agency mission.

Alliant 3 Draft Request for Proposal 4

(2) The Contractor shall promote IT solutions that support Federal

Government operational requirements for standardized technology and application service components. This shall facilitate integration requirements for broad Federal IT and e-Gov Initiatives, as well as promote the sharing, consolidation, and “re-use” of business processes and systems across the

Federal government. The Contractor shall promote the use of open-source solutions and open technology development where practicable to enable the

“re-use” in accordance with the underlying tenets of FEA/DoD IEA and to address any number of areas of interest within the limits of IT and supporting services and disciplines.

Figure 1 - Federal Enterprise Architecture (FEA)

The Master Contract leverages the existing FEA and the DoD IEA version

2.0 as the basis of its IT scope.

FEA & DOD IEA represent a well-defined practice for conducting enterprise analysis, design, planning, and implementation, using a holistic approach at all times, for the successful development and execution of strategy.

Enterprise architecture (EA) applies architecture principles and practices to guide organizations through the business, information, process, and technology changes necessary to execute their strategies. This includes

Alliant 3 Draft Request for Proposal 5 everything from a small mobile application development project to the design, installation, and migration to a complex network serving hundreds of thousands of users. These practices utilize the various aspects of an enterprise to identify, motivate, and achieve these changes.

Each reference model represents and includes a number of functional areas required to meet an objective.

C.3.1 FEA Reference Model Detailed Descriptions

Enterprise Architecture supports planning and decision-making through documentation and information that provides an abstracted view of an enterprise at various levels of scope and detail. The Common Approach to

Federal Enterprise Architecture, released in May 2012, as part of the federal

CIO’s policy guidance and management tools for increasing shared approaches to IT service delivery, presents an overall approach to developing and using Enterprise Architecture in the Federal Government. The Common

Approach promotes increased levels of mission effectiveness by standardizing the development and use of architectures within and between Federal

Agencies. This includes principles for using EA to help agencies eliminate waste and duplication, increase-shared services, close performance gaps, and promote engagement among government, industry, and citizens.

The Federal Enterprise Architecture Framework v2 describes a suite of tools to help government planners implement the Common Approach. At its core is the Consolidated Reference Model (CRM), which equips Office of

Management and Budget (OMB) and Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated “reference models” that describe the six sub-architecture domains in the framework:

● Strategy

● Business

● Data

● Applications

● Infrastructure

● Security

These are designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Also, by applying all six reference models, agencies can establish a line of sight from the strategic goals at the highest organizational level to the software and hardware infrastructure that enable achievement of

Alliant 3 Draft Request for Proposal 6 those goals. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way.

To apply the framework to an agency’s specific environment, the agency should develop a set of “core” artifacts to document its environment within the framework presented by the CRM. Each sub-architecture domain represents a specific area of the overall framework and has particular artifacts, based on EA best practices, which are described and recommended in the Framework and Artifacts document. The type and depth of documentation actually used by the agency should be guided by the need or detail and answers to questions about requirements, applicable standards, timeframes, and available resources.

The real value to the agency of developing an EA is to facilitate planning for the future in a way that transforms the government while making it more efficient. The agency can use the EA process to describe the enterprise as it currently is and determine what the enterprise should look like in the future, so that it can make plans to transition from the current state to the future state. The Collaborative Planning Methodology provides steps for planners to use throughout the planning process to flesh out a transition strategy that will enable the future state to become reality. It is a simple, repeatable process that consists of integrated, multi-disciplinary analysis that involves sponsors, stakeholders, planners, and implementers.

The agency will create an Enterprise Roadmap to document the current and future architecture states at a high level and present the transition plan for how the agency will move from the present to the future in an efficient, effective manner. The agency’s Enterprise Roadmap combines the artifacts developed for the EA, both current and future state versions, with a plan developed through the Collaborative Planning Methodology. This creates awareness, visibility and transparency within an organization to facilitate cross-organization planning and collaboration. It maps strategy to projects and budget and helps identify gaps between investment and execution, as well as dependencies and risks between projects.

All in all, the FEA Framework v2 helps to accelerate agency business transformation and new technology enablement by providing standardization, analysis and reporting tools, an enterprise roadmap, and a repeatable architecture project method that is more agile and useful and will

Alliant 3 Draft Request for Proposal 7 produce more authoritative information for intra- and inter- agency planning, decision making, and management.

Overview of the Collaborative Planning Methodology (CPM)

Planning is done to affect change in support of an organization’s Strategic

Plan, and the many types of planners (e.g., architects, organization and program managers, strategic planners, capital planners, and other planners) must work together to develop an integrated, actionable plan to implement that change. Planning should be used to determine the exact changes that are needed to implement an organization’s Strategic Plan, enable consistent decision-making, and provide measurable benefits to the organization. In short, an organization’s Strategic Plan should be executed by well-rounded planning that results in purposeful projects with measurable benefits.

In today’s environment, which demands more efficient government through the reuse of solutions and services, organizations need actionable, consistent, and rigorous plans to implement Strategic Plans and solve priority needs.

These integrated plans should support efforts to leverage other Federal, state, local, tribal, and international experiences and results as a means of reusing rather than inventing from scratch. Plans should be consistent and rigorous descriptions of the structure of the organization or enterprise, how

IT resources will be efficiently used, and how the use of assets such as IT will ultimately achieve stated strategies and needs.

Consolidated Reference Models

The Consolidated Reference Model of the FEA equips OMB and Federal agencies with a common language and framework to describe and analyze investments. It consists of a set of interrelated “reference models” designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of federal agency operations in a common and consistent way. Through the use of the Federal Enterprise Architecture

Framework (FEAF) and its vocabulary, IT portfolios can be better managed and leveraged across the federal government, enhancing collaboration and ultimately transforming the Federal government.

The five reference models in version 1 of the FEA have been regrouped and expanded into six reference models in the current version of the FEA.

Alliant 3 Draft Request for Proposal 8

Figure 2 - Consolidated Reference Model (CRM)

With edits for brevity, the following reference model summarized descriptions were taken from OMB’s FEA Consolidated Reference Model Document

Version 2, dated January 29, 2013.

Significantly more detail about the structure, taxonomy, and associated methods of the reference models is available online: See Attachment J-8

Website References.

The motivating purpose of adopting the FEA as scope guidance is to help establish business driver alignment with any number of the reference models which support all possible underlying technologies required to meet an agency objective as well as offering the baseline for the technical vocabulary required in any given task.

Performance Reference Model (PRM)

The PRM is designed to provide linkage between investments or activities and the strategic vision established by agencies and the Federal Government.

Historically, linking information management investments and activities has been anecdotal due to a lack of standard approach to describing agency and

Alliant 3 Draft Request for Proposal 9 cross-agency performance attributes. The GPRA Modernization Act of 2010 requires the government to publish performance information through a central website and make strategic plans and performance reports available in machine readable formats. This advance enables more comprehensive and consistent linking of investments and activities to Agency strategic goals and objectives, Agency priority Goals, Cross Agency Priority goals and management areas of focus. The PRM leverages the requirements of the

GPRA Modernization Act to establish mechanisms to link directly to the authoritative performance elements published in compliance with the law and provides the means for use of future developments in the mandated central performance website Performance.gov.

There are three areas to the Performance Reference Model. The first is the

Goal. This enables grouping of investments and activities through a common and authoritative framework established by agencies in compliance with

OMB direction and the GPRA Modernization Act of 2010. It allows the identification of common performance elements across investments or activities, and in the future will enable cross platform information linkages between systems such as Performance.gov and the IT Dashboard.

This linkage provides the logical relationships necessary to consistently provide much richer insights into details of the supported performance areas than previously feasible.

The second area of the Performance Reference Model is Measurement Area.

This describes the manner in which the investment or activity supports the achievement of the supported performance element identified by the Agency

Goal. Measurement Areas apply to the more detailed performance indicators associated with the investment of activity rather than the functions of the investment or activity. Investment or activity performance indicators should have a clear linkage to the activities, of course, but it is important to recognize that investments or activities may align to multiple measurement areas.

The third area, Measurement Category, refines Measurement Area. Any

Measurement Category may be applied to any Goal.

The PRM, like all other reference models, is intended to work in concert with other reference models. The combined descriptive qualities of the multiple perspectives afforded by assigning different reference model perspectives to investments or activities can provide rich insights into what, why and how the investments or activities are undertaken. Previous versions of the PRM

Alliant 3 Draft Request for Proposal 10 included mission function characteristics that were redundant to the BRM

(Business Reference Model, see below). In this version of the PRM the

Measurement Category codes have been streamlined to better identify the means by which performance is achieved. Including BRM and PRM mappings with an investment or activity provides information about the strategic basis

(why) through the Agency Goal, the means (how) through the measurement category, and the mission functions involved (what) through the BRM taxonomy. Additional mappings to other reference models provide further context for the investment or activity with the SRM providing information about risk, the DRM about the information involved and the ARM and IRM providing the technical details about the implementation.

Figure 3 - The Performance Reference Model - (PRM)

Business Reference Model (BRM)

The BRM is a classification taxonomy used to describe the type of business functions and services that are performed in the Federal Government. By describing the Federal Government using standard business functions rather than an organizational view, the BRM promotes cross-government collaboration. It enables business and IT leaders to discover opportunities for cost savings and new business capabilities that help to achieve strategic objectives. The BRM describes the “What we do” of the Federal enterprise through the definition of outcome-oriented and measurable functions and services.

Alliant 3 Draft Request for Proposal 11

While the BRM provides a standardized way of classifying government functions, it is only a model; its true utility and value is realized when it is applied and effectively used in business analysis, design and decision support that help to improve the performance of an agency, bureau or program.

BRM is informed by the PRM and informs the other reference models. At the high level, the BRM relationship and tie-in to the other reference models is illustrated in the following table:

Figure 4 - The Business Reference Model - (BRM)

The BRM forms a key part in delivering expected outcomes and business value to an organization. By using a standard taxonomy to classify functions, investments, programs, services and other elements across the Federal

Government, the BRM is useful in identifying opportunities for cost reduction, collaboration, shared services, and solution reuse in agency IT portfolios and intra- and inter-agency collaboration.

Data Reference Model (DRM)

The DRM’s primary purpose is to promote the common identification, use, and appropriate sharing of data/information across the federal government.

The DRM is a flexible and standards-based framework to enable information sharing and reuse via the standard description and discovery of common data and the promotion of uniform data management practices. The DRM provides a standard means by which data may be described, categorized, and shared, Alliant 3 Draft Request for Proposal 12 and it facilitates discovery and exchange of core information across organizational boundaries.

As a reference model, the DRM is presented as an abstract framework from which concrete implementations may be derived. The DRM’s abstract nature will enable agencies to use multiple implementation approaches, methodologies and technologies while remaining consistent with the foundational principles of the DRM.

The DRM is closely linked with the other five reference models of the

Consolidated Reference Model Framework. At the high level, the DRM relationship and tie-in to the other reference models is illustrated in the following table:

Figure 5 - The Data Reference Model - (DRM)

The DRM provides guidance for agencies to leverage existing Data Assets across the government. The DRM increases the Federal government’s agility in drawing out the value of information as a strategic asset. This reference-able, conceptual approach facilitates information sharing and reuse across the Federal government.

Application Reference Model (ARM)

The purpose of the ARM is to provide the basis for categorizing applications and their components. As agencies map their current and planned

Information Systems to the ARM categories, gaps and redundancies will

Alliant 3 Draft Request for Proposal 13 become evident, which will aid in identifying opportunities for sharing, reuse, and consolidation or renegotiation of licenses. This information may be used in conjunction with the other Reference Models to identify these opportunities.

For the purposes of the CRM, Application is defined as: Software components

(including websites, databases, email, and other supporting software) resting on Infrastructure that, when aggregated and managed, may be used to create, use, share, and store data and information to enable support of a business function.

The ARM is a categorization of different types of software, components, and interfaces. It categorizes software that supports or may be customized to support business. It does not include operating systems or software that is used to operate hardware (e.g., firmware) because these are contained in the

IRM. It also does not contain mission-specific categorizations for systems because that information can be obtained from mappings to the BRM.

The ARM is closely linked with the other five reference models of the

Consolidated Reference Model Framework. At the high level, the ARM relationship and tie-in to the other reference models is illustrated in the following table:

Figure 6 - The Application Reference Model - (ARM)

Alliant 3 Draft Request for Proposal 14

Infrastructure Reference Model (IRM)

The IRM is the taxonomy-based reference model for categorizing IT infrastructure and the facilities and network that host the IT infrastructure.

The IRM supports definition of infrastructure technology items and best practice guidance to promote positive outcomes across technology implementations.

For the purposes of the CRM, Infrastructure is defined as: The generic

(underlying) platform consisting of hardware, software and delivery platform upon which specific/customized capabilities (solutions, applications) may be deployed.

The IRM implementation enables sharing and reuse of infrastructure to reduce costs, increase interoperability across the government and its partners, support efficient acquisition and deployment, and enable greater access to information across enterprises.

In addition to providing a categorization schema for IT infrastructure assets, the IRM enables analysis of IT infrastructure assets at a Department or

Agency level as well as at a Federal Government level. In the Federal context, the IRM is adopted and used to conduct Government-wide analysis of

IT infrastructure assets and to identify consolidation initiatives. In the

Department or Agency context, the IRM is used to drive good IT infrastructure asset management practices such as identifying end-of-life assets before they affect the mission of an organization and to identify opportunities for sharing and consolidating infrastructure.

The IRM is closely linked with the other five reference models of the

Consolidated Reference Model Framework (CRM). At the high level, the IRM relationship and tie-in to the other reference models is illustrated in the following table:

Alliant 3 Draft Request for Proposal 15

Figure 7 - The Infrastructure Reference Model - (IRM)

Security Reference Model (SRM)

Security is integral to all architectural domains and at all levels of an organization. As a result, the SRM must be woven into all of the sub architectures of the overarching EA across all the other reference models and it must be considered up and down the different levels of the Enterprise.

Enterprise Architecture Governance is the perfect place for security standards, policies, and norms to be developed and followed, since it is an enforcement point for IT investments.

The SRM allows architects to classify or categorize security architecture at all scope levels of the Federal Architecture: International, National, Federal, Sector, Agency, Segment, System and Application. At the highest levels, the

SRM is used to transform federal laws, regulations, and publications into specific policies. At the segment level, the SRM is used to transform department specific policies into security controls and measurements. At the system level, it is used to transform segment controls into system specific designs or requirements. Each level of the SRM is critical to the overall security posture and health of an organization and/or system. The SRM helps business owners with risk-based decision-making to achieve security objectives by understanding the purpose and impact of security controls on business processes or IT systems.

Alliant 3 Draft Request for Proposal 16

Security integration across layers of the architecture is essential to ensure the protection of information and IT assets. Security must start at the business layer and work its way down to the application and infrastructure layers. At the high level, the SRM relationship and tie-in to the other reference models is illustrated below:

Figure 8 - The Security Reference Model - (SRM)

Linking security and privacy to agency enterprise architecture, including agency performance objectives, business processes, data flows, applications, and infrastructure technologies, ensures that each aspect of the business receives appropriate security and privacy considerations. Additionally, addressing security and privacy through enterprise architecture promotes interoperability and aids in the standardization and consolidation of security and privacy capabilities.

C.4 COMPONENTS OF AN IT SOLUTION

The Contractor shall provide Infrastructure and related services, applications and related services, and IT Management Services to support agencies’ integrated IT solution requirements.

In order to provide a common framework for defining and understanding the components of an IT solution, this section will refer to terminology included in the FEA and DoD IEA models. Usage of this terminology or structure is not required within individual Orders placed on this contract.

Alliant 3 Draft Request for Proposal 17

The Contractor shall promote IT solutions that support Federal Government operational requirements for standardized technology and application service components. This shall facilitate integration requirements for broad Federal

IT and e-Gov initiatives, as well as promote the sharing, consolidation, and

“re-use” of business processes and systems across the Federal government.

The Contractor shall promote the use of open-source solutions and open technology development where practicable to enable this re-use.

Within each section below, an overview of the contract solution and service offering is provided, followed by work to be performed relative to Order requirements. Components of an IT solution indicated in this Scope are not meant to be all-inclusive, but rather general indications of the types of services and goods within a given category. Other services and goods not listed, which adhere to the definition for each section, are also within scope.

C.4.1 Infrastructure

Infrastructure includes hardware, software, licensing, technical support, and warranty services from third party sources, as well as technological refreshment and enhancements for that hardware and software.

This section is aligned with the FEA/DoD IEA, which describes these components using a vocabulary that is common throughout the entire Federal government. Infrastructure includes complete life cycle support for all hardware, software, and services represented above, including planning, analysis, research and development, design, development, integration and testing, implementation, operations and maintenance, information assurance, and final disposition of these components. The services also include administration and help desk functions necessary to support the IT infrastructure. Infrastructure serves as the foundation and building blocks of an integrated IT solution. It is the hardware, which supports Application

Services and IT Management Services; the software and services which enable that hardware to function; and the hardware, software, and services which allow for secure communication and interoperability between all business and application service components.

Infrastructure services facilitate the development and maintenance of critical

IT infrastructures required to support Federal government business operations. This section includes the technical framework components that make up integrated IT solutions. One or any combination of these components may be used to deliver IT solutions intended to perform a wide

Alliant 3 Draft Request for Proposal 18 array of functions which allow agencies to deliver services to their customers

(or users), whether internal or external, in an efficient and effective manner.

C.4.1.1 Service Access and Delivery

These components are responsible for facilitating the end-to-end collection and distribution of data that is either entered or requested by a user. These components include all functions necessary to communicate in a client-server environment. Examples of these components include, but are not limited to:

● Web browsers

● Virtual Private Network (VPN)

● Remote Authentication Dial-In User Service (RADIUS)

● Peer-to-peer

● Section 508 compliance

● Hypertext Transfer Protocol (HTTP)

● File Transfer Protocol (FTP)

● Simple Mail Transfer Protocol (SMTP)

C.4.1.2 Service Platform and Infrastructure

These components include all functions necessary for processing and storing data. These components provide and manage the resources available for

Application Services. Examples of these components include, but are not limited to:

● Desktops, laptops, servers, mainframes, routers, switches, and printers

● Asynchronous Transfer Mode (ATM) and T1

● Digital Subscriber Line (DSL), Ethernet, Windows/UNIX, Java/.NET

● Web server/portal

● Database, data storage, data warehouse

● Software development tools

● Testing, modeling, versioning, and configuration management

Alliant 3 Draft Request for Proposal 19

C.4.1.3 Component Framework

These components consist of the design of application or system software that incorporates interfaces for interacting with other programs and for future flexibility and expandability. These components define higher level logical functions to provide services in a way that is useful and meaningful to users and other Application Services. Examples of these components include, but are not limited to:

● Digital certificates, biometrics

● Business logic: JavaScript, Visual Basic

● Data interchange

● Simple Object Access Protocol (SOAP)

● Resource Description Framework (RDF)

● Data management

● Structured Query Language (SQL), Open DataBase Connectivity

(ODBC), and Online Analytical Processing (OLAP)

C.4.1.4 Service Interface and Integration

These components define the discovery, interaction and communication technologies joining disparate systems and information providers.

Application Services leverage and incorporate these components to provide interoperability and scalability. Examples of these components include, but are not limited to:

● Messaging-Oriented Middleware (MOM)

● Object Request Broker (ORB)

● Enterprise Application Integration (EAI)

● Extensible Markup Language (XML)

● Electronic Data Interchange (EDI)

● Web Services Description Language (WSDL)

● Universal Description, Discovery, and Integration (UDDI)

C.4.2 Application Services

Application Services provide support for all applications and collaborative service capabilities. These services include support for developing and implementing enterprise and departmental-level applications. These applications may be “cross-cutting” in nature, with inter-related service processing components extending across/beyond the enterprise, or unique to a particular agency/department’s mission requirements.

Alliant 3 Draft Request for Proposal 20

The Contractor shall promote, to the maximum extent practicable use of commercially available technologies (e.g. Commercial Off-the-Shelf (COTS) and non-developmental items) to support Federal Government agencies’ IT solution requirements. The Contractor shall provide competencies to employ agencies’ EA as required by individual Orders, to support IT solutions development and implementation and alignment with the FEA.

Application Services include complete life cycle support, including planning, analysis, research and development, design, development, integration and testing, implementation, operations and maintenance, information assurance, and final disposition. The Contractor shall provide Applications

Services for systems required to support unique agency and departmental-level mission requirements, as specified in individual Orders.

These services include support for existing and/or new/emerging mission requirements.

The following paragraphs C.4.2.1 through C.4.2.8 represent either components of applications or capabilities which Application Services will support. Each particular area includes, but is not limited to, support for the described functions.

C.4.2.1 Customer Services

Customer Relationship Management (CRM): All aspects of the CRM process, including planning, scheduling, and control activities involved with service delivery. The service components facilitate agencies’ requirements for managing and coordinating customer interactions across multiple communication channels and business lines.

Customer Preferences: Customizing customer preferences relative to interface requirements and information delivery mechanisms (e.g., personalization, subscriptions, alerts and notifications).

Customer Initiated Services: Initiating service requests and seeking assistance from government agencies via online communication channels

(e.g., online help, tutorials, self-service, reservation/registration, multilingual support, scheduling).

C.4.2.2 Process Automation

Tracking and Workflow: Automated routing, tracking, and management of documents (e.g., process tracking, case management, and conflict resolution).

Alliant 3 Draft Request for Proposal 21

Routing and Scheduling: Automated distribution and scheduling activities

(e.g., inbound/outbound correspondence management).

C.4.2.3 Business Management

Process Management: Development and implementation of standard methodologies and automated process management systems, to facilitate agencies’ requirements for managing and monitoring activities surrounding their core business operations (e.g., change management, configuration management, requirements management, program/project management, governance/policy management, quality management, risk management).

Organizational Management: Collaboration and communication activities

(e.g., workgroup/groupware, network management).

Investment Management: Selecting, managing, and evaluating agencies’ investments and capital asset portfolios (e.g., strategic planning/ management, portfolio management, performance management).

Supply Chain Management: All aspects of supply chain management, from the initial sourcing phase through customer delivery (e.g., procurement, sourcing management, inventory management, catalog management, ordering/purchasing, invoice tracking, storefront/shopping cart, warehouse management, returns management, logistics/transportation).

C.4.2.4 Digital Asset Services

Content Management: Content development, maintenance, updates, and distribution (e.g., content authoring, content review/approval, tagging/ aggregation, content publishing/delivery, syndication management).

Document Management: Capturing, indexing, and maintaining documents

(e.g., document imaging, optical character recognition (OCR), document revisions, library/storage, review/approval, document conversion, indexing/classification).

Knowledge Management: Collecting and processing data from multiple sources and generating information to support business requirements (e.g., information retrieval, information mapping/taxonomy, information sharing, categorization, knowledge engineering, knowledge capture/ distribution/ delivery, smart documents).

Alliant 3 Draft Request for Proposal 22

Records Management: Administration of official government records (record linking/association, record storage/archival, document classification, document retirement, digital rights management).

C.4.2.5 Business Analytical Services

Analysis and Statistics: Applying analysis and statistics to examine/resolve business issues (e.g., mathematical, structural/thermal, radiological, forensics).

Visualization: Transforming data into graphical or image form (e.g., graphing/charting, imagery, multimedia, mapping/geospatial/elevation/global positioning systems (GPS), computer-aided design (CAD)).

Knowledge Discovery: Identifying and extracting information from multiple data source containing files stored in various formats (e.g., data mining, modeling, simulation).

Business Intelligence: Collecting information relevant to historical, existing, or future business needs (e.g., demand forecasting/management, balanced scorecard, decision support planning).

Reporting: Generating reports derived from single or multiple data sources

(e.g., ad hoc reporting, standardized/canned reporting, OLAP).

C.4.2.6 Back Office Services

Data Management: Creating, using, processing, and managing data resources

(e.g., data exchange, data mart, data warehouse, metadata management, data cleansing, extraction and transformation, data recovery).

Human Resources: Recruitment, training, and management of government personnel (e.g., recruiting, career development/retention, time reporting, awards/benefit management, retirement management, education/training, travel management).

Financial Management: Government financing and accounting activities (e.g., billing and accounting,…