justification_and_approval_document_redacted.pdf

Justification and Approval (J&A) for Other Than Full and Open Competition

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

I. Contracting Activity.

The Air Force Life Cycle Management Center (AFLCMC), Business and Enterprise Systems Logistics Sustainment Contract Division (AFLCMC/HIAK), 4225 Logistics Avenue, Building 266, Room A212, Wright-Patterson Air Force Base, Ohio 45433-5006. The Contracting Officer (CO) is Mr. Jeffrey Conroy, DSN and the Program Manager (PM) is Ms. Debora Sharp, AFLCMC/HIAR, DSN

. The Purchase Request Number is forthcoming and requires Fiscal Year (FY) 2017-2019 funding. The Justification and Approval (J&A) local control number is AFLCMC/HIK-16-J011.

II. Nature and/or description of the action being processed.

The nature of this action is to justify a new contract, totaling three years and six months, sole source, to accomplish sustainment, maintenance and operations support for the Air Force Equipment Management System (AFEMS). The contract is a combination of Firm Fixed Price (FFP), Cost Plus Incentive Fee (CPIF), Cost Plus Fixed Fee (CPFF) and Cost Reimbursable (CR) Contract Line Item Numbers (CLINs).

Currently the AFEMS prime contractor, MacAulay-Brown, Inc. (MacB), provides the sustainment, maintenance and operations support for AFEMS. The sole source contract value will be $46,592,000.

III. Description of supplies/services required to meet agency needs.

The objective is to provide AFEMS maintenance, sustainment, and operations which include completing scheduled releases, testing, documentation, project planning, security engineering, and configuration management along with user support for the system utilizing 3400 Operations and Maintenance and 3600 Research & Development funds. AFEMS is a United States Air Force (USAF) automated system that manages all equipment at retail and wholesale levels throughout the USAF to meet peacetime and wartime mission requirements. AFEMS provides worldwide visibility of equipment and Information Technology (IT) assets. This includes current authorizations, forecasted authorizations, in-use assets, and in-place assets. It supports equipment budget requirements, procurement plans, and capital equipment asset reporting in accordance with the Chief Financial Officer (CFO) Act of 1990. It is an on-line interactive process with worldwide user connectivity. Data processed by AFEMS includes both classified (SECRET) and sensitive unclassified equipment information.

Work will be performed for three (3) years (one (1) base period (Feb 17 - Feb 18), two (2) one (1) year option periods (Feb 18 - Feb 19 & Feb 19 - Feb 20) and potentially a six month extension of services effort involving (Feb 20 - Aug 20) Financial Improvement and Audit Readiness (FIAR) and Modernization Computer System Requirements Documents (CSRDs) necessary to achieve a modernized secure information technology (IT) system.To ensure the system does not become inoperable, the Program Management Office (PMO) must complete five (5) technical CSRDs: 1) PacBase Conversion, 2) SUPRA Conversion, 3) Discoverer replacement, 4) Federal Data Center Consolidation Initiative (FDCCI) compliance and 5) Interface conversion to Secure File Transfer Protocol (SFTP). A sole source contract to the incumbent vendor will allow immediate startup of high risk technical releases.

AFEMS has five (5) CSRDs that enable AFEMS to continue to perform its mission requirements, remain on the Air Force (AF) Network, and prevent high risks from being introduced into the program.

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

First Technical CSRD: PacBase reached end of life in December 2015, with sole-source extended support available from IBM until the end of 2018. The PacBase programming language is obsolete and must be replaced with a modern, maintainable programming language for which future vendor support will be available. Due to the complexity of the effort the PacBase conversion effort is estimated to take two (2) years.

Second Technical CSRD: AFEMS currently uses Oracle Discoverer, a Commercial Off-the-Shelf (COTS) report generation tool, to support equipment management and financial reporting. Oracle Discoverer reaches end of life in June 2017, and the certificate within the software will cause the product to be inoperable 12 Nov 2017. The PMO has made numerous attempts to gain extended support/capability from Oracle, however, Discoverer is a COTS product, and Oracle has made the business decision to end the product. There is no work-around available. The effort to replace Oracle Discoverer is estimated to take approximately 1 year.

Third Technical CSRD: The SUPRA Database (DB) component of AFEMS must be replaced with a COTS product compatible with AF initiatives, such as FDCCI and CCE. AFEMS uses a COTS tool, SUPRA SQL, as the AFEMS mainframe DB. As AFEMS is translated from PacBase to a current programming language, SUPRA database must be upgraded to maintain AFEMS functionality. This must be accomplished in conjunction with PacBase in order to avoid significant technical risk introduced by mixing obsolete DataBase technologies with modern programming technologies.

Fourth Technical CSRD: FDCCI compliance is required by Sep 2018.

Fifth Technical CSRD: Federal Information System Controls Audit Manual (FISCAM) paragraph 4.3 and sub-paragraphs make Federal Information Processing Standard (FIPS) 140-2 encryption conformance an auditable item. AFEMS has 26 interfaces with 15 systems which utilize non-secure File Transfer Protocol (FTP) for data transmission. The interfaces must be upgraded to a FIPS-140-2 compliant implementation of Secure File Transfer Protocol (SFTP). New data transmission protocols will need to be documented for auditing purposes. The effort to encrypt all 26 interfaces is estimated to take one (1) year.

During the course of completing the above CSRDs, uninterrupted sustainment, maintenance, and operations of the AFEMS will be required. In addition, AFEMS anticipates the the effort o include, but not be limited to the following list of CSRDs.

1. CSRD 2015-06-7537 Capital Threshold Modification. This CSRD will ensure all depreciated values are accurately reflected in the Air Force financial statements which directly supports the OUSD(C) valuation priority. Anticipated duration 15 Months.

2. CSRD 2013-02-5783 Item Unique Identification (IUID)-Enabled Transactions to/from AFEMS.

This CSRD will allow IUID information for each base level support equipment asset to be passed to and from Integrated Logistics Support System (ILSS) and AFEMS. Anticipated duration 18 Months.

3. CSRD 2015-06-7542 Generate a Query to the IUID Registry and update AFEMS - IUID Registry Data Retrieval. This CSRD will allow AFEMS to process a query to the IUID registry to retrieve missing IUID information for existing equipment asset records (Support Equipment, IT Equipment, Internal Use Software, etcAnticipated duration 18 Months.

4. CSRD 2015-06 7506 AFWay to Asset Inventory Management (AIM) Interface. This CSRD will

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16 create an interface to retrieve asset information in a standard format from AFWay. Anticipated duration 12 Months.

5. CSRD 2015-06-7550 Encrypting Property Files for Common Database Login Account Passwords. This CSRD will enable AFEMS to properly secure login account passwords in accordance with FISCAM. Anticipated duration 12 Months.

6. CSRD 2015-06-7558 Maximum Allowed Quantity Calculation Error. This CSRD will ensure the proper Data Base tables are used to calculate the maximum allowed quantity. Anticipated duration 18 Months.

7. CSRD 2015-06-7557 Inventory Adjustment. This CSRD will allow pending departing/departed ECO tasks to be assigned to new ECOs and the actions can be completed at the user level.

Anticipated duration 15 Months.

8. CSRD 2015-06-7559 Unusable AIM User Acct Audit Data. Implementing this CSRD will ensure the history data is converted to a readable format and thereby auditable. Anticipated duration 12 Months.

9. CSRD 2015-06-7549 Interface changes to Interface Control Document (ICD) C001/ESB/Q310- A. Implementing this CSRD will feed Rejects, Variances, and Date of Last Inventory actions to Logistics, Installations and Mission Support-Enterprise View (LIMS-EV) Q310A. Anticipated duration 12 Months.

10. Classified Equipment Requirements Computation (CERC) D039 Modernization. This CSRD will implement all functionality of CERC using languages and technologies that support AFEMS compliance with all applicable DoD and AF regulations and initiatives, including but not limited to, the FDCCI, CCE, and Section 508 of the Rehabilitation Act of 1973. Anticipated duration is 12 months.

Other Sustainment, Maintenance and Operation services anticipated to be contracted include but are not limited to:

• Maintaining, sustaining, operating and modifying the AFEMS software application and infrastructure using documented software engineering practices.

• Migrating from Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) security control set to a Risk Management Framework (RMF) set of controls based on the National Institute for Standards and Technology (NIST).

• Performing System Security Authorization work to establish a secure baseline.

• Providing Help Desk support, problem analysis, and resolution for the AFEMS users.

• Performing the technical and functional activities at the contract level needed for the program management of this contract.

• Providing support to Integrated Process Teams (IPTs), the Functional Review Board (FRB), Component Validation and Integration testing, Test Readiness Reviews (TRRs), Qualification Test & Evaluations (QT&Es), Field Readiness Reviews (FRRs), and Technical Interchange Meetings (TIMs).

• Conducting Program Management Reviews and other status presentations as necessary to keep the PMO and other stakeholders abreast of system status.

• Delivering all documentation necessary to obtain the required data from system interfaces.

• Delivering all documentation in a final format for Government review, coordination, and approval.

• 60-day transition period for the orderly transfer of all items related to the maintenance of the

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

AFEMS to a new maintainer.

The estimated contract value will be $46,592,000.

The schedule of all requirements is depicted below:

SEE TABLE 3.1 - J&A CHARTS & TABLES

SEE TABLE 3.2 - J&A CHARTS & TABLES

IV. Statutory authority permitting Other than Full and Open Competition.

10 U.S.C 2304(c)(1), as implemented by Federal Acquisition Regulation (FAR) 6.302-1(a)(2)(iii)(B)

V. Demonstration that the contractor's unique qualifications or nature of the acquisition requires the use of the authority cited above (applicability of authority).

Sustainment, Maintenance, and Operations for AFEMS has been provided by MacAulay-Brown using contract FA8770-11-C-0023 awarded in Jun 2011, awarded via competitive procedures, will conclude 9 Feb 2017. This acquisition is for continued performance of a highly specialized service.

FAR 6.302-1(a)(2)(iii)(B) states that

“services may be deemed to be available only from the original source in the case of follow-on contracts for the continued provision of highly specialized services when it is likely that award to any other source would result in--

(B) Unacceptable delays in fulfilling the agency's requirements” In order to avoid unacceptable delays the AFEMS program requires a continuation of highly specialized services performed by MacB.

MacB is uniquely qualified to support this effort. MacB's personnel have over five years of specialized experience with software development tools and all environments specific to the AFEMS. MacB has significant experience with coding and maintaining PacBase, utilizing SUPRA, and coding Java. As PacBase coded screens are introduced in current requirements, MacB converts the outdated PacBase code to Java. This is the same type of PacBase conversion requirement required in this effort, however the conversions that have taken place to date are only a fraction of the total effort that needs to be accomplished. MacB has converted nearly 115 screens (approximately 15%) of the 750+ screens in AFEMS and therefore has specialized experience to complete the current conversion requirements. The antiquated hardware and software utilized in sustaining, maintaining, and operating AFEMS in the mainframe environment is increasingly disappearing from mainstream use. As such, the skillset necessary to meet the requirements of AFEMS draws upon a significantly reduced talent pool. The skills associated with PacBase and SUPRA are nearly impossible to locate and will be discussed in in Section VIII. MacB has the specialized staff to accomplish the upgrades to the antiquated and unsupportable software. A three year sole-source contract will allow for the technical and FIAR releases to be accomplished prior to the end of life and audit dates. Due to the current state of antiquated and unsupportable software and unsecure

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16 interfaces, the releases identified above must be accomplished for AFEMS to continue to function and provide global customer support. Loss of system capabilities will cause an eventual stoppage of direct mission support of wartime or contingency operations. If the contract is not approved, AFEMS will become partially inoperable in Nov 2017 due to the expiration of Discoverer capabilities. The only work-around requires significant man hours to manually generate reports, with the PacBase portion of AFEMS still becoming unsupportable on 1 Jan 2019, caused by a failure to complete. The inoperability would be caused by a failure to complete the necessary technical conversions and upgrades by the need dates: Oracle Discoverer (Nov 2017), the replacement of PacBase (Dec 2018), SUPRA DB replacement (Dec 2018), FDCCI Compliance (Sep 2018, extension waiver possible), and the conversion from non-secure FTP to SFTP. Should these releases not be implemented in accordance with the need dates, AFEMS confidentiality, integrity, and availability will become severely impacted.

