SOURCES SOUGHT
D -- Windows Development Production Environment
- Notice Date
- 4/2/2007
- Notice Type
- Sources Sought
- NAICS
- 511210
— Software Publishers
- Contracting Office
- Social Security Administration, Office of Budget, Finance, and Management, Office of Acquisition and Grants, 1st Floor, Rear Entrance 7111 Security Blvd., Baltimore, MD, 21244, UNITED STATES
- ZIP Code
- 00000
- Solicitation Number
- Reference-Number-SSA-RFI-07-1003
- Response Due
- 4/16/2007
- Archive Date
- 5/1/2007
- Description
- The Social Security Administration (SSA) currently operates a large enterprise-level Development and Production Environment (DPE) for SSA?s computer applications that are hosted on IBM mainframe computers running the IBM z/OS operating system and Sun Microsystems computers running the Solaris Unix operating system. SSA?s DPE consists of six separate environments?each configured with hardware, software, data and procedures necessary for an application to transition from one environment in the DPE to another. At SSA, a computer application can be viewed as transitioning through the following six environments: 1. Pre-Development?This is a separate environment for testing new versions of (or major changes to) the operating system and essential infrastructure software (systems software, system management tools, developer and System Development Life Cycle support tools, etc.) prior to their implementation in the Development environment. Pre-development testing is performed by SSA personnel and contractors who report to SSA?s centralized IT development support component. 2. Development?This is the environment in which developers create or modify an application and then perform unit and team testing on that application. Development testing continues until the application is ready for Validation testing (i.e., is stable and provides the target functionality for the current application release). Development testing is performed by SSA personnel and contractors who report to SSA?s centralized IT application development and SSA?s centralized IT development support components. 3. Validation?This is the environment where an application is subjected to testing by independent (non developer) groups in SSA?s centralized IT application and IT support components such as: specialized testing teams, requirements analysts, and by select end user representatives. Validation testing is intended to verify that the functional requirements for this release of the application are met and there are no adverse effects. SSA?s Validation environments do not generally support stress testing. 4. Integration?This is the environment where an application is subjected to integration testing in a production like environment. The integration tests are performed by independent testers who report to SSA?s production data center component. The integration testing environment is focused on testing applications with production versions of infrastructure software and other applications that will co-exist with the subject application in the production environment. This is to ensure that the subject application software: a. Runs normally (does not crash/abend) and produces expected outputs. This includes its interactions with other transactions and/or associated batch work b. Can co-exist with other applications in the shared application server target environment, an example from the J2EE environment is that the application uses the standard Java Runtime Environment. c. In appropriate situations, will process data at projected transaction throughput rates (this may involve stress testing of the application). 5. Training?This is a separate environment where end users learn how to use an application prior to implementing it in a production environment. It is used when major new applications or major modifications to existing applications make it advisable to deploy an application that has passed through integration testing in a pre-production environment for hands-on end user training prior to going into the production environment. 6. Production?This is the target ?live? environment for all application development efforts where an application will be hosted with full scale data center 24x7 support, service level agreements, etc. Each of the above six environments is supported with the hardware, software, data, procedures and staff personnel that are necessary for SSA?s applications to progress through the life-cycle steps associated with that environment. In addition, each environment includes procedures that identify the steps that need to be performed for an application to transition from that environment to the next environment. Although SSA has a structured DPE, SSA does not currently have such an environment set up for the development, testing and operation of its computer applications, relative to these applications being hosted on an x86 or Itanium2 server system platform running the Microsoft?s Windows Server operating system. At this time, SSA is considering the feasibility of operating an enterprise-level Windows Development and Production Environment (WDPE)?with the same operational and management process as is currently being used within the DPE computing infrastructure?adding a 3rd enterprise development and production environment to SSA?s existing mainframe and UNIX system infrastructure. This Windows/x86 or Windows/Itanium2 WDPE is being considered for production class deployment of both select COTS, as well as SSA custom developed or modified applications. As with the current DPE, it is expected that the WDPE will consist of a sequence of environments?each configured with the hardware, software, data and procedures that are necessary for a Windows Server based application to transition from one environment to the next. Initially this environment will be used to develop, validate, integrate, performance test and host: 1. COTS applications of a departmental scope which require full data center support ? monitoring, Service Level Objectives, backup and recovery, business continuity, integration with enterprise security. 2. COTS applications which are enterprise level in scope. SSA does not expect that applications which are the most demanding in terms of scalability, criticality (Core applications) or reliability will initially be hosted in the Windows Environment, but that SSA will grow towards that capability over a period of several years. 3. COTS packages or applications developed by SSA employees or contractors which support application development (SDLC support tools). 4. Applications developed by SSA personnel or contractors which need to access other production data, be integrated with enterprise security and require full data center support. SSA is seeking a vendor who is familiar with highly scalable enterprise DPEs that has experience in defining, planning, developing and implementing highly scalable centralized WDPEs in geographically dispersed organizations with large numbers of end users. SSA has approximately 65,000 personnel in its District Office and Disability Determination Service locations, most of whom interact with SSA?s production applications on a daily basis and continuously throughout their working day Additionally, it should be noted that some of the developers who will use the WDPE will be in distributed locations across our nationwide network. Service Areas In particular, SSA is looking for vendors that will be able to provide the following services to SSA: 1. Appropriately identifying the hardware systems architecture for each environment in the WDPE. This will include, but not be limited to identifying/ recommending: a. server types (i.e. Database Server, Application Server, Web Server) b. application performance scalability requirements c. appropriate server hardware/operating systems for enterprise applications (e.g., enterprise-class blade server architectures, x86/x64 servers, Itanium2-based servers, running a, 64-bit edition of a Windows Server operating Systems, use of Windows Server Enterprise Edition) d. a full and comprehensive server virtualization product stack (please include all aspects of a virtualization environment, including the system management requirements required to best optimize the feature/functions of the virtual machine environment e. workload balancing across and workload management within servers f. a full and comprehensive storage virtualization product stack 2. Identifying the software architecture for each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Groupware/ tools for collaborative development b. Modeling tools for application development c. Application Development Tools / IDEs d. software debugging tools ? developer oriented e. software testing tools ? developer oriented, f. software tools for validation/quality assurance g. code coverage/code analysis tools, h. data sanitization tools for data containing Personally Identifiable Information i. load testing tools j. capacity modeling tools k. software monitoring tools l. software repository and version tracking tools m. software release / software migration tools n. performance analysis software o. environment management tools 3. Identifying the network and security considerations for each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Physical design b. Impact and interaction with existing infrastructure and other lifecycle phases c. Appropriate separation of environments to provide for isolation of testing when appropriate, and protect production from developmental activities NOTE: SSA currently has a Microsoft Active Directory (AD) environment with separate forests for development and production. It also has a nationwide network connecting its main operational centers, regional offices and payment centers to its Baltimore-based development and production data center. ?Windows? programmers at these centers generally do not develop applications for SSA?s DPE. The WDPE could potentially add significant numbers (100?s) of developers from these operational centers to the centralized WDPE platforms. The network impact of adding these developers to the Baltimore development facility is unknown. Additionally, these developers are not currently members of the developer AD forest 4. Identifying security procedures for each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Integration of Windows Active Directory platform security with IBM mainframe system security (CA Top/Secret) b. Security configurations to meet government mandates and industry best practices which would include: (1) Sarbanes-Oxley and other governing federal laws (2) NIST guidelines (3) Industry best practices (4) Appropriate access controls to mitigate risk 5. Identifying capacity requirements for each environment in the WDPE. This will include, but not be limited to identifying/ recommending: a. failover procedures and best practices to achieve reliability 6. Identifying how to monitor the performance for each environment in the WDPE. 7. Identifying back-up and recovery procedures for each environment in the WDPE 8. High Availability/Failover Strategy. Propose a strategy for assuring High Availability and for efficient Fail Over. 1. Describe the products and services relative to server host-based fail-over and fail-back strategies for the proposed server systems. 2. Identify the up-time metrics and/or service levels for which the vendor services organization(s) will commit to in a services contract. 3. Describe how the High Availability strategy will foster 365/24/7 availability. 9. Identifying physical facilities requirements for each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Space b. Power and backup power c. HVAC d. Physical security 10. Identifying staffing requirements (e.g., skill sets and numbers of people needed) for setting up and maintaining each environment in the WDPE. This will include configuration recommendations in terms of Vendor and agency personnel. 11. Identifying policies, procedures, best practices and enforcement mechanisms that will be required for each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Architectural standards / reference architectures to ensure applications are designed and developed to be scalable and fault resilient. b. Recommendations on the typical projects that is used to pilot this type of environment c. Strategies to guide selection and development of future enterprise applications targeted for Windows production. d. Recommended approaches towards use of Open Source Software (OSS) on Windows e. Recommendations regarding specifications and guidelines for COTS targeted for enterprise support. e.g.: f. COTS installation specification requirements, to ensure COTS doesn?t require dedicated servers g. COTS packages that require embedded or proprietary databases, associated tools, or data formats h. COTS packages that include or require Open Source or freeware i. Procedures for acceptance of new or additional tools j. Database standards and guidelines k. Administrative guidelines and standards to ensure adequate security throughout the Software Development Lifecycle (SDLC). 12. Developing a time-phased plan with auditable checkpoints that identifies the strategy for establishing each environment in the WDPE. This will include, but not be limited to identifying/recommending: a. Initial and out year consultant support staffing estimates, by area of specialization. b. Training estimates needed for the development and production support staffs and if applicable, users of the WDPE. 1. Describe the education and training strategy that will assure SSA of its internal capability to support the proposed server systems. Be specific to: 2. Operating system 3. System management 4. Network management 5. Security features and facilities 6. Virtualization 7. High Availability/Cluster Systems software 8. Knowledge transfer from vendor operations 9. Training certifications if applicable. c. Strategies for developing a successful ?ramp up? schedule that moves from creation of development environment, selection of pilot projects, to production maintenance capability. SSA?s Current Centralized (Departmental) Windows Application Hosting Environment This information is presented only to give a frame of reference to SSA?s current Windows application environment. SSA?s current centralized Windows application hosting environment supports applications of a departmental nature. Business unit or IT development teams deploy applications to this environment directly, without benefit of a formal SDLC process. This environment is not considered an enterprise class production environment (not 24/7 data center support, no defined Service Level Objectives, not integrated with enterprise security, has no access to production data). Other Background Information SSA?s current production Database environment includes support for Oracle 10g and DB2 v7.2 for z/OS. Note: SSA does not at this time plan to include Microsoft SQL Server as a 3rd Enterprise database. SSA?s desktops are running Microsoft XP Professional SP2. Upgrade to Microsoft Vista is in the planning stage. SSA uses Microsoft SMS and Hewlett Packard Radia for software distribution. The current desktop application suite includes Microsoft Office 2003, Internet Explorer 6, Outlook/Exchange, and IBM PCOM for mainframe connectivity. SSA has deprecated support for fat client and client/server applications, e.g. applications which require application software components to be distributed to the desktop. SSA does not expect that WDPE applications or COTS will be Internet facing for security reasons. Employees With Disabilities (Section 508) Requirements The software that is configured in SSA?s WDPE must be compatible with Federal Government Section 508 standards. Section 508 software standards can be found at www.section508.gov. Vendor Responses Vendors who have provided the above listed services to large geographically dispersed organizations with a large number of end users and both centralized and dispersed developers are invited to submit information concerning their past experience in performing those services. Detailed responses addressing each of the above 12 service areas are required. Vendors should provide customer references for (their) large implementations. Of particular interest is techniques used to grow from an initial small implementation to a full blown, large one. Deployments referenced must have been operating in production in customer sites for a minimum of 18 months (x86) or 6 months (Itanium2 running 64 bits). Vendor responses should provide detailed accounts of: 1. The company/organization that the vendor provided the services to. 2. A reference contact at the company (name, email, phone number). 3. What did the customer provide 4. What services the vendor provided. 5. Vendors may provide the following information regarding the 3-5 year lifecycle costs to the referenced customers, including ?WDPE? equivalent: a. Planning construction services b. Construction services c. hardware d. hardware refresh e. software f. software update g. training h. ongoing consulting i. ongoing services It is important to note that simple marketing information or incomplete responses will not be considered as an acceptable or valid response. Additionally references, informational extraction, or links to vendor web sites is not considered a valid response. Respondents should indicate whether their services/products are available on GSA Federal Supply Schedules or any other Government-wide Agency Contract (GWAC). Electronic responses only must be submitted by 04/16/2007. Faxed information will not be permitted. The size limitation for email attachments is 5 megabytes. MS Word 2003 is the standard word processing software. NO FORMAL SOLICITATION IS BEING ISSUED AT THIS TIME, and the Government does not intend to pay for the information submitted. This information will be used in SSA?s assessment of capable sources. Respondents will not be notified of any evaluated results from the data received. Any questions should be submitted via EMAIL ONLY (no phone calls please) to the Contract Specialist at Jessica.Coombs@ssa.gov. Point of Contact Jessica Coombs, Contract Specialist Phone 410-597-1959 Email Jessica.Coombs@ssa.gov
- Place of Performance
- Address: Social Security Administration, 6401 Security Blvd, Baltimore, MD
- Zip Code: 21235
- Country: UNITED STATES
- Zip Code: 21235
- Record
- SN01264671-W 20070404/070402224621 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |