appendix r - web viewthe selected offeror’s proposed l&i-oit training, ... must be...

Appendix R

Technical Requirements

This document outlines the technical requirements for CWDS. All proposed solutions must adhere to the L&I technical requirements and standards contained within this RFP and associated appendices, unless the Selected Offeror offers clear and convincing financial justification (without disclosing cost figures in the technical response) and technical or business value justification.

1. Overview. The CWDS Project Management Team has set preferred standards for this project, which are listed in Appendix U, L&I Technical Architecture Requirements. A Selected Offeror who wants to propose hardware/software not listed in this appendix should defer to Appendix KK, L&I Enterprise Standards. Selected Offerors who want to propose hardware/software not listed in the L&I Enterprise Standards should defer to the Commonwealth’s Office of Administration Information Technology Bulletins (ITB) standards as listed in both Appendix U and Appendix KK. Hardware and software available for L&I shared products are available in Appendix V, L&I Shared Product Environments. Appendix W, CWDS Environments provides Visio diagrams of the current environment hardware infrastructure.

For any solution type proposed, Selected Offerors are responsible for reviewing their proposed solution against Appendix KK, L&I Enterprise Standards and the Commonwealth Information Technology Standards. The Selected Offerors are responsible to ensure that CWDS continues to adhere to all applicable technical standards, policies and procedures. In the absence of detailed standards and/or practices relating to the proposed solution, the principles defined throughout the Commonwealth Information Technology Standards must be used to direct the design and decision making. Any deviation from the specifications indicated herein must be clearly identified as an exception and listed on a separate page labeled “Exceptions to Specification,” otherwise, it will be considered that items offered are in strict compliance with these specifications, and the Selected Offeror will be held responsible.

L&I has implemented a standards-based infrastructure to support current business systems as well as upcoming technical projects. Project-specific standards are provided in Appendix U, L&I Technical Architecture Requirements. The Selected Offeror is expected to use the project specific standards in use in CWDS. The L&I Enterprise Standards are provided in Appendix KK, L&I Enterprise Standards. If no standards exist, the Selected Offeror should provide justification and business value for the proposed product. Note that all proposed products must conform to established OA-OIT ITBs, which govern the development and use of information systems.

A. Information and requirements in Appendices include:1. Appendix L, L&I Voice, Data and Power Infrastructure Specifications – addresses

the voice, data and power specifications for the proposed project facility.2. Appendix M, Project Facility Router, Switch and Site Server Requirements –

provides router, switch and site server requirements for the proposed project facility.3. Appendix N, L&I Systems Management Plan – Change Management – provides

information on requirements, responsibilities and processes for change management. 4. Appendix T, Technology Upgrades – provides a listing of potential technology and

software upgrades needed over the life of the proposed contract.5. Appendix U, L&I Technical Architecture Requirements – provides specific Project

standards, available hardware and software for the Project and information about the network supporting the business processes.

CWDS Technical Requirement of 22

http://www.portal.state.pa.us/portal/server.pt/community/policies/10301/information_technology_bulletins/551947

http://www.portal.state.pa.us/portal/server.pt?open=512&objID=416&&PageID=210791&level=3&css=L3&mode=2

http://www.portal.state.pa.us/portal/server.pt?open=512&objID=416&&PageID=210791&level=3&css=L3&mode=2

6. Appendix V, L&I Shared Product Environments – provides a summary of the shared system application environments and accompanying end user license information.

7. Appendix W, CWDS Environments – provide architecture workflow diagrams of the application environments across prior phases of system implementation.

8. Appendices X, Y, Z, AA and BB – Security and Identity and Access Management Standards – provides security requirements for the proposed solution, including a description, diagram and requirements for the enterprise standard shared environment for security.

9. Appendix CC, L&I Remedy Components and Processes - Shared Product Software- Remedy – provides information on help desk, change management and asset management.

10. Appendix DD, Proposed Resource Hours Matrix – provide a worksheet template for completing proposed resource allocation hours.

11. Appendix EE, L&I Tivoli Enterprise Application Shared Product – provides information on data backup and system monitoring.

12. Appendix FF, L&I Content Management Requirements – provides information on L&I’s implementation of IBM FileNet Enterprise Content Management Suite including infrastructure diagrams.

13. Appendix GG, L&I-OIT Business Process Integration Software – Shared Products Software - WebMethods provides information on L&I’s implementation of WebMethods including infrastructure diagrams.

14. Appendix HH, L&I Accessibility Requirements – details the requirements of the proposed solution to meet the US Government 508 (Subpart B) accessibility standards and guidelines, and where applicable, to meet the standards and guidelines within US Government Section 504.

15. Appendix II, CWDS Database Architecture Overview – provides an overview of the CWDS database architecture including infrastructure and databases.

16. Appendix JJ, L&I Standards Environments – provide a summary of L&I system standard environments (non-shared)

17. Appendix KK, L&I Enterprise Standards – provides a summary of the L&I OIT Enterprise Architecture Policies and Domain Standards.

18. Appendix LL, Disaster Recovery Plan – provide details of the CWDS Disaster Recovery Plan.

19. Appendix MM, CWDS Business Context Overview – provides general background information of the CWDS programs and program areas involved with the system.

20. Appendix NN, L&I Application Lifecycle Management Requirements – provides a general overview and diagrams of how the Microsoft Visual Studio Team Foundation Server 2010 (TFS) is used to control the management of the L&I standard for application lifecycle.

21. Appendix OO, L&I Business Objects Enterprise Requirements – provides information on L&I’s implementation of Business Objects Enterprise including infrastructure diagrams.

22. Appendix PP, L&I Communication and Collaboration - SharePoint Requirements – provides information on L&I’s implementation of SharePoint including infrastructure diagrams.

23. Appendix QQ, System Administration Guidelines for Non-Commonwealth Employees Consultant c-340.1 – provides information on access to the Commonwealth network for non-Commonwealth individuals.


The Selected Offeror must assess all application design, developed code, application components, database logic, and deployment architecture in terms of how the system will scale and how well the application must perform at peak concurrent usage, not average user workload. Critical Note: Performance, scalability and security must not be compromised to support a solution.

The Selected Offeror must include all configurations of required hardware and software, documentation, technical and operational support, and knowledge/skills transfer to L&I-OIT staff for the duration of the contract. Any request for L&I to acquire or authorize the use of any hardware or software during the course of this project, must be referred to the L&I Enterprise Change Control Board (ECCB). To the extent possible, Selected Offerors are asked to leverage existing investments in technology. L&I will make any purchase of hardware and software.

B. Key elements of CWDS to be continued, enhanced, or extended:1. Designed and architected to use standard Intel-based Xeon server processing

requirements. CWDS is currently 32-bit compliant but the CWDS Project Management Team, as part of technology upgrades (refer to Appendix T, Technology Upgrades), expects to move to 64-bit compliant platform in the first year of this contract. All associated changes must have the ability to execute and use the addressability of Xeon processor-based hardware and 64-bit software solutions. All software proposed thereafter (including 3rd party COTS, open source, shareware, or freeware components) must be 64-bit compliant in accordance with Appendix KK, L&I Enterprise Standards. Within its proposal, the Selected Offeror must document and address any software that is not 64-bit compatible and cannot run on a 64-bit server. The use of virtualization on a VMware platform must be considered for all components to be installed and maintained for the project. Further discussion of virtualization may be found in Appendix U, L&I Technical Architecture Requirements.

2. A browser-based business application architected in a tiered approach that logically and physically separates User-Interface, Business Logic, Data Access and Database layers of the system. The browser-based front end for the application must leverage the existing L&I reverse proxy (ForeFront 2010) infrastructure at the Commonwealth’s Enterprise Server Farm at the Commonwealth Technology Center (CTC). This arrangement allows the application and security infrastructures to reside in the L&I Data Center.

3. Custom-built supporting software or customizations to COTS supporting software must be based on the Microsoft .NET Application Framework v3.5 Service Pack 1 or higher. All portions of the custom application code/COTS customization code shall become the property of the Commonwealth and are to be coded on Microsoft Visual Studio 2008 Premium Edition with MSDN subscription or higher.

4. A solution designed, developed, and deployed on the Microsoft Windows Enterprise Edition server platform with Internet Information Server (IIS), whereas the version is based on the release outlined in Appendix KK, L&I Enterprise Standards, as the presentation and application services tier.

5. A solution that continues to provide U.S. English, U.S. English Text only and Spanish versions of any public user presented screen interfaces. CWDS must continue to be designed and architected to allow expansion to additional languages in future versions of


the system. Use of an automated language translator to meet this requirement is NOT acceptable.

6. Maximizes system performance and meets the performance requirements described in Section 6, Performance and Scalability Requirements.

7. Meets all Commonwealth and L&I-OIT security requirements described in Section 4.1.1, Shared Service for Security – CA Identity and Access Management Requirements and Appendices:

a. Appendix X, L&I Enterprise Security Standards and Requirements b. Appendix Y, IAM Infrastructure and Diagrams – Shared Product Software c. Appendix Z, L&I-OIT Policy C-301 – Identification and Authentication of Users on

New L&I Computer Systems d. Appendix AA, L&I-OIT Policy C-306 – Application Access Control e. Appendix BB, L&I-OIT Policy C-320 – Data Encryption Standards

8. Meets all business area business continuity requirements described in Appendix LL, Disaster Recovery Plan.

9. Uses MS SQLServer Enterprise 2008 R2 as the database platform, whereas the version is based on the release outlined in Appendix KK, L&I Enterprise Standards, as the presentation and application services tier.

2. Service-Oriented Architecture (SOA) RequirementsService-Oriented Architecture (SOA) is the process of building scalable distributed systems that treat software components as services. SOA provides the framework for independent services to interact with each other across a network. This allows a complex distributed system to be assembled quickly and cost-effectively from individual services, most commonly implemented using Web service technologies.

A service is reusable, easy-to-program, and independent of programming language or platform. It can be best thought of as a reusable application function, used as a component in a business process. A service is able to provide this function over and over again to various service requesters. It is this ability to reuse the service, and the practice of breaking down each business process into a series of services, that generates the efficiency benefits of a SOA. A service can consist of a single object or a connected series of objects. However, a key definition is that a service, no matter its makeup, is always treated by external entities as a single unit.

As part of the planning for each major functional release, time must be allotted for analysis and identification of business processes and business services that would be candidates for reuse across multiple business systems. Care must be given to design these reusable services so that they may be registered in the central services registry and made available for consumption by other business systems.

All Web service descriptions and related SOA artifacts are required to be stored and managed within an enterprise Universal Description, Discovery and Integration (UDDI) registry.

L&I has begun to focus on the identification and reuse of common business services and technology components that meet business requirements, which are shared by multiple business systems. To date, the primary emphasis has been on the identification of common technology components that are to be used by multiple business systems. Some examples of those components and the functions that they provide are listed below:

A. Identity and Access Management – CA SiteMinder provides central Identity and Access Management services. CA SiteMinder allows L&I to automate identity and access management tasks to ensure that only authorized users can access critical IT resources.


B. Enterprise Job Scheduling – $Universe provides L&I with a comprehensive enterprise scheduling solution that aggregates, automates, and orchestrates IT processes.

C. Message-Oriented Middleware – WebMethods is used to automate and improve integration of business processes, promote re-use versus re-creation of business service components and to govern SOA-based initiatives.

D. Enterprise Business Reporting – Business Objects is a single platform to provide L&I with Business Intelligence, information analysis, and reporting across multiple business systems.

E. Enterprise Content Management – FileNet is used to store, organize, manage and secure documents/image. Datacap is used to scan documents/images into FileNet from a central location and from remote field sites.

F. Appendix NN, L&I Application Lifecycle Management (ALM) Requirements – Team Foundation Server 2010 enables software development teams to collaborate more effectively, be more agile, and provide better quality software by providing project management, work item tracking, version control, build automation and reporting functionalities.

G. Appendix PP, L&I Communications and Collaboration – SharePoint provides collaborative workspaces used to efficiently centralize and manage information and communication.

These shared components allow L&I-OIT to meet common business requirements while leveraging common technology solutions and shared infrastructure. All business systems should use these common components as part of their system architecture. This embedded functionality must meet the applicable requirements detailed within the RFP. The shared components listed above, with the exception of Business Objects, are centrally managed by L&I-OIT staff. It is expected that Business Object will migrate to a centrally managed installation in the near future. Current and future business system development projects will be required to allot time for analysis and identification of business requirements that could be met using existing technology components. For further information on shared products see Section 3, Hardware Requirements, Section 3C, L&I Shared Product Environments; and Section 4.1, L&I Shared Product Software Requirements.

All new application code will be scanned as part of L&I and the Office of Administration’s accreditation process as per ITB-SEC005 – Commonwealth Application Certification and Accreditation . Any code that does not successfully pass the scanning process will have to be rewritten or modified to pass the exception before the code is placed into production.

3. Hardware RequirementsAll functional releases are to reside on existing L&I hardware assigned to the CWDS project. A full CWDS hardware refresh was completed in December 2010. L&I-OIT will be responsible for the installation, configuration, and daily maintenance of the CWDS hardware that already exists within the L&I Enterprise.

A. The Selected Offeror must design, plan, and fulfill all necessary prerequisites and requirements to deploy each release to the L&I Server Farm’s Data Center. It is expected the CWDS will continue to use all existing L&I owned servers, including proxy servers in the OA co-location facility to pass public traffic to servers located in the L&I Harrisburg Data Center. For components exposed to the public, the Selected Offeror’s solution must be sized so that performance will continue to be acceptable. Refer to Section 6, Performance and Scalability Requirements of this document.

B. L&I Standard Environments. CWDS must continue to be deployed according to the System Development Life Cycle environments listed below and further detailed in Appendix JJ, L&I Standard Environments. In the System Documentation, the Selected Offeror should detail


http://www.portal.state.pa.us/portal/server.pt?open=512&objID=416&PageID=200500&mode=2&contentid=http://pubcontent.state.pa.us/publishedcontent/publish/cop_general_government_operations/oa/oa_portal/omd/p_and_p/itbs/domains/security/itbs/itb_sec005.html