This effort is needed so AFEMS can continue to meet the requirements of the AF. Extensive manual work around's would be necessary to manage equipment inventories, and would halt the AF's ability to do CFO reporting and Capital Asset Management. Further, the AF will be unable to implement the high risk technical releases that are urgent and vital to maintain the AFEMS mission, to enable compliance with FDCCI, and to prepare for CCE compliance. Without a PacBase replacement, AFEMS will be unable to maintain and provide access to accountable inventories. Support equipment will not be managed or allocated to the appropriate locations as needed to complete the base/MAJCOM missions. A failure of AFEMS would prevent accurate sourcing of support equipment and would lead to down-time of small arms, weapon systems, personnel, and all other supported platforms. Additionally, the potential to inhibit system maintenance is extremely likely.

The PacBase and SUPRA conversions must be accomplished prior to moving into a FDCCI compliant infrastructure because long term vendor support for both technologies is unavailable. This CSRD is estimated to take two (2) years and two (2) months and can be worked independently of and concurrently with PacBase and SUPRA conversions. FDCCI compliance cannot be fully achieved until both the PacBase and SUPRA products, which are not FDCCI compliant, are converted to compliant products, such as Java and Oracle, respectively.

Similarly, an AF Initiative compatible COTS replacement for the SUPRA database must be accomplished in conjunction with the PacBase conversion to ensure compatibility and prevent a significant amount of rework. The SUPRA database must be converted when PacBase conversions are completed to a current programming language (Java), otherwise AFEMS would have to support both a mainframe and mid-tier database. The interfaces required to transfer data between systems increases the processing time for data and would be an interim solution until SUPRA reaches end of life, as well as meeting FDCCI/CCE compliance requirements. The PMO, through discussions with SUPRA and market surveillance, believes that SUPRA support will rapidly conclude, primarily as a result of a declining market. Maintaining the SUPRA database in addition to the mid-tier which would host all PacBase converted code, would require additional expenditures of of software and hardware maintenance and an additional for SUPRA licenses and maintenance.

SEE TABLE 5.1 - J&A Charts & Tables

Additionally, failure to implement a satisfactory replacement for the report generation tool, Discoverer, would result in the loss of a significant number of both PMO-provided (700+) and user ad-hoc (1,500+)

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16 reports, as well as report creation and editing capability. Creating new reports and editing existing reports will no longer be possible. A loss of ad-hoc capability is expected to result in significant user workload and numerous requests for PMO development of reporting functionality. If this capability were to be lost, each user would have to mine data individually. As a single example, a current Aging Asset List sorted by Department of Defense Activity Address Code (DoDAAC) and Date Range is typically 30 pages of generated data, processed utilizing Discoverer in 5 minutes or less. If a report were to be generated manually it would require all 1200 assets to be viewed individually. The data obtained would then be manually transferred to a database and sorted, all of which would cause significant increases in man-hour expenditures and increase data entry error. If this process were to be undertaken to generate all the currently provided/created reports, the USG would experience a delay of nearly 308,000 (1200 assets x 2 screens x 1 minute average viewing duration x 3.5 reports weekly x 2,200 reports) man hours weekly.

Finally, if the SFTP upgrade is not executed, the confidentiality and integrity of AFEMS data transmitted across these interfaces is vulnerable and a denial of AFEMS ATO on the AF Network is a near certainty.

The effort required to accomplish the PacBase conversion is estimated to take two years, which necessitates the need to start no later than February 2017. Due to MacB's specialized services the efforts can start immediately with MacB and vendor teaming already established and with a proven, experienced staff already employed by MacB. MacB retains the highly specialized technical capabilities associated with coding and maintaining the antiquated programming language PacBase, SUPRA database, Discoverer functionality, and SFTP. These four technical inititives represent the most critical need requirements and if not completed will render AFEMS inoperable. They cannot be completed by any other vendor than MacB prior to the need dates outlined in Section III due to the market constrictions identified in Section VIII.

During the course of completing the above CSRDs, uninterrupted sustainment, maintenance, and operations of the AFEMS will be required. Due to AFEMS being an Information Technology (IT) system where the developer maintains the development and test environments along with the system baseline, another contractor maintaining the system would add significant risk to the completion of the releases.

Coordinating the development and sustainment zone between two contractors is not feasible due to the constant change levied upon IT environments. The USG would have to provide both vendors identical development and test environments, which would cost for hardware and software, if only one environment had to be purchased. Due to compatibility issues with hardware, software and operating systems, it is likely that both vendors would need new environments. In addition, when a new development environment is stood up, it would require a significant number of hours to test to ensure compatibility. The contractors would have to enter into Associate Contractor Agreements (ACAs), which can take up to a year to solidify. Having two contractors within the same development/test environments can lead to discrepancies in whom is responsible for problems that arise during performance. MacB sustainment, maintenance, and operations will ensure the users continued access to information necessary for uninterrupted continuation of day-to-day business without a loss of system confidentiality, integrity, and availability.

The highly specialized services MacB possesses will be primarily positioned to complete the complex conversion associated with the tasks above. MacB has the capability to augment staff, or gain additional resources to facilitate completion of the less complex requirements of FIAR and general sustainment, maintenance, and help desk. Market research determined that the market for PacBase and SUPRA resources is severely limited due to the antiquated nature of PacBase, Discoverer and SUPRA. Discoverer modification can begin and attempt to meet the Nov 2017 date required, without additional delays.

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

In addition, MacB currently houses the AFEMS development and testing environments in their facilities in Beavercreek, OH. They also operate the staging and production environments located in Building 271 at Wright-Patterson AFB. Without MacB to support operations on a 24/7 basis, a simple power surge could make the system inoperable without someone to bring the system back up in accordance with the detailed Operating Work Instructions (OWIs). PMO staff does not have the qualifications or the skills (proper certifications to be an administrator) required to accomplish these operational tasks in a timely fashion.

Even utilizing the OWIs to bring the system back on line would cause significant delays due to the learning curve associated with reading and understanding the sequence to bring multiple servers and mainframes on-line. There are also risks of voiding warranties and maintenance/support agreements during this process.

The delays associated with a new contractor's capabilities ramp up would drive a break in service and would interrupt the AFEMS mission. The lack of PacBase and SUPRA resources in the marketplace would drive extended delays in the ramp-up process of any other contractor. After completion of the PacBase and SUPRA conversions to more mainstream, current, common languages (Java and Oracle), will drastically increase the competitive pool and will remove the barrier to transition at contract start. Any break in service, whether a day or a month, would be unacceptable.

Based upon the likelihood of another vendor being unable to immediately begin on the high risk technical requirements (CSRDs), AFEMS will become inoperable. The complexities of the system necessitate a minimum of a 60 day transition period between the incumbent and any other source. The incumbent currently maintains the contractor development environment (hardware, software and facilities) in their facility which would necessitate a transfer of knowledge of the AFEMS unique aspects of the tools and utilities utilized to manage AFEMS. Based upon the likelihood of a critical development timeline, an award to any source other than the incumbent is impractical and would result in unnaceptable delays to the Air Force's ability to keep AFEMS functional.

Accordingly, MacB is the only firm capable of providing the services described in Section III above without the USAF experiencing unacceptable delays in fulfilling AFEMS requirements.

VI. Description of efforts made to ensure that offers are solicited from as many potential sources as practicable.

Market research was conducted with the NETCENTS-2 Application Services Small Business vendors to determine whether or not there is reasonable expectation of receiving offers from at least two small business companion contractors. The NETCENTS-2 PCO has already determined that the twelve (12) NETCENTS-2 Applications Services vendors were qualified to accomplish any requirement that falls within scope. A Request for Information (RFI) was issued via the AFWAY web site to all 12 of the NETCENTS-2 Application Services Small Business contract holders on 5 Mar 2015. Responses were received from Three (3) vendors:

There were six (6) vendors who declined to respond, of which two (2) expressed desire to propose on the official Request for Proposal (RFP) when released. Three (3) vendors did not respond negatively or positively.

In addition to the RFI, a draft Request for Proposal (RFP) was released on 28 Dec 2015 (RFQ ID number:

136386). The Draft RFP included the planned Computer System Requirements documents (CSRDs), planned period of performances for CSRDs and CLINs, planned CLIN structure, and planned contract type.

The draft RFP also included draft CDRLs, PWS, TDP, ITO, Evaluation Criteria, and PWS to CLIN Matrix.

Written responses were received from three (3) vendors:

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16 acknowledge receipt of the draft RFP, stated they had no questions concerning the documents released and that they planned to propose when the final RFP was released.

expressed desire to propose when the final RFP is provided and asked two (2) questions.

