Defense Travel System Web Application Hosting Request for Information

THIS IS A REQUEST FOR INFORMATION (RFI) ONLY. This RFI is issued by the Washington Headquarters Service Acquisition and Procurement Office (WHS/A&PO) solely for information and planning purposes; it does not constitute a Request for Proposal (RFP) or a promise to issue an RFP. This RFI does not commit the Government to contract for any supply or services. WHS is not seeking proposals at this time. Responders are advised that the Government will not pay any cost incurred in response to this RFI. All costs associated with responding to this RFI will be solely at the interested party’s expense. Not responding to the RFI does not preclude participation in any future RFP. If a solicitation is released, it will be issued via the Federal Business Opportunities website (www.fbo.gov). It is the responsibility of the potential offerors to monitor this website for any information that may pertain to this RFI. The information provided in this RFI is subject to change and is not binding on the Government. (a) The Government does not intend to award a contract on the basis of this solicitation or to otherwise pay for the information solicited except as an allowable cost under other contracts as provided in subsection 31.205-18, Bid and proposal costs, of the Federal Acquisition Regulation (FAR). (b) Although “proposal”, “contractor”, and “offeror” are used in this Request for Information, your response will be treated as information only. It shall not be used as a proposal. (c) This solicitation is issued for the purpose of gaining information to be used in determining the scope of future DTS contracts. This RFI is a part of Market Research in accordance with FAR Part 10, FAR 12.101 and FAR 12.202. Any proprietary information submitted in response to this RFI, if marked with a restrictive legend, will not be disclosed outside the Government or its support contractors except with the permission of the responder. 1.0 Background The Defense Travel System (DTS) is a paperless electronic web-based system that enables DoD employees to determine availability of and make reservations for transportation and lodging arrangements, and reimburses them through their financial institutions for out-of-pocket expenses. It also creates necessary financial transactions to provide funding for travel, identifies any deviations from the statutes and regulations governing DoD travel, and archives electronic versions of documents in accordance with regulatory and statutory requirements. It is the mandated system for DoD temporary duty travel, and currently handles more than 65% of all travel of this type. Operations and maintenance of the system, as well as development of new functionality, are provided by the prime contractor, Northrop Grumman Corporation. 1.1 Purpose of the RFI The purpose of this market research is to gain knowledge to determine if it is in the best interest of the Department of Defense to outsource applications hosting of the DTS, a web application predominately Java based, using Oracle RDMBS™ and containing some Progress™ 4GL code. DOD is continuing to modernize DTS and add additional functionality. Progress™ functionality is being removed from DTS and replaced with Java code using Oracle RDBMS™ as the data storage. 2.0 Requirements 2.1 Definitions Developer – either the Government or another contractor that develops and/or operates aspects of DTS. Contractor – the organization providing services to host the DTS application. Offeror – the organization responding to this RFI. 2.2 Key Feature The key feature DOD is seeking is high availability of service levels that are demonstrated by the current commercially available documented practices and existing client base. The winning contractor will have control over software product upgrades and changes to assure that service levels are maintained. This may be represented by stress testing, validation of Developer test records and any other documented practice the winning offeror may have in place as part of their existing business practices. Software development and maintenance will not be performed by the winning contractor. These efforts will be performed by the government or another contractor. The government is specifically seeking to divide the development and software maintenance from the hosting of the application. 2.3 Information Assurance (IA) The following IA requirements are expected to be in any RFP or contract related to this RFI. 2.3.1 Clearances The Contractor shall maintain a DOD Secret and Top Secret security clearance as requested by the Government. 2.3.2 Incident Reports The Contractor shall notify by phone the PMO Information Assurance Officer (IAO) and the Contracting Officer Representative (COR) all security incidents within one hour of the incident. Minor incidents shall be reported to the PMO in routine monthly reports. 2.3.3 Vulnerability Alerts The Contractor shall assess all Information Assurance Vulnerability Alerts (IAVA), taking immediate action to mitigate issues, and issue a written response within 5 business days. 2.3.4 Authorization to Operate The Contractor shall continue to maintain the current DTS Authorization to Operate (ATO) status. DTS is a Mission Assurance Category II, Sensitive (MAC II) system and its IA posture is maintained by implementation of the IA Controls of Department of Defense Instructions (DoDI) 8500.2, “Information Assurance Implementations” E4, Attachments A2 and A5. 2.3.5 System Accreditation The Contractor shall maintain DTS System Accreditation by continuously monitoring the DTS IA posture and through reviewing IA controls implementation and revalidation of those controls as dictated by significant system changes or yearly at a minimum. The contractor shall perform appropriate Phase Four Department of Defense Information Assurance Certification and Accreditation Process (DIACAP) tasks consistent with maintaining DTS accreditation such as: • Incorporating any new or modified IA Controls • Mitigating any identified security vulnerabilities • Conduct periodic vulnerability scan and penetration tests • Maintain information necessary to assist updating DIACAP Package and IA control Scorecard per the format and guidance contained at the DIACAP Knowledge website (https://diacap.iaportal.navy.mil/) • Executing DTS Plan of Action and Milestones (POA&M) actions 2.3.6 Metrics The Contractor shall provide a copy of all IA control metrics to IAO on a quarterly basis 2.3.7 Host Base Security System (HBSS) The Contractor shall maintain the Host Base Security System (HBSS) on DTS providing quarterly metric updates to the IAO or seek a waiver and support the waiver with documentation. 2.3.8 IAO Support The Contractor shall assist the IAO with updating the Enterprise Mission Assurance Support Service (eMASS) application by providing artifacts related to IA controls as requested by IAO. 2.3.9 Vulnerability Management System (VMS) The Contractor shall populate, maintain the Vulnerability Management System (VMS), and provide mitigation strategies for IAO review related to open items. 2.3.10 Security Investigations The Contractor shall comply with security investigations for privileged user as stated in DoDI 8500.2, E3.4.8 2.3.11 JTF-GNO Compliance The Contractor shall comply with Joint Task Force Global Network Operations (JTF-GNO) tasking orders and implement changes as required by the tasking orders or have obtained supported and obtained a waiver from these provisions. 2.3.12 Certification and Training The Contractor shall comply with technical certification and training as specified in Department of Defense (DOD) 8570.01-M “Information Assurance Workforce Improvement Plan, Change 1, 15 May 2008 through the life of the contract. 2.3.13 OMB Memorandum Compliance The Contractor shall comply with the requirements of Office of Management and Budget (OMB) Memorandum M-06-16, Protection of Sensitive Agency Information and Department of Defense (DOD) Memorandum of August 18, 2006, Subject: Department of Defense (DOD) Guidance on Protecting Personally Identifiable Information (PII). 2.4 The Current Environment The following sections provide a general description of the current DTS environment. In the event that a Request For Proposal (RFP) is prepared as the basis for a procurement action resulting from this RFI, a complete list of software and hardware configuration items will be included in the RFP. 2.4.1 Software DTS application software is developed and maintained under contract to the Government, and will be furnished, along with associated documentation (such as requirements and design documents, version descriptions, and test specifications and results) to the application hosting contractor as Government Furnished Equipment (GFE) or Government Furnished Information (GFI). All other software (operating systems, network management tools, performance monitoring tools, and other items required for application hosting) will be procured and maintained by the application hosting contractor. 2.4.2 Hardware The DTS hardware environment includes commercially available information technology and telecommunications equipment operating in a three-tiered architecture: a web tier, an application tier, and a database tier. Two environments are in operation; the primary one is used to support production (normal system operation), and the second is normally used as a training environment. In the event that the primary environment is unable to operate normally, the second is used as a fail-over to continue support of users. The hardware is currently located in data centers in the National Capital Area and will be provided to the application hosting contractor as GFE. 2.4.3 Network and Interfaces The application hosting contractor must establish and maintain the following network and system interfaces (currently in operation within DTS): • The DTS web portal for user access to the system; • Connection with the Defense Information Systems Agency (DISA) Non-classified Internet Protocol Router Network (NIPRNet); • Interfaces via the NIPRNet with • DISA Public Key Interface (PKI) for user access verification; • Defense Manpower Data Center (DMDC) Archive/Management Information System for archiving of electronic travel records; • DISA Global Exchange Service (GEX) to interface with DoD financial systems; • Interfaces via commercial networks or dedicated lines with • Government Charge Card Vendor; • Global Distribution Systems (GDS), Commercial Travel Offices (CTOs) and Travel Service Providers via OpenJaw for information on and reservations for travel arrangements; • ITA Software for commercial airline reservation information. 2.5 Operating Requirements The DTS services 2,069,032 people as of May 1, 2009. The projected user growth rate is about 2% per year. The system processes about 350,000 authorizations (travel orders) and 325,000 vouchers (requests for reimbursement) per month; the projected growth rate is 15% per year, with steady state being achieved sometime in 2011. DTS must be available 7x24x365 with maintenance periods limited to the vendor’s current published service levels. If commercially feasible and cost effective, zero down time for the system is the optimum standard service level. 2.6 Future Vision The Department of Defense will continue to add travelers and travel types to the Defense Travel System and may evolve the underlying technology to a Service-Oriented Architecture (SOA). Expansion of user base may extend to other than DOD so ability to maintain service levels for an expanding user base may be required and will be evaluated if this requirement moves to a procurement phase Future increases in functionality that the contract must plan for in cooperation with the Government and the Government’s development contractor(s) are Permanent Duty Travel (PDT), Military Entrance Processing System (MEPS) travel, Special Circumstances Travel (SCT), and other types of DoD travel as required to support a Congressional mandate for DTS to replace other, legacy travel systems within DoD. These increases in functionality are expected to take place as five major releases from fiscal year 2009 through fiscal year 2011. 2.7 Division of Responsibility The currently envisioned division of responsibility is discussed in this section. Responders are encouraged to comment and suggest improvements based on their experience. 2.7.1 Contractor Responsibilities The contractor shall: • Maintain the computing environment to achieve performance and availability requirements • Manage network connections to the established point of demarcation • Manage and maintain the operating system software • Manage and maintain all third party software including requesting patches and upgrades from the appropriate vendor • Perform the duties as Oracle Database Administrator (DBA). DBA responsibilities will transition from primarily a Developer function to the Developer acting as a backup DBA for critical corrections. This transition will be planned around the release schedule shown in Section 3.4. • Perform any other action in accordance with their standard practices or operating procedures to maintain the performance and availability requirements. 2.7.2 Government or Developer Responsibilities The Department of Defense or Developer will: • Maintain the data in DTS • Operate the applications of DTS • Develop and maintain DTS software • Approve dates, time lines and coordinate upgrades (software, hardware, telecommunications and any other change to any aspect of DTS) 2.8 Configuration Management The application hosting contractor will be required to manage the configuration of the system, to include the application software and all hardware and software in the operating environment. The contractor will provide training for individuals on their configuration management practices and systems as requested by the Government. The contractor will also be required to assist in and support the transition of configuration management information from the Developer to the contractor’s configuration management system. The contractor will function as the guarantor of the performance of the DTS system. As such, they will be in the role to recommend not fielding a patch, release or software change if it impacts performance of DTS. The government retains the right to direct implementation in which case the contractor will be held harmless for any negative DTS performance. 2.9 System Backup All environments and databases offered shall have data, source code, modified, configured environment(s) and machine readable code fully backed up weekly and incrementally daily or as per the contractors practices it they exceed these minimums. The contractor shall also deliver any other electronic files, software or other items necessary to restore the environments to an operational status. In addition, whenever the contractor changes configuration of hardware or other contractor owned or leased software, the contractor shall deliver these configuration changes to the Contracting Officers Technical Representative via email within a week of making any change. The backups shall be delivered weekly and daily respectively to a facility to be named by the Government on machine-readable electronic media to be proposed by the contractor or using file transfer methodologies. The contractor may not rely upon these backups provided to the Government for their operations. This provision is to ensure continuity of operations in the event the contractor defaults or ceases operation. This requirement must be separately priced. 2.10 Disaster Recovery The contractor shall show as separately priced items disaster recovery options to recover the DTS environment(s) (productions and development) fully operational (data, applications, and performance level) within: • No down time • Not more than 45 minutes • 24 hours The contractor shall also include the timelines for rollback to the production system once the reason for failover is resolved. The Government will have no role or responsibility for disaster recovery with the possible exception of validating network connectivity if connecting to the Government Network is not bid as part of the contractor offer. The Government may exercise annual unannounced disaster recovery assessments. Exercising disaster recovery will be separately priced and may not be procured. 2.11 Computing Performance The contractor shall maintain system response time(s) as proposed in their standard offering but must reflect a web page response time of less than 2 seconds. Documentation of system response time shall be reported to the Government on a periodic basis as contained in the contractor’s standard agreements. 2.12 Network Segment Performance The contractor shall maintain network response time as proposed in their standard offering. Documentation of network response time shall be reported to the Government on a periodic basis as contained in the contractor’s standard agreements. To achieve over-all system performance and response, the contractor shall assist the Government in assessing network performance and workstation performance issues outside of the contractor’s owned and operated network segments. The Government does not expect the contractor to actively diagnose and resolve problems outside the contractor’s owned facilities, but to team with the Government in analyzing and resolving system and network performance issues. 2.13 Transition of DTS to the Contractor’s Facility The contractor should address their standard transition strategy for movement of operational DTS to the contractor’s facility with no down time but not more than a 24 hour period of non-availability. 2.14 Performance Tuning The contractor would be responsible for all aspects of performance tuning to meet computing and network segment performance requirements as proposed as standard performance practice by the contractor. The single exception is of custom code developed by the Developer. The Developer will make the custom code available for review to the contractor to provide suggestions to improve performance When performance requirements are not being met the contractor shall take steps to restore performance. The contractor should address any cost to diagnose performance problems if the Government will agree to follow the contractor’s configuration management and change process. Following the contractor’s configuration management and change processing should preclude the vast majority of issues or identify up front any potential performance issues caused by the Government/Developer team. 2.15 Upgrade in Performance due to Increased Loading The Defense Travel System may grow in size and may service additional organizations in the Government. The contractor will show the cost for additional capacity as a separately priced service item. The Government also seeks to take advantage of new functionality in third party software in use. All of the possibilities can cause the need for additional storage, computing capacity, network usage and capacity and other factors. As the Defense Travel System is approaching its maximum data storage capacity, contractors’ proposals will include pricing for additional storage costs. The contractors shall provide as part of their proposal options and costs over the full life of this contract and for a lifecycle of 15 years from date of award, the cost to upgrade these components of the support services. 2.16 Incorporation of Standard Operating Processes and Policy The primary goals for this contract are: • To take maximum advantage of the economies of scale of an application hosting activity; • To capitalize on expert knowledge supporting multiple customers using web based applications with similar tool sets to DTS; • To reduce operating cost while increasing performance and availability. To achieve these goals the Government wants to take advantage of the existing operating process and policies of the successful contractor. For these reasons, we are seeking the best industry standard practices, performance standards, and measures to monitor compliance. The contractor shall propose any standard practice offered to their other customers that are missing from this contract. The contractor shall also clearly highlight where, in this contract, the Government is at odds with the contractor’s standard or optional practices or policies. In the event that the contractor modifies operating processes or policies during the performance of this contract, the Government will be allowed a reasonable transition period to adapt to the change, or elect not to adopt the change with no change in pricing. The contractor shall at no additional cost educate and/or train up to 10 Government staff for each particular change. 2.17 Operational Decisions and Facilities Access The decisions on operational issues, all non-availability periods, upgrades, software migrations and any risk assumed by the Government will be made by the Government. The Government staff associated with DTS support and operations shall have access to the contractor facilities that support DTS in accordance with the contractor’s standard practices. In no case shall the contractor deny the Government access to inspect the contractor’s facilities and practices to validate compliance with all contract terms. 3.0 Instructions for Responses to this Request for Information (RFI) Firms should respond to this Request for Information by addressing the topics listed below. The total page number should not exceed fifty (50) pages. Headings and topics may be consolidated when practical. Published offerings, pricing data sheets and any material which is evidence of standard offering will not be included in the page counts and should be reference by title page and paragraph. 3.1 The cover page will contain (1) Company name, (2) Primary point of contact and one alternate, (3) Phone Number and Email address, (4) Cage Code, (5) NAICS Code, (6) Small Business Category, if applicable, (7) Federal Supply Schedule (FSS), General Services Administration contract number, if applicable. 3.2 Corporate Experience: a brief description of your corporate experience in service to both commercial and government organizations. 3.3 Technical Capability: Based on the other information in the RFI, please provide evidence of a large customer base comparable to the DTS users. Good evidence will be demonstrated by published verifiable service offerings and a large customer reference base for web base application hosting. Include any published pricing and any estimate budgetary cost to provide services to operate DTS. The budgetary estimates will be protected by the government as proprietary to the organization submitting the estimate. Vendors are requested to provide evidence of their standard business practices relative to achieving the objectives below. Objectives: 1. Maintain the computing environment to achieve performance and availability requirements. May use the DTS Platform and/or Legacy Platforms. In the event the vendor uses these platforms the vendor shall bear the cost to move the platform(s) and pay any maintenance charges. If in the future the platforms cannot maintain service levels it shall be the vendors responsibility to upgrade the platforms at vendor cost. 2. Manage and maintain the operating system software. 3. Manage and maintain all third party software including requesting patches and upgrades from the appropriate vendor. 4. Perform the duties as Oracle Database Administrator (DBA). DBA responsibilities will transition from primarily the government support contractor to the government support contractor acting as a backup DBA for critical corrections. 5. Coordinate any change in hardware, network, software of any other change with the government. The government will have rights to defer the change. 6. Propose the standard transition strategy for movement of operational DTS to the contractor's facility with minimum down time. 7. Maintain and procure the connection to the Internet allowing connection to DOD network. 8. Manage network connections to DOD networks. 9. Provide connectivity that allows all sessions entering the DOD to be initiated from inside DOD networks. 10. Arrange a secure remote access solution to allow the government to monitor the DTS application and performance. 11. Provide a strong security solution to ensure the DTS external vendor hosting will provide security appropriate to the protection of privacy data and a corporate financial or banking application, while not compromising the integrity of the DOD networks. This will mean that the vendor must comply with DOD IA provision as documented in DOD instructions or seek a waiver of specific provision to maintain commercial provision equivalent to the DOD IA provisions. This may be the current security plan provided by the vendor to other customers. 12. Perform security audits, monitor for intrusion, while taking steps to prevent such intrusions. The vendor shall describe in detail how this security is to be provided. The vendor shall further describe how they would deal with cyber attacks in their current operating environment. Perform any other action in accordance with their standard practices or operating procedures to maintain the performance and availability requirements. 13. Provide disaster recovery options to recover the DTS (production and development) to fully operational status (data, applications, and performance level) for a minimum of these three options: a. with zero outage; N+1 solution b. within 4 hours c. within 24 hours 14. Provide at the government's option one unannounced disaster recover demonstration annually. 15. Provide a comprehensive system backup and disaster recover plan to provide 100% operating capability of DTS in the event of an outage of the primary instance of DTS. 16. Experience in supporting applications which access the DOD unclassified network for transmission of data and use of the DTS products. 17. Accept domain name services for DTS and keep them active and operating. 18. Provide the commercial pricing for additional users. 19. Provide pricing for incremental storage costs. 20. Provide performance tuning after delivery of additional functions implemented in DTS as indicated in this RFI and quarterly or less frequently as needed to maintain service level agreements. 21. Train up to 10 government staff in the standard business practices of the vendor after award of the contract to be schedule after award and anytime the vendor desires to change business practices impacting the government. 22. Provide the government a real time surveillance capability to monitor compliance with service level agreements and security measures. 23. Provide the government the capability to reestablish the DTS to the previous day's state (including all development and test areas) at another facility. This objective provides the government security in the event of the vendor ceasing business operations or in the event the contract terminates. If part of the vendor's solution includes providing media, hardware and software configuration items to other facilities, the government is ready to accommodate the need. This capability shall be in place at all times and for every configuration change. 24. Provide a estimated pricing for support staff needed to maintaining service level agreements and security. 3.4 Please address the following questions regarding Application Hosting: a. What are the options, releasable pricing (for planning and budgetary purposes), support service agreements and connection to the NIPRNET for: • Moving the current infrastructure to a service provider with the Government conveying title to the equipment and having system admin functions performed including OS level support, backup and user account administration at the OS level? • Providing the same capability using the contractor’s equipment to provide the functionality of the current infrastructure and have the capability to expand the environment in increments of user population? b. How do you increase capacity and charge for it when the customer needs more capacity or the application demands more from the infrastructure? c. How do you manage connections and help diagnose problems when you connect to customers’ private networks like NIPRNET? d. What are the applicable best practices in the application service provider and hosting markets? (Submit your existing product offerings in detail.) e. Provide evidence of a large base of custom developed web applications that you currently provide a “guaranteed” service level for through exercise of the Key Features the Government is seeking. f. How do you protect your customers in the event that you cease operations or the customer elects to move to another service provider? g. What suggestions do you have for improving the division of responsibility discussed in Section 2.7? h. What other factors should the DOD consider? i. Please comment on your compliance with or recommendations for the notional architecture depicted in Appendix 1. 4.0 Reference Documents: The following documents are provided to assist offerors in preparing their responses: Item Title Description (A) DTS System Overview dated June 20, 2006 Provides an overview of the basic components and structure of the DTS. (B) DTS Architecture Description, Version 2.0 dated 14 July 2005 Describes functional, logical, and physical architecture of DTS. (C) IDA Paper P-4200, Assessment of the Potential to Improve the Cost-Effectiveness of the Defense Travel System, dated March 2007 Reviews Defense Travel System and program and makes specific recommendations for usability and future functionality development. (D) DBSAE Notional Architecture (see Appendix 1) Provides view of recommended architectural approach Potential sources are invited to submit their response, as described above, to the “RFI Defense Travel System Web Application Hosting”. All responses should be submitted via e-mail address to [email protected] no later than 12:00 noon on July 17th, 2009. Only attach MS Word/Excel compatible files or Adobe Acrobat PDF files in electronic correspondence. WHS will not acknowledge receipt of responses to this RFI. If you have any questions please contact Jennifer Harmon at [email protected]. If you would like to arrange an alternate delivery method, please send an email to the above address. Primary Point of Contact.: Thomas S. Bordone Contracting Office Address: Washington Headquarters Services/Acquisition & Procurement Office 1700 N. Moore St. Suite 1425 Arlington, VA 22209 Attachments: Item Title Description (A) DTS System Overview dated June 20, 2006 Provides an overview of the basic components and structure of the DTS. (B) DTS Architecture Description, Version 2.0 dated 14 July 2005 Describes functional, logical, and physical architecture of DTS. (C) IDA Paper P-4200, Assessment of the Potential to Improve the Cost-Effectiveness of the Defense Travel System, dated March 2007 Reviews Defense Travel System and program and makes specific recommendations for usability and future functionality development. (D) DBSAE Notional Architecture (see Appendix 1) Provides view of recommended architectural approach