how releases will be migrated between the environments and how the Selected Offeror will continue to use the existing environments that are being shared with other projects within L&I. The Selected Offeror must describe its strategy for verifying that the system is ready for deployment to the next environment. 1. Development and Unit Test2. Component Integration Test3. System and User Acceptance Test (UAT). Note: In the event that a catastrophe has

made the Production environment unavailable, the ability to repurpose this environment for production purposes is a requirement. Processes and procedures to accomplish this must be documented in the Selected Offeror’s Disaster Recovery Plan. The hardware for this environment is located at L&I’s Disaster Recovery site.

4. Training5. Test for Production (TFP)6. Production

C. L&I Shared Product Environments. The Commonwealth and L&I have invested in the Shared Product concept whereby software used by more than one system is administered centrally and environments are ‘shared’ by L&I systems. L&I has a number of shared products in use and is continually expanding the Shared Product concept. For specific details on each shared product environment, refer to Appendix V, L&I Shared Product Environments.

The L&I Shared Services Change Control Board (SSCCB) and the ECCB must approve any changes to these shared product environments. All changes to shared environments must be discussed at the SSCCB meetings and, once approved, will be brought before the ECCB for approval and scheduling. Meetings are held weekly by both boards.

Please refer to Appendix U, L&I Technical Architecture Requirement and Section 4.1 L&I Shared Product Software Requirements and its Subsections 4.1.1 through 4.1.12 for further information.

1. Computer Associates Identity and Access Management Suite (IAM)2. $Universe3. WebMethods4. FileNet5. Tivoli6. Remedy7. IIS8. CentraSite Active SOA9. Corticon10. Business Objects Enterprise11. SharePoint12. Team Foundation Server

3.1. Hardware Refresh RequirementsThe Commonwealth will be responsible for acquiring and installing recommended hardware. The Selected Offeror must propose and include all costs for implementing CWDS onto a hardware refresh in the Option Year 1 of the contract, this includes workstation and server hardware and any expansion necessary to the Project’s L&I standard environments and the L&I shared product environments, including disaster recovery infrastructure necessary to support the Selected Offeror’s project requirements. A


hardware refresh is defined as assessing industry technology and architecture as compared with Project needs, including planning for additional growth, and replacing the hardware. The Selected Offeror will be collaborating and providing input for the hardware refresh including the system architecture design and planning, with L&I-OIT approval. The Selected Offeror must work with L&I-OIT staff to implement the hardware refresh. As part of its proposal, the Selected Offeror must indicate the number of person hours and skill levels allocated to each task (refer to Appendix DD, Proposed Resource Hours Matrix for information). In addition to conducting the configuration, the Selected Offeror must also document the process to configure the necessary hardware.

4. Software RequirementsAll current system and supporting software used by and/or newly proposed for the Project must adhere to and meet these requirements and the standards and requirements referenced in Appendix KK, L&I Enterprise Standards; Appendix U, L&I Technical Architecture Requirements; and Appendix V, L&I Shared Products Environments. Any software proposed will be considered. All software acquisitions are the Commonwealth’s responsibility. The Commonwealth reserves the right to remove, in part or in whole, the proposed software at any point during the course of the contract including the time period between the Selected Offeror’s proposal of the software and an executed contract. All changes during the course of the contract will follow the Change Order Process.

The Selected Offeror is responsible for, and must include, all costs for the configuration, technical, and operational support of all the software needed to design, develop, deploy, and support its solution throughout the life of the contract, including any additional software to expand any shared software products required to support the Selected Offeror’s proposed solution. CDWS will continue to be deployed on L&I provided hardware for the life of the contract. The Selected Offeror is responsible for hardware/software configuration and implementation recommendations, technical and operational support.

The Selected Offeror must team with L&I-OIT staff during all phases of this task. Under direction of L&I-OIT staff, all software installation and configuration is the responsibility of the Selected Offeror, with the exception of shared software components. In the cases of shared software the Selected Offeror will assist L&I-OIT staff with the installation and configuration process as needed. Where deemed necessary by the third-party vendors, the Selected Offeror must ensure that authorized/certified personnel or sub-Selected Offerors are performing this activity. All software installations must be documented in detail, including screen shots of the installation process. As part of its proposal, the Selected Offeror must indicate the number of person hours and skill levels allocated to each task (refer to Appendix DD, Proposed Resource Hours Matrix for information). The Selected Offeror’s proposed L&I-OIT Training, Mentoring and Knowledge Transfer Plan must include applicable, targeted mentoring and any relevant training deemed necessary for L&I-OIT to support the Selected Offeror’s proposed software.

Any requests for L&I to acquire or authorize the use of any software, not identified in the Selected Offeror’s proposal, must be referred to the Project Change Control Board. The L&I SSCCB and the ECCB must approve any changes to shared software products.

A. To the extent possible, Selected Offerors should make use of L&I’s existing shared software assets.

B. Once the project has started, any additional software proposed by the Selected Offeror must be approved by the L&I-OIT Software Review Committee (SRC).

C. Information regarding technology upgrades currently planned to be conducted under this contract can be found in Appendix T, Technology Upgrades. The Selected Offeror must work with the CWDS Project Management Team to schedule and implement the upgrades. All


affected applications and/or environments must be analyzed and changes made as required as a part of each upgrade.

D. The Selected Offeror must install current release levels and patches/fixes in an industry standard timely manner. New releases or versions of installed software products must be installed on the development and testing environments upon approval to do so first from the CWDS Project Management Team, followed by OIT-Bureau of Enterprise Architecture (BEA) and the L&I ECCB. Once tested, the software must be migrated to the production environment upon approval to do so from OIT-BEA and the L&I ECCB, the L&I-OIT staff will implement the software into production. All patches, fixes, and service packs must be installed in the development and testing environments upon approval to do so from OIT-BEA and the L&I ECCB.

4.1. L&I Shared Product Software RequirementsThe Selected Offeror is responsible for meeting the requirements listed in this section and in Section 4, Software Requirements for shared product software within its proposed solution. For all shared product software proposed, the Selected Offeror must include all costs for updates to application code using shared services. L&I’s intent is to keep all shared product software and operating systems at current versions and patch levels, however, L&I does understand that shared software may not be supported by the newer versions of an operating system until updated by the Selected Offeror. These exceptions would be handled on a case-by-case basis. The Selected Offeror must include all proposed shared product software upgrades, refreshes, and subscription renewals needed for all environments in its proposal.

In addition to conducting the configuration, the Selected Offeror must also document the process to configure the necessary software. The Selected Offeror must team with L&I-OIT staff during all phases of this task. As part of its proposal, the Selected Offeror must indicate the number of person hours and skill levels allocated to each task (refer to Appendix DD, Proposed Resource Hours Matrix for information).

The Selected Offeror is responsible for engaging shared product software specialists or technical leads to assist in performing all shared product software work associated with the Project.

The L&I SSCCB and the ECCB must approve any changes to the shared software products. All changes to shared environments must be discussed at the SSCCB meetings and, once approved, will be brought before the ECCB for approval and scheduling. Meetings are held weekly by both boards.

A detailed table of available shared product software for use in the project is in Appendix V, L&I Shared Product Environments. Selected Offerors are expected to review this table when proposing additional infrastructure and licensing.

The Selected Offeror’s proposed shared product software must meet the standards as referenced in Appendix KK, L&I Enterprise Standards. Any exceptions to the standards list must be noted and an explanation must be provided and approval must be received from the Project Change Control Board, OIT-BEA, and the L&I ECCB.

The Selected Offeror’s proposed system architecture design must be approved by OIT-BEA as well as the CWDS Project Management Team prior to the Selected Offeror’s execution of this deliverable throughout the life of the Project.

4.1.1. Shared Service for Security – CA Identity and Access Management RequirementsL&I and CWDS currently use Computer Associates (CA) Identity and Access Management (IAM) E-Trust suite for application security for Department applications. Access to specific applications is managed


through these tools. The IAM system provides single sign-on into applications for Commonwealth employees, and a single account to be used by business partners and public users of Web applications. It also provides external customers with self registration and password reset functionality to limit the administration overhead.

L&I shares common business partner and public repositories with several other state agencies in an effort to provide a single account that can be used with numerous services offered by the Commonwealth.

CWDS must continue to leverage the CA Security suite and allow for integration with the existing CWDS IAM solution for its employees, Selected Offerors, citizens and business partners. The Project’s system will house, collect and process data from many internal and external participants, employers and providers.

The Selected Offeror must leverage L&I and CWDS’s existing investment in the Computer Associates (CA) Security suite Identity and Access Management (IAM) system (SiteMinder & Identity Manager). The Computer Associates license held by the Commonwealth covers the Identity Manager Web Edition and SiteMinder Policy servers, as well as the basic Web agent. The Selected Offeror must provide expert services to the L&I security team related to any specific product or system integration with the existing security infrastructure. The configuration requirements and maintenance of the IAM application will be completed by the Selected Offeror’s IAM technical lead working with the CWDS Project Management Team staff responsible for the shared environments. The IAM environments are described in Appendix Y, IAM Infrastructure and Diagrams. See the table in Appendix U, L&I Technical Architecture Requirements for available Shared Product software for use in the Project.

CWDS must continue to comply with the security requirements contained in Appendix X, L&I Enterprise Security Standards and Requirements and the security policies contained in Appendix Z, L&I-OIT Policy C-301 – Identification and Authentication of Users on New L&I Computer Systems; Appendix AA, L&I-OIT Policy C-306 – Application Access Control; and Appendix BB, L&I-OIT Policy C-320 – Data Encryption Standards. The Selected Offeror is responsible for using security tools and processes to ensure the implementation of risk-free code and the resolution of any identified issues. The Selected Offeror’s solution must provide for the assignment and reassignment of roles and permissions as identified and approved by the CWDS Project Management Team.

Any exceptions to the defined security requirements and/or changes of implementation methods must be approved by the CWDS Project Management Team and the L&I’s Chief Information Security Officer (CISO).

The Selected Offeror is responsible for bringing IAM knowledge and staff with technical skills to the project to assist in performing all CA IAM work associated with the Project.

4.1.2. Shared Service for Enterprise Job Scheduling – $UniverseL&I and CWDS have adopted Orsyp’s $Universe ($U) as its standard for batch scheduling. $U is a grid computing application installed on one or more servers per environment, depending upon the batch processing needs and the system architecture. $U is a very flexible tool that can accommodate a wide variety of solutions.

Administration is handled centrally by OIT-Bureau of Enterprise Services (BES) as is the administration for all shared products.


The Selected Offeror’s proposed CWDS solution must minimize batch processing to the extent possible and maximize real time processing. Batch jobs will be loosely coupled with $U by calling executables written in the project language.

For those processing functions requiring batch processes, these requirements must be followed:A. All batch processing procedures and routines must continue to be written in languages

compatible with $U, preferably Microsoft .NET.B. All batch processing requirements must be documented with run time frequency, input/output

streams, estimated size of data, estimated total run time, back out processes, and rerun procedures.

C. No batch scheduling will be permitted on the database management system server directly, except for jobs using the Database Management System (DBMS) Job Agent.

D. All batch processing import or export routines for external system interfaces will continue to use Internet Information Server (IIS)/File Transfer Protocol (FTP) server processing capabilities.

E. All data extracts and data validation processes must continue to use stored procedures whenever possible. Data extract, validation, or nightly database update processes must continue to be scheduled by the database system job agent.

The Selected Offeror is responsible for bringing $U knowledge and staff with technical skills to the project to assist in performing all $U work associated with the project.

The Selected Offeror must develop the $U components that are applicable to its proposed solution for each functional release and the customization of any $U components that require integration with the Selected Offeror’s proposed solution.

The Selected Offeror’s strategy for meeting and executing these requirements must be detailed in the Selected Offeror’s General System Design and Detailed System Design and must be approved by the CWDS Project Management Team.

4.1.3. Shared Service for Business Process Integration – WebMethodsL&I and CWDS have adopted WebMethods as its business process integration software. WebMethods is a solution when business-to-business (B2B), business-to-consumer (B2C), business-to-government (B2G), middleware, job scheduling, and platform independent software is needed. WebMethods is also used by other L&I application systems, including a separate batch address application. L&I is currently leveraging WebMethods v.8.0.1, however, is in the process of upgrading to v.8.2.2 with the goal of having the v.8.2.2 production environment available by June 2013.

The Selected Offeror is responsible for engaging a WebMethods developer to perform all WebMethods development necessary for the project. Note that L&I has WebMethods administrators and does not require assistance with product administration. The WebMethods developer is strictly for the Project’s WebMethods programming needs. The WebMethods developer will work with L&I WebMethods administrators to ensure that the code developed as part of the Project meets the standard naming conventions and is packaged to ensure optimum performance.

The diagrams in Appendix GG, L&I-OIT Business Process Integration Software – Shared Products Software - WebMethods depict the WebMethods infrastructure. In the development region each program area has its own “sandbox” WebMethods infrastructure. The size and set up of that structure solely depends on what processes the Selected Offeror plans to implement.


The Selected Offeror is responsible for bringing WebMethods knowledge and staff with technical skills to the project to assist in performing all WebMethods work associated with the Project.

The Selected Offeror must develop the WebMethods code applicable for each functional release of the Selected Offeror’s proposed solution.


4.1.4. Shared Service for Content Management – FileNetL&I currently uses the IBM FileNet Enterprise Content Management (ECM) Content Manager suite for managing content in the form of documents and images although it is not currently in use in CWDS.

L&I has licenses for FileNet P8 version 5.0 and Oracle 11gR2. If the Commonwealth decides to use FileNet on the CWDS project, the Selected Offeror would be responsible for expansion of the environments and recommendation for the procurement of licenses necessary to support CWDS. With the implementation of version 5.0, the Commonwealth has a Full Disaster Recovery Plan and has established High Availability. The Selected Offeror will be responsible for identifying licenses for these products if the products are proposed for this project.

The FileNet requirements and environments are described in Appendix FF, L&I Content Management Requirements.

If the Commonwealth decides to use FileNet on the CWDS project the Selected Offeror will be responsible for bringing FileNet knowledge and staff with technical skills to the project to assist in performing all FileNet shared product work associated with CWDS and to meet the content management requirements of CWDS.

The Selected Offeror’s strategy for meeting and executing these requirements would be detailed in the Selected Offeror’s General System Design and Detailed System Design and must be approved by the CWDS Project Management Team.

4.1.5. Shared Service for Enterprise Business Reporting – Business Objects EnterpriseThe standard reporting solution for L&I and CWDS is based on the Business Objects Enterprise (BOE) reporting platform. There are currently a number of BOE instances installed to support ongoing projects, however, L&I is migrating all instances of BOE into one shared or Enterprise infrastructure. The Selected Offeror must determine if the Enterprise BOE infrastructure will need to be expanded to support the reporting requirements of CWDS. The Enterprise BOE instance consists of these components installed on a Windows server platform:

A. Business Objects ComposerB. Business Objects Data Integrator Departmental Data Integrator ServerC. Business Objects Data Integrator Multi-User Team DevelopmentD. Business Objects Web IntelligenceE. Business Objects Enterprise Premium

The Selected Offeror is responsible for bringing Business Objects Enterprise knowledge and staff with technical skills to the project to assist in reporting requirements work associated with the Project.


The Selected Offeror must develop the BOE components that are applicable to its proposed solution for each functional release and the customization of any BOE components that require integration with the Selected Offeror’s proposed solution.

4.1.6. Shared Service for Data Backup and Systems Monitoring – TivoliTivoli is L&I’s shared enterprise application for both data backups and systems monitoring. Specific products include IBM Tivoli Monitoring for Microsoft Applications, IBM Tivoli Composite Application Manager (ITCAM) for Applications, ITCAM for Transactions, and OMNIbus.

The Selected Offeror must use Tivoli for ongoing server and network monitoring of the proposed solution as necessary to meet the requirements in Section 6, Performance and Scalability Requirements and Section 7, Disaster Recovery Requirements of this document.

The Selected Offeror must use Tivoli Storage Manager (TSM) for ongoing server backup and recovery services as necessary to meet the requirements in Section 6, Performance and Scalability Requirements and Section 7, Disaster Recovery Requirements of this document.

The L&I Tivoli Enterprise Application is described in Appendix EE, L&I Tivoli Enterprise Application – Shared Product Software - Tivoli.

The Selected Offeror is responsible for meeting the requirements for Tivoli software and services listed in this section and in the following:

Section 3.C, L&I Shared Product Environments;Section 4.1, L&I Shared Product Software Requirements; Appendix U, L&I Technical Architecture Requirements; andAppendix V, L&I Shared Product Environments

The Selected Offeror must assign a Tivoli Lead Specialist(s) to the Project to assist in performing all Tivoli work associated with the Project. This includes backup/recovery and monitoring.

The Selected Offeror’s strategy and execution of this task must be approved by the CWDS Project Management Team.

4.1.7. Shared Service for Change Management, Asset Management, and Help Desk – RemedyL&I’s Remedy System uses three Remedy components: Change, Asset, and Help Desk Management. Remedy is customized to meet L&I’s business requirements. It is fully integrated with essential incoming and outgoing feeds, along with locally developed processes.

A. L&I’s Remedy Change Management provides change management capabilities with integration to the Remedy Help Desk and Remedy Asset Management applications. Functionality is provided for recording, approving, and tracking change requests to resolution.

B. L&I’s Remedy Asset Management implementation provides functionality for creating, modifying, and retiring asset records with integration to the Remedy Help Desk and Remedy Change Management applications. L&I’s Remedy Asset database is the official L&I repository for all data related to hardware and software within the enterprise.

C. L&I’s Remedy Help Desk provides incident management capabilities with integration to the Remedy Change Management and Remedy Asset Management applications. Incident-related calls are reported to the Labor & Industry Network Knowledge System (LINKS) Help Desk and recorded in the Remedy Help Desk application.


The Selected Offeror must work with the CWDS Project Management Team to ensure that all changes, assets and asset modifications are documented for the proposed solution.

The Remedy environments are detailed in Appendix CC, L&I Remedy Components and Processes.

4.1.8. Shared Service for Microsoft Application Engine – IISL&I currently uses IIS as its application engine for Microsoft .NET web-based applications. The version of IIS that will be used will depend on the Windows server version loaded.

A. Windows Server 2008, IIS 7B. Windows Server 2008 R2, IIS 7.5C. Windows Server 2012, IIS 8

The Selected Offeror is responsible for bringing IIS knowledge and staff with technical skills to the project to assist in performing all IIS work associated with the Project.

IIS licensing is directly tied to Windows Server licensing. IIS installation will be performed by the L&I IIS administration team with assistance by the Selected Offeror following the build of a server. The L&I standard IIS configurations will be applied by the L&I IIS administrators. Once the initial install and configuration of IIS is completed the application team will then be delegated specific permissions to customize IIS configurations to fit project requirements. All IIS configurations above and beyond the standard L&I configuration must be approved and documented so that all IIS servers in all environments can be kept consistent.

4.1.9. Shared Service for Business Rules Management System (BRMS)BRMS software focuses on capturing, analyzing, testing, and executing business rules that comprise automated decisions critical to business operations. L&I has reviewed business rules management tools and Corticon has been added as a tool to its list of Shared Services. CWDS currently uses an internal business rules engine using the Microsoft .NET framework. The CWDS Project Management Team may require the Selected Offeror to convert the existing BRMS to a shared services BRMS if applicable.

The Selected Offeror will be responsible for engaging the BRMS administration team to perform any BRMS-related development that may be necessary for the project.


4.1.10. Shared Service for SOA Registry and Repository – CentraSite ActiveSOAThe standard SOA registry and repository for L&I is CentraSite ActiveSOA. CentraSite ActiveSOA establishes policies, controls, and enforcement mechanisms required for successful SOA adoption by giving IT visibility and control over SOA development and deployment. It is used to store and manage Web service descriptions and related SOA artifacts including business process and information models. CentraSite ActiveSOA reports changes on these SOA items throughout their life cycle in the enterprise. By combining a standards-based registry and repository with policy management, CentraSite ActiveSOA adds value throughout the SOA lifecycle.

CentraSite ActiveSOA is the Business Services Repository for WebMethods. It provides built-in support for WebMethods assets and native integration with other WebMethods components. CentraSite is platform and technology agnostic. All services described by a Web Service Definition Language (WSDL) can be imported and managed with CentraSite regardless of the implementation technology.


At the time of this RFP, CentraSite instances are available for use. However, no project is currently leveraging this product, nor is its use mandated. It is expected that by the anticipated start date of this project, use of CentraSite ActiveSOA will be required as the Universal Description, Discovery and Integration (UDDI) registry for all SOA solutions. In addition, the processes and procedures for the use of the tool will be in place. There are presently no exposed services in CWDS. The CWDS Project Management Team may introduce requirements for exposed SOA services if applicable.

CentraSite Active SOA is deployed within the DEV, UAT, and PROD environments. The CentraSite Active SOA infrastructure is described in conjunction with the WebMethods diagrams in Appendix GG, L&I-OIT Business Process Integration Software – Shared Products Software - WebMethods. L&I-OIT will maintain the system-level administrator role within all instances of CentraSite Active SOA. The Selected Offeror will be provided an administrative role for working with project-specific objects in the Development environment only.

The Selected Offeror is responsible for bringing SOA registry and repository knowledge to the project to assist in performing all SOA work associated with the Project.

4.1.11. Shared Service for Communication and Collaboration – SharePointThe standard communication and collaboration tool for L&I OIT is SharePoint 2010. Shared instances of SharePoint exist in Development, User Acceptance Testing, and Production environments. This enterprise instance is currently in use by several projects within L&I OIT with several other sites anticipated in early 2013. The Selected Offeror is responsible for bringing SharePoint knowledge and staff with technical skills to the project to assist in the collaboration requirements associated with the Project.

L&I-OIT will maintain full administrative access in all environments. The Project will be provided elevated permissions for their site collection as warranted by the requirements of the site while meeting L&I Standards.

4.1.12. Shared Service for Application Lifecycle Management (ALM – Team Foundation ServerThe standard application lifecycle management tool for L&I is Microsoft Visual Studio Team Foundation Server 2010 (TFS).An Enterprise Shared instance of TFS 2010 exists in the Development, User Acceptance Testing, and Production environments. This Enterprise instance is currently in use by several projects. In addition, L&I is in the process of migrating all application code maintained in Microsoft Visual Source Safe to this Enterprise instance. It is also anticipated that the CWDS project will be migrating from their TFS 2008 environments to the Enterprise TFS 2010 environments by the end of 2013. The Selected Offeror must determine if the Enterprise TFS infrastructure will need to be expanded to meet the needs of the Project.

The Selected Offeror is responsible for bringing Team Foundation Server knowledge and staff with technical skills to the project to assist in ALM requirements associated with the Project.

L&I-OIT will maintain the system-level administrator role within all instances of Team Foundation Server. The Selected Offeror will be provided an administrative role for their Project Collection. The Selected Offeror will be provided the administrator role for their Build Automation Server.

5. Networking Overview and RequirementsDiagrams of the existing network infrastructure supporting L&I are provided in Appendix U, L&I Technical Architecture Requirements. CWDS must continue to support a variety of internal and external customer network requirements. CWDS must continue to have minimal combined delay for completion of transactions and data round trip to minimize response times to the end user. CWDS must continue to be friendly and acceptable to all users (LAN attached users, DSL/Cable modem and dial up). System


response must continue to be at the forefront of architected design requirements. CWDS must continue to be designed within the described network parameters provided below and using the information provided in Appendix U, L&I Technical Architecture Requirements. L&I currently has no plans to expand or upgrade the existing data circuits or network equipment for this project. Any proposed expansion of the network infrastructure necessary to support the project must be detailed in both the technical and cost sections of the proposal.

A. System connectivity must continue to be designed to minimize data traffic and flows between servers and components while maximizing performance and network bandwidth.

B. Where possible, CWDS must continue to have the ability to schedule upgrades, maintenance and code fixes, or new releases, without having to take the applications down or out of service. The upgrades must be seamless, transparent, and installed concurrently, without any impact to the end user.

C. CWDS must continue to have the ability to redirect and provide a friendly system message when the application is not available and out of service. This message must be easily customizable via an online interface.

D. CWDS must continue to have screens and correspondence documents designed to allow printing on standard LAN attached printers, supporting both Printer Command Language (PCL) and PostScript printing.

E. CWDS design must not require unnecessary Transmission Control Protocol/Internet Protocol (TCP/IP) port exposure to the Internet. TCP port usage for Internet-facing traffic must be restricted to well-known ports such as those required for secure Web browsing and secure file transfer. Proposed TCP ports and protocols must be documented.

F. All data at rest and file transfers must continue to adhere to L&I security requirements as described in Appendix X, L&I Enterprise Security Standards and Requirements. Also refer to Commonwealth OA ITB-SEC020 Encryption Standards for Data at Rest and OA ITB-SEC031 Encryption Standards for Data in Transit for further information.

G. The existing Web front end for the application must continue to leverage the existing L&I reverse proxy (ForeFront 2010) infrastructure at the Commonwealth’s Enterprise Server Farm. This arrangement allows the application and security infrastructures to reside in the L&I Data Center.

H. Digital certificate services must continue to be performed at both the ISA/ForeFront server and the proposed application servers in both UAT/Staging and Production.

I. File transfers for the application to or from external parties must continue to leverage the existing L&I FTP infrastructure.

6. Performance and Scalability RequirementsThe Selected Offeror must continue to provide a robust scalable architecture that will support the business needs and requirements of the system for CWDS. It is a critical requirement that the Selected Offeror’s solution continue to provide prompt response times for both inquiry and update transactions. The Selected Offeror is responsible for testing and assuring that the system’s performance and scalability continue to meet existing needs and future expansion requirements. CWDS Business Area Staff and L&I CWDS Technical Staff will participate in this testing effort.

CWDS must continue to accommodate the nightly batch and update processing needs. CWDS must be able to complete the batch update/processing during an overnight window or provide the capability to process batch jobs while the online system is active without adversely impacting the online system.


At a minimum, the Selected Offeror must recommend appropriate criteria (indicators and measurement values) that L&I-OIT should use for measuring system performance and address:

A. Response timeB. ConcurrencyC. System PerformanceD. Impact on Network PerformanceE. Scheduled Maintenance

Note: The project will only be considered a success when the resulting system meets the performance requirements detailed within this RFP.

The Selected Offeror must recognize that performance of CWDS, which extensively uses large databases, is largely affected by how optimized the database model is and the methods used to connect to and retrieve the information from the database. Database modeling and design must continue to be optimized and tuned to maximize operation and performance. An ongoing database monitoring and tuning strategy including SQL stored procedures, indexes, and views must be identified, documented and implemented.

The Selected Offeror must identify peak usage within units of work and maximize the load on the system within each unit of work. This must be documented within a deliverable that includes the results associated with stress and load testing and a resolution of any issues found.

CWDS must continue to sustain an acceptable performance response time with a minimum 1,000 concurrent user sessions and a concurrent transaction load rate of 100 active requests per second. Internal processing response time will be defined as the length of time upon receipt of the transaction at the Web Server request queue, internal processing for data retrieval and return to the Web Server for issuance to the workstation. It will not include network delay or client lag time. Normal internal transaction response time is two (2) seconds or less per transaction. Complex transactions that exceed two (2) seconds per transaction will be reviewed on a case-by-case basis and mutually agreed upon transaction times will be determined. The Selected Offeror must continue to design and architect CWDS to meet acceptable performance levels agreed to by the CWDS Project Management Team.

It is expected that the system will sustain a growth rate of 20% each year in data file sizes, internal/external customer usage, and transaction loads. This growth rate must be factored and included in the system design and architecture, ensuring the solution must be scalable through the term of the contract, with no degradation to response times or performance permitted. All hardware configurations, operating system configurations, or application modifications necessary to meet this requirement will be the responsibility of the Selected Offeror.

The system must have a 99.8% uptime. There will be minimal time (near zero) tolerance for unplanned or unscheduled system down time. The system must continue to be available to external customers 24 hours a day, 7 days a week. The Selected Offeror must adhere to the scheduled maintenance windows as established by OA/CTC Enterprise Server Farm and L&I-OIT staff. In addition, L&I-OIT server technicians may schedule upgrades on software and system code during scheduled or emergency periods. CWDS must have the ability to post friendly outage messages to internal and external customers notifying them of planned maintenance or system unavailability. Per Appendix KK, L&I Enterprise Standards, the Selected Offeror must use Tivoli for server, network, and transaction response time performance monitoring.


L&I ARM (Application Response Measurement) standard provides a way to manage business transactions. By embedding simple calls to an agent supporting ARM, an application can be managed for availability, service level agreements, and capacity planning. ARM includes details about the relationship between parent and child transactions. By leveraging the current installation of Tivoli’s ITCAM for Response Time Tracking (RTT) at L&I, applications can use the provided plug-in to code ARM calls. ARM calls should continue to be embedded into code developed for L&I with the ability to turn on and off this functionality when this level of transaction monitoring is required. At a minimum, the top 20% of transactions for the application must be ARM-enabled for monitoring purposes.

After the production deployment of each sub-release, the Selected Offeror will be responsible for identifying and monitoring the top five (5) most frequently used transactions in each release for availability and response time. After the last production deployment of each yearly major release, the Selected Offeror will review all monitored transactions to identify the top fifteen (15) most frequently used transactions encompassing all releases for availability and response time. When determining which transactions to monitor, the transactions affecting the general public will take priority. The Selected Offeror should note that transactions affecting the general public will include transactions used solely by the general public as well as transactions that are used by Commonwealth employees to provide information to the public. Adequate Tivoli response time tracking software must be proposed to measure these transactions.

The Selected Offeror’s design must continue to provide utilities to analyze and identify bottlenecks. This includes differentiating and measuring the components of response times such as network delay, client, and server components (application, Storage Area Networks, Database, etc). The CWDS Project Management Team will work with the Selected Offeror to establish Service Level Agreements along with fault identification and resolution mechanisms. The system must complete batch processes within a specific time frame agreed to by the CWDS Project Management Team.

7. Disaster Recovery RequirementsFor the purposes of this RFP, the Selected Offeror may assume that in addition to the primary site location, a warm off-site location has been designated and is provided by the Commonwealth. The Selected Offeror should assume the Commonwealth will continue to provide the redundant power sources, UPS capabilities, building security access, and communications.

The Selected Offeror must perform an analysis of the current Disaster Recovery Plan and make recommendations as necessary for changes or improvements. The Selected Offeror’s proposed solution must meet the Project’s Disaster Recovery requirements as defined within the Appendix LL, Disaster Recovery Plan.

8. Geospatial RequirementsThe Selected Offeror’s proposed solution must continue to meet the Project’s GIS requirements.

The Commonwealth executed a five-year enterprise license agreement, effective July 1, 2010, with American Digital Cartography, Inc (ADCi) for TeleAtlas products. The following data products are included with the enterprise license and the Selected Offeror will not be responsible for the cost of these data products:

A. MultiNet with routing attribution, state of PA B. MultiNet Display, state of PA plus a county buffer of surrounding states C. StreetMap Premium for ArcIMS and ArcGIS Server, nationwide coverage includes United

States, Canada, and Puerto Rico


D. MultiNet Administrative Areas, state of PA E. MultiNet Post (Zip+4 Centroids), state of PA F. MultiNet FGDC Metadata

The Commonwealth has also developed one-off and batch geocoding Web services that use the TeleAtlas Matchmaker software development kit and data.

The Selected Offeror must continue to work in consultation with OIT-BEA for the design and development of the proposed solution as it relates to GIS requirements. The Selected Offeror must design, develop, and implement the detailed plan and integration of the server-based GIS software within CWDS. This includes leveraging solutions developed by OIT-BEA or working with OIT-BEA to develop appropriate components required for the Project.

Address verification and geocoding services have been developed and are designed for 24 hours a day, 7 days a week availability. These Web services provide address verification, standardization, and geocoding capabilities. Returned information includes census data, FIPS codes, county name, and other relevant information for statistical analysis. The address verification Web services provide Coding Accuracy Support System (CASS)-certified capabilities. This CASS certification is a requirement for the Project.

9. Batch Processing RequirementsTo the maximum extent possible, all processing activity should continue to be provided in the online system. While there may be a minimal need to create additional batch processes, these interfaces should be minimized and will be the solution of last resort. The Selected Offeror must make use of DBMS-provided features to the maximum extent possible. CWDS must continue to comply with the requirements defined in Section 4.1.2, Shared Service for Enterprise Job Scheduling – $Universe.

10. Additional Technical RequirementsThe proposed CWDS system must adhere to these additional technical requirements:

A. Continue to provide U.S. English spell checking of identified screens and forms. CWDS must continue to have minimal impact on server hardware and system resources. The system must continue to allow the CWDS technical staff to implement and expand spell-checking ability to other languages in a flexible manner.

B. All content in the application must continue to be written at the 6th grade grammatical level. An existing tool (Readability PLUS – Vocabulary Assessor) will be used to verify compliance with this requirement.

C. Support e-Signatures.D. Provide both template-based (parameter driven) and ad hoc correspondence and online

forms.E. Design to use an e-mail queuing system that allows application processing to continue in the

event of Simple Mail Transfer Protocol (SMTP) mail server unavailability. The system must continue to hold and queue all mail for processing when SMTP services then become available and process in timely manner.

F. Continue to provide a calendaring/scheduling function that will be used throughout the application within various modules.

G. All data elements used within the application system must continue to be stored within the database. Data elements are not to be stored in the Operating System file system. The only exception that may be allowed (as a last resort) is for some temporary data scratch usage. If


agreed to by the CWDS Project Management Team, the design must include clean up routines and processes to clear the temporary data files up.

H. The application must NOT send or accept dynamic SQL statements from the application tier.I. All application and SQL code connection strings must continue to be secured using

encryption or any other recognized security standard.J. Continue to provide standard data validation at the source of all input fields, including, but not

limited to, field edits, validation of totals, validation of e-mail address formats, validation and standardization of addressing fields.

K. Continue to use drop-down selections for data capture fields that are supported by reference tables and prevent free form entry.

L. Continue to provide the capability to pre-populate data fields with selected data from existing database information as defined in the business rules.

M. Continue to provide standard keystroke shortcuts to enable navigation, data capture, data entry, and context switching. Cursor placement to the first data capture field, or the error fields on data capture validation must be provided.

N. Always use four-digit year for all date captures.O. Continue to support concurrent batch and online transactions (real time and background

processing of large files).P. Allow a user to export dates from calendars within the new system and import the dates into

the user’s Microsoft Outlook calendar. Q. At a minimum, all database management system (DBMS) application written code must

continue to be compliant with ANSI-92 coding standards or higher (such as ANSI-99 or ANSI-2003) for SQL. If any coding standard has been upgraded or modified to the higher ANSI-99 or ANSI-2003 standard level, it must be used in the database to meet the minimum level for acceptability by the CWDS Project Management Team.

R. All DBMS system identity columns should continue to use standard primary key definitions and NOT use Globally Unique Identifiers (GUIDS) unless the design and requirement are accepted and approved by the CWDS Project Management Team.

S. All proposed DBMS schemas; models and data dictionaries must be documented using the CWDS Project standard (Refer to Appendix U L&I Technical Architecture Requirements). All data element and entities defined in the DBMS system must be self-documenting and use descriptor fields to facilitate the Metadata for a self-describing Data Dictionary.

11. Development RequirementsOngoing design and development of the system MUST continue to adhere to the following requirements:

A. Web-based browser internal and external customer interfaces, with a consistent, common and modern look and feel, and common navigation throughout the application.

B. Thin client solution with no downloading of executable code or caching of pages required on the client PCs.

C. Application code developed must be based on N-tier architecture; the business logic layer is separated from the presentation layer, allowing for the development of transportable business logic within and across the applications.

D. The application must meet the CWDS Project Technical software standards for application development and deployment. Refer to Appendix U, L&I Technical Architecture Requirements and Appendix KK, L&I Enterprise Standards for additional information.


E. All portions of the application code are the property of the Commonwealth and are to be coded on Visual Studio .NET 2008 or higher using VB.NET, ASP.NET and ADO.NET. Refer to Appendix U, L&I Technical Architecture Requirements and Appendix KK, L&I Enterprise Standards for additional information.

F. Application code must continue to be designed, developed, and deployed on the Microsoft Windows 2008 Enterprise Edition server 32-bit platform, with Internet Information Server (IIS) 7.0 or later release as the presentation and application services tier. Refer to Appendix U, L&I Technical Architecture Requirements and Appendix KK, L&I Enterprise Standards for additional information.

G. The program code must provide built in instrumentation code points to capture application performance data in Microsoft Performance Monitor (PERFMON), Microsoft Windows Management Instrumentation (WMI) and Microsoft Enterprise Instrumentation Framework (EIF).

H. The system must continue to be architected to interact with the most current and future supported releases of Microsoft Internet Explorer and Mozilla Firefox browsers. Operational support capability and accessibility must be maintained within the CWDS application for the then current and two (2) back-level releases of the browser software products. There must not be any requirement of specific browser option settings necessary, beyond the default settings of the browser, for the application to function properly. The World Wide Web Consortium (W3C) standards should be used as reference for browser specifications.

I. Allow for use of interpretive client side JAVA scripting or VB Scripting as needed, as long as no portion of the applications depends on the download of any executable code and meets all accessibility standards and compliance.

J. All COTS software products used must be maintained at the most recently released, and supported non-beta version level through the life of the contract, unless otherwise approved by the CWDS Project Management Team. Consideration for product compatibility and release stability will be assessed.

K. The application must NOT send or accept dynamic SQL statements from the application tier.

L. Continue to provide a robust error handling mechanism in the presentation, data, and application layer to capture and record errors, preventing masking of errors and data corruption. This error log must be viewable and administered by the assigned System Administrator staff. Error messages MUST be captured within database tables containing identifiers and references for easy customization by L&I CWDS Technical Staff.

M. All application transactions must continue to be wrapped in stored procedures or use ADO.NET to manage transactions.

N. Ensure that all work-in-progress is appropriately backed up and available to CWDS on a daily basis.

O. Include unit testing, component integration testing, system testing (including extensive Quality Assurance (QA) and regression testing), security testing, and load performance testing for each release.

12. Operational and Data Mart/Warehouse Reporting RequirementsThe proposed solution, beginning with the initial release must allow for an optimized reporting database, which will become part of the planned L&I Enterprise Data Warehouse. This reporting database must support daily, weekly, and monthly reporting; this includes scheduled and ad hoc reports. The Selected Offeror must provide seamless integration of the reporting system into the newly developed application system design. The reporting system presentation should have the same look and feel of the newly


developed system. All client access and authentication should come from the newly developed application, eliminating the standalone administration of the reporting system. The Selected Offeror is responsible for writing any and all interface programs to facilitate integration from the new application to the new reporting database.

The reporting database must:A. Continue to enable authorized users to perform statistical analysis and reporting using the

Project’s standardized products as outlined in Appendix KK, L&I Enterprise Standards. B. Continue to support and include both predefined and ad hoc queries for authorized users.C. Continue to provide automated assistance for business users creating queries.D. Continue to provide querying capability that supports the following functional abilities:

1. Case sensitive and non case sensitive queries2. Ability to match parts of words, whole words or multiple word phrases3. Boolean (and/or) combinations of keywords4. Approximate matches (phonetic match, sound-alike)5. Structured queries that allow matches constrained to certain fields6. Ability to show matched lines or entire matching records7. Ability to specify limits on the number of matches returned8. Allow unlimited prefix or suffix by using “wild cards”9. Comparison operators (Equal, not equal, greater than, less than, like, not like)

E. Continue to include the ability to execute queries and reports on a scheduled or user-designated basis, and present the output in predefined report templates.

F. Continue to provide a mechanism for authorized users to save and modify report layouts.G. Continue to include the extraction and creation of data tables and/or validation extract files. H. Continue to include the extraction of data files as input to the interfaces as found on the

CWDS Interfaces tab of Appendix MM, CWDS Business Context Overview.I. CWDS must continue to include the functionality to gather all the data necessary to meet

requirements.J. Continue to assess, design, and prepare implementation plans to support a data

mart/warehouse.

Development and maintenance of the L&I Enterprise Data Warehouse and the BWDP Data Mart must include:

A. Maintaining and expanding the Enterprise Data Warehouse relational data model for holding the “single version of truth” for Enterprise data across L&I agencies.

B. Maintaining and expanding the BWDP Data Mart dimensional (star schema) data model for holding pre-aggregated business metrics data as defined by BWDP business reporting requirements.

C. Maintaining and developing Extract, Transform and Load (ETL) jobs for extracting data from various specialized L&I systems, including the CWDS application, and loading it into the Enterprise Data Warehouse using the SAP Business Objects Data Services toolset or using Microsoft’s SQL Server Integration Services (SSIS) toolset.

D. Maintaining and developing ETL jobs for extracting data from the EDW, pre-aggregating and calculating business metrics, and loading it into subject-area specific data marts, such as the BWDP Data Mart, using the SAP Business Objects Data Service toolset. Development and maintenance of both ETL layers includes job scheduling and performance tuning.


E. Work with L&I staff to maintaining the Business Intelligence (BI) layer, including Universes, Business Objects Web Intelligence reports, and Xcelsius interactive dashboards.

F. Analyzing business requirements, identifying new metrics and performance indicators, and developing additional reports, Universe ad hoc capabilities, and dashboards for BWDP and other agencies within L&I.

G. Assist L&I staff in migrating all reporting to the new L&I shared installation of BoE.H. Work with L&I staff to update the EDW based on updated/changing requirements.


appendix r - web viewthe selected offeror’s proposed l&i-oit training, ... must be...

Documents