provided a document that contained twenty-four (24) comments and questions pertaining to the Draft RFP.

On 28 Jan 2016, responses to the twenty-six (26) comments/questions were released by the Contracting Officer (CO) to all 12 NETCENTS-2 vendors.

After the first notification of AFEMS as an upcoming acquisition in the BES SmartGuide and postings of the RFI and draft RFP, the AFEMS PMO had several one-on-one meetings with various vendors, associated potential teaming partners and product providers which include:

The focus of the one-on-one sessions was the vendors informing the USG of their capabilities and strengths, and to glean information about the USGs plans to accomplish the technical CSRDs and FIAR requirements outlined in the RFI and within the PoPs identified in the draft RFP. During these meetings, said that PacBase conversion was at least a 2 year effort, and they also believed that doing that effort while accomplishing other functional requirements is high risk, but executable. After making this statement, requested that we provide the PacBase and COBOL code with the RFP, however, we informed them that the code for AFEMS cannot be provided to industry because AFEMS is a National Security System (NSS). As a result of the USG's inability to provide the code, noted that it would be nearly impossible to provide an adequate technical solution and cost/price the effort without access to the code and made additional unsuccessful efforts through the PMO chain to gain access to the requested code.

During the three year performance the technical release CSRDs are expected to be completed within a minimum of 28 months. The remaining 8 months provides adequate schedule to ensure completion of all technical CSRDs and mitigates risk for unknown schedule delays. This also provides adequate schedule to complete a competitive Contract Award with stable requirements included in a completely documented Technical Document Package (bidders library) as a result of technical release completion. This follow-on contract will be awarded via competitive action. In accordance with FAR 5.201 a synopsis will be required.

VII. Determination by the Contracting Officer that the anticipated cost to the Government will be fair and reasonable.

The Government's cost proposal evaluation will be based upon government estimates and historic cost information from the incumbent's current contract performance and other similar contracts where this similar type of work has been accomplished. AFLCMC/HIAK will utilize price analysis, cost analysis, and certified cost or pricing data and AFLCMC/HIAR will provide a technical evaluation of the proposed effort and mix of labor types and quantities to determine the proposed solution for this effort is fair and reasonable.

The savings associated with moving AFEMS off the mainframe will be realized in year three of this effort.

If SUPRA conversion is not completed under this effort, it would require an additional 14 months of effort during the next contract effort. As such, the realized savings by avoiding the of cost of maintaining two hosting locations (mid-tier and mainframe) without any escalation totals

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

VIII. Description of the market research conducted and the results, or a statement of the reasons market research was not conducted.

In 2014, the AFEMS PMO performed internet searches for information about conversion from PacBase to other languages. These searches found only sales material for products and/or services to do the conversion with one exception: The Ohio Department of Public Safety Information Technology Office Exodus Project.

From Mar 2016 through Apr 2016 several emails and phone calls between AFEMS PMO and Ohio Bureau of Motor Vehicles (BMV) yielded several technical papers concerning the Exodus Project. The BMV partially outsourced the ongoing maintenance of their PacBase code, and they hired contractor personnel for staff augmentation. The BMV used organic talent to redesign and develop replacement systems. The BMV has a service that is basically a services “body shop”. The “body shop” was provided the skill set (i.e. PacBase) and the “body shop” department notified hundreds of contracting firms seeking capable resources. The BMV accomplished the effort in phases. Phase 1 of the project (conversion of PacBase to COBOL running on Windows based servers) took approximately 58 months and approximately 84,500 man hours for more than 1.5 million lines of PacBase Code (AFEMS has 1.3 million lines of PacBase code). Phase 2 (rewrite of system into .NET technologies) is ongoing and the target programming language is C++. As of early Mar 2016, phase 2 was approximately 40% complete. The database the BMV converted was Legacy database, which is a Unisys proprietary database called Data Management Service (DMS). The DMS product is only available from Unisys and only runs on Unisys mainframes. The target database is MS SQL Server. The BMV did not use a code conversion tool. COBOL code was captured from the PacBase pre-compile step and the COBOL was transferred to Windows based servers and compiled there. When errors were found, they went back to the original PacBase on the mainframe and modified the PacBase code to produce COBOL that would compile on the Windows platforms. The conversion to a more modern language will be done as part of phase 2 of the project. The database conversion took less than 2 years. Their database has roughly 2000 tables and 80,000,000 records, where AFEMS has roughly 600 tables and 33,000,000 records.

As a part of market research, the AFEMS PMO performed a search of resumes posted on Indeed's website (http://www.indeed.com) to determine the current marketplace for the skillset required to complete AFEMS requirements. Indeed.com is an American worldwide employment-related search engine for job listings launched in November 2004. Analysis of the data obtained via the research shows the following:

• There is a very limited resource pool with any PacBase experience and an even smaller pool with recent PacBase experience

• There is a very limited resource pool with any SUPRA experience and an even smaller pool with recent SUPRA experience

• There is a large resource pool for Java with recent Java experience

Both searches for PacBase returned 23 resumes. Both searches for SUPRA returned 34 resumes. The two sort orders for each keyword returned the same results, in different orders. Using the keyword Java, both sort orders reported 3744 total resumes but would only display the first 1000 individual resumes. No effort was made to determine if the resumes for each sort order returned the same 1000 resumes.

In addition, the AFEMS PMO staff performed a search of resumes posted on indeed (http:// www.indeed.com) to gather information nationwide. Nationwide was not an option in Indeed, but worldwide was, so the PMO reviewed the data to extract USA numbers. The search parameters were as follows:

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

Keyword Location Distance from Dayton Sort Order PacBase Dayton, OH No limit Relevance PacBase Dayton, OH No limit Date SUPRA Dayton, OH No limit Relevance SUPRA Dayton, OH No limit Date Java Dayton, OH No limit Relevance Java Dayton, OH No limit Date

PacBase: Worldwide there are 436 resumes containing the word PACBASE, with 367 from the USA and assumed to be US citizens. Of the 367, 221 of the USA resumes have not been updated in more than a year meaning they are not actively looking for a new job. That leaves 146 possible candidates nationwide.

SUPRA: Worldwide there are 4496 resumes with the word SUPRA on them, but the website will only present the first 1000 resumes. Of the 1000 resumes that could be scanned, 77 are Information Technology related, virtually all the rest are healthcare related (there is a medical COTS product named SUPRA). Of the 77 resumes that are IT related, 72 are from the USA and assumed to be US citizens. Of the 72 USA resumes of the USA resumes 37 have not been updated in more than a year meaning they are not actively looking for a new job. That leaves 35 possible candidates nationwide.

Java: Worldwide there are 549,804 resumes with the word Java on them, the website will only present the first 1000 resumes. Within the sheer number of candidates, it is assumed that there are suitable candidates that are in the area or are willing to move, are capable of obtaining the required government clearance, and will work for the prevailing salaries in this area.

For the PacBase and SUPRA searches, individual resumes were examined to determine the following additional information:

• Individuals present position title

• Last experience date on resume

• Date of the last use of PacBase or SUPRA (depending on the search keyword)

• Years since PacBase or SUPRA use (depending on the search keyword) (calculated)

• Years since resume was updated (calculated)

• Years since resume was updated with removal of current AFLCMC/HI, incumbent contractor, and other known WPAFB resources (calculated)

• Years since PacBase or SUPRA use (depending on search keyword) with removal of current

AFLCMC/HI, incumbent contractor, and other known WPAFB resources (calculated) (calculated)

Below are the tables to demonstrate the findings from the research conducted:

SEE TABLES 8.3 : 8.8 - J&A CHARTS & TABLES

In addition, the USG did internet research to determine the market of second generation code skills and ability to obtain individuals/companies with the qualifications to make the necessary upgrades (PacBase/ SUPRA/Discoverer) to AFEMS. The USG polled 3 popular recruiting sites (Monster.com, [ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

CareerBuilder.com, and Indeed.com) for current job postings pertaining to code used in AFEMS: Java, COBOL, SUPRA, and PacBase. This inquiry produced the results in Table 8.9. Without a market place for skills, applicants will not obtain those skills. As evidenced in the table below, there is no market for PacBase and SUPRA. Finding qualified personnel for the PacBase and Supra conversions is severely limited.

SEE TABLE 8.9 - J&A CHARTS & TABLES

The information contained in Table 8.9 shows that there is not a market for individuals that have PacBase and SUPRA skills. These two products have been obsolete for years, and are at end of life. To accomplish those tasks, a vendor needs individuals who have an understanding of the products. As demonstrated in the table, the market for PacBase and SUPRA is slim as compared to the products on a modern system (Java).

Consequently, market research shows that a significant number of qualified PacBase and SUPRA skilled employees already are working for MacB.

IX. Any other facts supporting the use of Other Than Full and Open Competition.

The AFEMS PMO experienced unforeseen delays which could not be anticipated in completing activities associated with the AFEMS follow-on NETCENTS-2 competition, which resulted in the need for this 3 year sole source contract. Due to AFEMS slated to be in Increment 1 of Expeditionary Combat Support System (ECSS), AFEMS funding was cut to support "below barebones maintenance" and ECSS was canceled in 2012. From 2007 to 2010, the functional system owners for AFEMS were only authorized to approve requirements that kept the system in its existing functional state (e.g., defects, TCNOs, etc.). They were not authorized to approve any enhancements (e.g., functional process updates, system upgrades, modernization, etc.). These rules of engagement continued until ECSS was discontinued. It was not obvious to the function system owners that without IT advances AFEMS would become stagnant with the aging code becoming more obsolete as every year passed. After ECSS was cancelled, a strategic decision was made to accomplish FIAR requirements in lieu of technical upgrades. However, in hind sight, the strategy was backwards. AF/A4L should have prioritized technical upgrades (like PACBASE Conversion, SFTP, Customer Information Control System (CICS)/zOS (IBM Mainframe Operating System), etc.) ahead of FIAR requirements. If AFEMS system operated on more modern technology, the FIAR requirements may have been easier to implement in time to meet FIAR assertions.

In addition to the ECSS events, AFEMS experienced a significant loss of Security knowledge and experienced a high rate of Information System Security Officers (ISSOs) & Information System Security Managers (ISSMs) turnover. The lack of security professionals (ISSM and ISSOs) resulted in an Authority to Operate with Conditions (ATOC) for Release 9.3 and one year to clear those conditions. The PMO was unable to act upon security deficiencies due to lack of personnel with the appropriate security certifications to accomplish the required tasks. Consequently, all subsequent releases began to stack up. The difficulties caused by the Oracle 9.3 delay resulted in additional time and effort required from the PMO, the sustainment contractor, and the Security Control Assessor (SCA) team. All the problems have affected the PMOs ability to obtain an ATO and continue to put the ability to obtain future ATOs at risk. AFEMS is unable to accomplish releases until a secure baseline is achieved, and a new ATO granted. Another effect of the schedule compression is that some of the underlying products upon which AFEMS is constructed have now reached end of support or end of life (zOS, CICS, ORACLE discoverer). zOS and CICS (Mainframe Middleware) are currently being accomplished and are scheduled to complete by 30 Sep 2016.

[ Enter security markings here -- or delete this text. ]

[ Enter security markings here -- or delete this text. ]Updated: 15 Mar 16

These products must be replaced or upgraded just to keep AFEMS running. The inability to upgrade to supportable products has introduced addition Category (CAT) I security vulnerabilities which, in turn, increases the scrutiny of the security accessors, the amount of security testing and documentation required, creating a self-propagating cycle of delays causing security issues, which cause additional delays.

X. List of sources, if any, that expressed interest in the acquisition.

See section VI above.

XI. A statement of the actions, if any, the agency may take to remove or overcome any barriers to competition before making subsequent acquisitions for the supplies or services required.

This J&A covers the period of performance 10 Feb 2017 - 09 Feb 2020 (if the Option to Extend Services is used, the ending PoP of 9 Aug 2020). The follow-on effort will be obtained via a competitive action. The planned award date for the follow-on effort is 9 Nov 2019, with a start date of 9 Dec 2019, to allow for a 60 day transition to a new vendor. The USG anticipates the upgrades accomplished under this effort will increase the competitive pool for future acquisitions. Following modernization conversion, and the Supra to Oracle conversion will remove competitive barriers associated to the antiquated products used on AFEMS today.

XII. Certification by the Contracting Officer.

As evidenced by my signature above, I have determined this document to be both accurate and complete to the best of my knowledge and belief.

XIII. Certification by the technical/requirements personnel.

As evidenced by my (our) signature(s) above, I (we) certify that any supporting data contained herein, which is my (our) responsibility, is both accurate and complete.