Your SlideShare is downloading. ×
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
08-5878 (Amendment
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

08-5878 (Amendment

288

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
288
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. A REQUEST FOR PROPOSAL (RFP) RFP #08-5878 AGENT: Vera Laufenberg at (608) 262-3198 / FAX: (608) 262-4467 / TTY 608/262-0825 E MAIL: vlaufenber@bussvc.wisc.edu If NO BID (check here) and return. UNIVERSITY OF WISCONSIN – Madison Identity and Access Management Software Issued by: STATE OF WISCONSIN UNIVERSITY OF WISCONSIN - MADISON PURCHASING SERVICES Amendment #1 - August 17, 2007 NO PUBLIC OPENING Proposals must be submitted by September 6, 2007 - No later than 2:00 p.m. CDT NOTE TO PROPOSERS: Amendment #1 issued to: (1) replace Table of Contents – added ATTACHMENT I (Page 64-67); (2) Page 4 (Section 2.1- changed due date); (3) Page 36 (section 6.3.1.4 – removed word “external”); (4) Pages 45 and 46 replaced in their entirety; (5) added Attachment I (Pages 64-67), (6) provide questions and answers received from Proposers; and (7) The DUE DATE has been EXTENDED to 09/06/07 @ 2:00 PM CDT. PURCHASING SERVICES University of Wisconsin-Madison • 21 N Park St, Suite 6101 • Madison, WI 53715-1218 608/262-6121 • (Fax) 608/262-4467 • www.bussvc.wisc.edu • bids@bussvc.wisc.edu
  • 2. AMENDMENT #1 SUBMITTAL INSTRUCTIONS A completed and signed proposal response must be received and date/time stamped in by UW-Madison Purchasing Services prior to 2:00 p.m. CDT on the stated proposal due date to be considered. Proposals not so date/time stamped in shall be considered late. Late proposals shall be rejected. We have supplied you with a pre- addressed return label. Please fill in your vendor name and address on the return label to help us identify this transaction. Please use one of the options below for return of your proposal. MAILING: Original and seven (7) copies of mailed proposals must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218, prior to 2:00 p.m. CDT on the stated proposal due date. HAND DELIVERY: Original and seven (7) copies of hand-delivered proposals may be delivered by vendor or third-party/courier service. Proposals must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218, prior to 2:00 p.m. CDT on the stated proposal due date. E-MAILING: For your e-mailed proposal to be considered valid by UW-Madison Purchasing Services: 1. Send a complete copy of the entire response prior to 2:00 p.m. CDT on the stated proposal due date via e-mail to: bids@bussvc.wisc.edu. Submitting a proposal to any other e-mail address than bids@bussvc.wisc.edu does not constitute receipt of a valid proposal by Purchasing Services. 2. Original and seven (7) copies to be delivered (via hand delivery, mail or courier) within one (1) business day after the stated proposal due date must be received at Purchasing Services, 21 N. Park Street, Suite 6101, Madison, WI 53715-1218. Prior to the proposal deadline, proposer is responsible for confirming that their e-mailed proposal response has been successfully received. Proof of transmission doesn't constitute proof of receipt. The original e-mail submission must be supported by the last page of Section 6 “RFP Checklist and Submittal Page”. This page must be signed and returned via fax (608-262-4467) and must be received prior to 2:00 p.m. CDT on the proposal stated due date. RETURN ADDRESS LABEL:  OFFICIAL SEALED PROPOSAL NUMBER: 08-5878 DUE DATE: 09/06/07 TIME: 2:00 PM CDT NO PUBLIC OPENING INSERT VENDOR NAME HERE: ______________________________________ ADDRESS: ________________________________________________ ________________________________________________ ________________________________________________ UNIVERSITY OF WISCONSIN-MADISON PURCHASING SERVICES 21 N PARK ST, SUITE 6101 MADISON, WI 53715-1218
  • 3. UNIVERSITY OF WISCONSIN AMENDMENT #1 PROPOSAL NO.: 08-5878 PAGE(S) Attachment A – Specifications (19-44) Attachment B – Cost Proposal Form (45-47) Attachment C – Client Reference List (48) Attachment D – Supplier Diversity, Minority Business Enterprise (MBE) Program Commitment (49) Attachment E – Standard Terms and Conditions (50-53) Attachment F – Software Rider (54-59) Attachment G – Personal Services Rider (60-62) Attachment H – Designation of Confidential and Proprietary Information (DOA-3027) (63) Attachment I – UW Madison Enterprise IT Infrastructure: Current State (64-67)
  • 4. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 4 OF 63 Section #2: RFP Process Instructions 2.1 Applicable Dates DATE EVENT August 3, 2007 Date of Issue of the RFP August 13, 2007 Written questions due September 6, 2007 -- 2:00 PM CDT RFP Due Date (Local Madison Time) 2.2 Clarifications and/or Revisions through Designated Contact All communications and/or questions in regard to this request should be in writing and proposers are encouraged to FAX or e-mail written questions to the Purchasing Office. Verbal questions, when permitted, must be directed to Vera Laufenberg at (608) 262-3198. If a Proposer discovers any significant ambiguity, error, conflict, discrepancy, omission, or other deficiency in this RFP, they have five (5) business days prior to the RFP due date to notify, in writing, Vera Laufenberg at the address shown below of such error and request modification or clarification of the RFP document. All written questions will be responded to in writing and provided to all proposers. Vera Laufenberg UW Purchasing 21 N Park St, Suite 6101 Madison, WI 53715-1218 E-mail: vlaufenber@bussvc.wisc.edu PHONE 608/262-3198 -- FAX 608/262-4467 – TTY 608/262-0825 If a Proposer fails to notify the Purchasing Office of an error in the RFP document which is known to the Proposer, or which must have reasonably been known to the Proposer, then the Proposer shall submit a response at the Proposer’s risk and if awarded a contract, shall not be entitled to additional compensation or time by reason of the error or its later correction. In the event that it becomes necessary to provide additional clarifying data or information, or to revise any part of this RFP, supplements or revisions will be provided to all recipients of this initial RFP. 2.3 Preparing the Proposal To be considered, Proposers must respond to each of the requirements listed in Section #4 and per the attached Submittal Instructions. Responses should be formatted to correspond numerically to the requirements listed in Section #4. 2.4 Conflict of Interest By submitting a proposal, the proposer certifies that no relationship exists between the proposer and the University that interferes with fair competition or is a conflict of interest, and no relationship exists between such proposer and another person or firm that constitutes a conflict of interest that is adverse to the University.
  • 5. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 36 OF 63 6.3Consulting Services: There are two components to this portion of the RFP. The first is the Detailed Implementation Road Map, described below. The second component is a general price list for additional consulting resources that the University may need during the term of the contract 6.3.1 Initial Engagement-Detailed Implementation Road Map (for Madison Campus): The University Wisconsin-Madison will require a phased implementation of any IAM suite purchased, integrating the deployed capability in each phase with our existing infrastructure and any previously deployed capability. The initial engagement between your consulting services and the University Wisconsin-Madison will therefore be a detailed road map for the succeeding phases. The exact nature of those phases is to be considered negotiable until the road map is complete, but what follows is the University Wisconsin-Madison’s current understanding of the work required to deploy an IAM suite. Provide a detailed Statement of Work for a project that would cover this effort. On your Price Sheet, also give the estimated cost for this project. 6.3.1.1 Implementation Road Map  Policy analysis with multiple University-represented sponsors, constituents, and IT personnel.  Vendor garnering a complete understanding of the existing University identity management components, directories, and manual provisioning processes.  The map itself, with defined phases and milestones within phases.  Provide diagrams describing the migration from existing to new or the integration of existing with new.  Describe the general time frames associated with each phase.  Describe the primary team roles involved in each phase.  Describe the testing plan for measuring the success of each phase.  Describe the training or expertise required to complete each phase successfully. 6.3.1.2 Phase I - Replacement of Custom Identity and Affiliation Manager (UW Madison Special Authorization for Photo ID System)  Policy analysis.  Large data migration of identities, roles and attributes in production.  Creation of production and pre-production systems for new solution, possibly while maintaining a parallel solution using existing infrastructure to minimize source provider disruption. 6.3.1.3 Phase II - Replacement of Custom Linking Between Authoritative Source Systems  Policy analysis.  Multiple source system data transformations.  Moving sensitive data and accompanying security issues.  Process for reconciling multiple source data records into a single identity.  Process for unlinking improperly linked identities, such as when bad data is submitted from source system.  Process for communicating new identities or changes to identities to downstream systems.  Creating pre-production and production systems that communicate with authoritative sources. 6.3.1.4 Phase III - Replacement of Manual or Custom Provisioning to Key Systems  Policy analysis.  Business process analysis with possible consulting service to assist with process change.  Moving sensitive data and accompanying security issues.  Creating pre-production and production systems that provision to external University systems. 6.3.1.5 Documentation and Training  Describe the business, technical, and end user documentation provided.
  • 6. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 45 OF 63 ATTACHMENT B – COST PROPOSAL FORM Option 1: UW System Enterprise License 1st year 2nd year 3rd year 4th year 5th year Unlimited instances Maintenance Maintenance Maintenance Maintenance Maintenance Software Net Price Net Price Net Price Net Price Net Price Head count information is for reference only Net Total of Faculty, Staff and Students for all Campuses instance Price Software Please note: Fac/Staff data first/Student data second University of Wisconsin System-Enterprise Licenses Total head count is: 193,372 (28,497: 164,875) Source: UW System 2006 Fact Book Services Net Price UW-Madison Detailed Implementation Roadmap as described in Attachment A Technical Specifications- Section 6.3.1 Provide detailed Statement of Work and price for the project Price must include all travel expenses for contractor Consulting Positions Project Manager (hourly rate including expenses) Solutions Architect (hourly rate including expenses) Programmer Analyst (hourly rate including expenses) System Analyst (hourly rate including expenses) Business Analyst (hourly rate including expenses) Other Relevant Positions as proposed by contractor List position and hourly rate including expenses Additional Price List for Misc. Items rate Training - administrative - rate per day contractor site Training - administrative - rate per day customer site Other resources that may be required - please identify in detail
  • 7. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 46 OF 63 Option 2: UW System Campuses Purchase Instances Individually 1st year 2nd year 3rd year 4th year 5th year Maintenance Maintenance Maintenance Maintenance Maintenance Software Net Price Net Price Net Price Net Price Net Price Head count information is for reference only Net Total of Faculty, Staff and Students for each Campuses instance Price Software Please note: Fac/Staff data first/Student data second University of Wisconsin- Madison - includes Madison plus other Campuses for Shared Resources - 193,372 (28,497: 164,875) UW- Eau Claire - 11,588 (1,082:10,506) UW-Green Bay - 5,913 (565: 5,348) UW-La Crosse -9,482 (947: 8,533) UW-Milwaukee - 31,329 (2,973:28,356) UW-Oshkosh - 12,267 (1,197: 11,070) UW-Parkside - 5,417 (502: 4,915) UW-Platteville - 6,666 (655:6,011) UW-River Falls - 6,592 (602: 5,990) UW-Stevens Point - 9,835 (1,012: 8,823) UW-Stout - 9,200 (974: 8,226) UW-Superior - 3,215 (389:2,826) UW-Whitewater - 11,546 (1,023: 10,523) UW-Colleges - 13,084 (802: 12,282) UW-Extension - 1,092 (1,092: no student data) UW-System Administration - 248 (248: no students) Source: UW System 2006 Fact Book
  • 8. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 64 OF 67 Attachment I University of Wisconsin Enterprise IT Infrastructure: Current State Overview This document represents an overview of the current enterprise applications and infrastructure in place at the University of Wisconsin in support of the business needs of higher education. This document is intended to baseline the understanding of the University of Wisconsin’s current state to vendor representatives so that a roadmap for the adoption of enterprise application infrastructure (middleware) is well grounded. Enterprise Applications 1. Oracle/PeopleSoft Student Administration a. 10 of the 14 campuses in the UW-System have deployed – other 4 will deploy in the next 2-3 years b. Most deployments are done at the campus – with the exception of 2 deployments at the UW-Madison shared resource (FASTAR) service c. Customizations vary from campus to campus d. Most campuses will be @ 8.9 by end of year – one is thinking about staying @ 8 until 2008 e. Systems operated mostly autonomously with some sharing of code, experiences, tools and techniques. f. UW-Madison implementation is called ISIS – Integrated Student Information System 2. Oracle/PeopleSoft Financials a. Centrally deployed to most campuses within the UW-System. All campuses will be using within the next several years b. Adding Expense Reporting and Grants as modules within the next 1.5 years c. Currently upgrading to version 8.9 d. Possible future target for federated authentication and access management (integration with local campus authentication and authorization schemes)
  • 9. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 65 OF 67 e. Possible future target for presentation through multiple venues (integration with local campus portals or content management infrastructure) f. Work being done by the State of Wisconsin is influencing University of Wisconsin’s timelines and strategies (e.g. eProcurement) 3. Oracle E-Business Suite a. Internal business application for DoIT b. Storefront integrated with inventory and order modules c. Data feeds for customer base come from legacy Human Resource and student administration system 4. Legacy Human Resources/Benefits/Payroll a. Payroll is used by all campuses within the UW-System b. Faculty/Staff payroll is COBOL c. Student payroll is Oracle Developer application d. Human Resources (IADS – Integrated Appointment Data System) contains data about all employees in UW-System. Each campus accesses IADS data (via sFTP) to run their own shadow Human Resource systems (providing supplemental information about their employees) e. Benefits uses the same IADS model 5. Oracle/PeopleSoft Human Capital Management (HCM) a. Licensed – to be deployed in the next 2-3 years – not sure of version b. Questions surrounding benefits of partial implementation of HCM in support of workflows and/or system of record for employees c. Likely to need some level of federation in identity and access management d. Likely to be a popular source for data to drive detailed authorization decisions. 6. Clarify Customer Relationship Management (CRM) a. Help Desk application for UW-Madison campus is currently Amdocs/Clarify b. Data feeds for customer base come from legacy Human Resource and student administration system c. In early phases of evaluating future CRM solutions d. Some basic integration with uPortal e. Help Desk has developed a custom-built Knowledge Base 7. Oracle Collaboration Suite – Calendar a. Licensed for all students and staff for the UW-Madison campus b. Policy is to retain calendar account until NetID is de-activated (scheduled process – sometimes takes months) c. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS system d. WebISO enabled e. Available through uPortal (web client) f. Some basic integration with campus event systems through batch extract and load g. Calendar group management driven through batch extract and load of Human Resource information 8. Sun E-Mail a. Licensed for all students and staff for the UW-Madison campus b. Policy is to retain email account until NetID is de-activated (scheduled process – sometimes takes months) c. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS system d. WebISO enabled e. Available through uPortal (web client) 9. uPortal a. Open Source portal software (Madison campus only) b. Integration with student content – link to student center w/ single sign-on c. Advisor content required custom code to allow advisor to assume role of student d. uPortal is not the sole presentation layer for enterprise applications – many end users access these applications directly e. Some role-based content delivery based on very broadly defined roles (student, employee, applicant, etc) f. WebISO enabled
  • 10. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 66 OF 67 10. Desire2Learn CMS a. Web-based CMS built in ASP/SQL Server (moving to .NET) b. Interfaces are customizations created by vendor c. Primary interfaces are course roster (student, courses, instructors) feeds and eGrading d. Used UW-System-wide – authentication using AuthHub (a locally developed system for federated authentication) e. Potential for other CMS products to be run across the enterprise 11. University Directory Service (UDS)/Registry a. UW-Madison directory and registry services b. Populated from Human Resource system (FTP/file), PeopleSoft Student (DB Link), and “Special Authorization” database table (DB Link) – with potential for more feeds c. Central IT organization does not control data sources d. Feeds are Near real Time and batch e. UDS service consolidates these feeds into a master representation of the constituent with some consolidation of specific business information into broad roles (student, employee, applicant, etc) f. UDS masters campus identifiers and credentials (NetID, PVI, Campus ID, Photo ID) g. View of consolidated constituents (DRExport) is used as an attribute store and also populates LDAP and Kerberos services h. LDAP population sets service flags based on source system granting access to enterprise applications like uPortal, Calendar and email i. WebISO solution (pubCookie) uses LDAP service 12. IAA (Identification, Authentication, Authorization) a. Populated in the same manner as UDS/Registry – but for all campuses b. IAA masters system-wide identifier (SPVI) c. IAA is used for minimal authorizations based on attributes d. IAA has a custom proxy authentication service that authenticates users into enterprise applications using local credentials (Auth Hub) e. SFS will be using IAA Auth Hub for authentication in February 2007 f. Working towards a combined registry (UDS/IAA) g. Potential to migrate IAA/AuthHub to Shibboleth 13. Hyperion a. System-wide Business Intelligence suite b. Authenticated through IAA c. Used to access data views from data marts d. General interest around dashboards across System 14. Informatica a. System-wide Extract Transform and Load (ETL) tool b. Used sporadically (along with techniques like SQRs) to populate data marts 15. Kronos a. System-wide timekeeping application deployed to subsets of employees (primarily student employees) across various UW campuses b. Current pressure from campuses to integrate Kronos with IAA and Auth Hub 16. Xythos (My WebSpace) a. Web-accessible file storage system b. Licensed for all students and staff for the UW-Madison campus c. Policy is to retain account until NetID is de-activated (scheduled process – sometimes takes months) d. Entitled through service flag in LDAP – changes to authorization driven by role as defined in UDS system e. WebISO enabled f. Available through uPortal
  • 11. UNIVERSITY OF WISCONSIN PROPOSAL NO.: 08-5878 MADISON, WISCONSIN 53715-1218 AMENDMENT #1 PAGE 67 OF 67 17. Auxiliary Applications a. Large applications that are either purchased or custom-built b. Not necessarily run by central IT organization c. Examples include Housing, Parking, E-Commerce d. Main points of integration with enterprise infrastructure include authentication services, attribute delivery (either from IAA, UDS or data marts) and uPortal e. Frequent pressures from these applications for infrastructure that supports federation of identity and access management and multiple venues for presentation and integration. 18. Network access a. Comprehensive wireless infrastructure integrated with campus LDAP/RADIUS authentication system b. Some implementations of port-based authentication and access control on the wired network. c. VPN service integrated with campus LDAP/RADIUS authentication scheme. Little sophistication in authorization or access control logic. d. Many tactical deployments of transport-level proxies controlling access based on authentication. No holistic strategy and little in the way of sophisticated access control based on role or user data.
  • 12. AMENDMENT #1 QUESTIONS & ANSWERS FOR 08-5878 (IDENTITY AND ACCESS MANAGEMENT SOFTWARE) Q1: Section 1.1 Are you looking for changes to be tracked within the identities (themselves), or to changes to be tracked within the identity management suite itself (configuration changes? A1: Both Q2: I understand there are 900k identities (active and in-active), and growing. Can you help me understand the number of current active identities? Are these identities related in a 1:1 relationship with user accounts? Is there a way to distinguish between active and inactive users? A2: There are 250,000 active identities. No- they are not related 1:1 with user accounts. There are attributes that distinguish between active and inactive users. Q3: Section 3.4 Who and how it’s determined whether the general market conditions change, regarding the lowering of prices? A3: The Contract Manager from UW- Madison Purchasing Services in conjunction with the Division of Information Technology (DoIT) is the sole judge of the acceptance of any prices changes whether it’s an increase or decrease. Increases are limited to changes in the Federal Consumer Price Index (CPI) from the previous year. This language is included in the RFP. Q4: Section 4 Are you looking for a replacement of your current LDAP directory, or an additional LDAP directory for greater functionality? A4: Either/Both Q5: General Question: I didn't see it, but it is important to ask. Are you looking for the proposal to include hardware? A5: No Q6: Are there any other IAM modules in the UW's stack that are not listed in the RFP document? Are there any other details such as version, etc for those products? A6: No Q7: Would it be possible to get an extension of at least 14 days for proposal submittal? A7: The deadline has been extended until September 6, 2007 at 2:00 p.m.
  • 13. -2- Q8: We only have two questions regarding pricing our solution at this time. Our proposed solution will be based on a User Based Pricing Model. We classify Users as either Internal Users or External Users. An Internal User is part of the Enterprise. (i.e. employee of the State) An External users is not part of the enterprise (i.e. Student, Alum, Contractor, Supplier) For Option 1: UW System Enterprise License Total head count is: 193,372 Out of the 193,372 Users, can you classify how many are Internal or External Users? A8: The detailed breakdown is provided in the chart below which is part of the answer to Question 9. This information will replace the chart in Option 2 of Attachment B: Cost Proposal. Option 1 will also be updated to reflect separated numbers. However, Proposers should note: Their response to the Cost Proposal for Options 1 and Option 2, should be provide in the format directed by the RFP process. Their proposal may not be considered if they do not comply with the instructions. Proposers may submit an alternative (Option 3) but at this point, it’s for information purposes only. Q9: For Option 2: UW System Campuses Purchase Instances Individually UW- Eau Claire - 11,588 UW-Green Bay - 5,913 UW-La Crosse -9,482 UW-Milwaukee - 31,329 UW-Oshkosh – 12,267 UW-Parkside - 5,417 UW-Platteville – 6,666 UW-River Falls - 6,592 UW-Stevens Point - 9,835 UW-Stout - 9,200 UW-Superior - 3,215 UW-Whitewater - 11,546 UW-Colleges – 13,084 UW-Extension – 1,002 UW-System Administration - 248 For each location User Count, can you separate by Internal Users or External Users?
  • 14. -3- A9: The information is below. It will replace Option 2 of the Cost Proposal. In addition, Option 1 has changed to reflect the Fac/Staff and Student counts separated. Software Please note: Fac/Staff data first/Student data second University of Wisconsin- Madison - includes Madison plus other Campuses for Shared Resources - 193,372 (28,497: 164,875) UW- Eau Claire - 11,588 (1,082:10,506) UW-Green Bay - 5,913 (565: 5,348) UW-La Crosse -9,480 (947: 8,535) UW-Milwaukee - 31,329 (2,973:28,356) UW-Oshkosh - 12,267 (1,197: 11,070) UW-Parkside - 5,417 (502: 4,915) UW-Platteville - 6,666 (655:6,011) UW-River Falls - 6,592 (602: 5,990) UW-Stevens Point – 9,835 (1,012: 8,823) UW-Stout - 9,200 (974: 8,226) UW-Superior - 3,215 (389:2,826) UW-Whitewater – 11,546 (1,023: 10,523) UW-Colleges - 13,084 (802: 12,282) UW-Extension - 1,092 (1,092: no student data) UW-System Administration - 248 (248: no students) Q10: The only other question we have is what requirements does the U of WI-Mad have for the Affirmative Action Plan. It sounds to us like it may be different than the Federal AAP. A10: The reporting requirements based on dollar and employee thresholds are lower than the Federal Government Affirmative Action Plan. Their reporting requirements are more extensive than the State of Wisconsin. Q11: Section 6.3.1.2 References replacement of the Custom Identity and Affiliation Manager. Is this synonymous with the current UW-Madison role-based access management system? A11: Yes Q12: Section 6.3.1.4 What are the "Key Systems" along with expected instances that are within scope of a Services engagement SOW? A12: Please reference Attachment A: Requirement 2.5.2 of the RFP. In addition, the list is below:  ERP Applications o PeopleSoft Student Administration o PeopleSoft Financial Management o PeopleSoft Human Capital Management o PeopleSoft Enterprise Expenses  RDBMS (local accounts) o Oracle RDBMS (on various platforms) o DB2 on IBM Z/OS o MySQL o MS SQL Server
  • 15. -4- Q13: Will UW consider an extension to the due date of August 30 for the responding vendors? A13: The deadline has been extended until September 6, 2007 at 2:00 p.m. Q14: Can you share with us who else has been invited to respond? A14: State of Wisconsin procurement processes do not allow for this information to be released at this time. Q15: We are making an assumption that the consulting SOW and estimated pricing is limited for the Implementation road map section as defined in section 6.3.1.1 only. Please confirm. Hourly prices will address the implementation services required based on the output of the roadmap. A15: The assumption is not correct. Proposers should provide an estimated price for the Detailed Implementation Roadmap based on the information provided in Section 6.3.1.1. This information may be considered as part of the cost evaluation at the sole discretion of the University. In addition, Proposers should provide hourly rates for the resources defined in Section 6.3.2 of Attachment A: Technical Specifications. These resources may be engaged at any time during the five year life of the contract by the University. For each engagement a specific SOW will be developed by the Contractor based on the rates offered as part of their response to the RFP. During the term of the contract prices may be adjusted based on Section 3.0 of RFP Specification Q16: In the RFP, there is a lot of reference to U of WI's current infrastructure and the new products compatibility with it. Do you have a document which would give us a better picture of the current environment state at U of WI? A16: The University has added Attachment I: “University of Wisconsin Enterprise IT Infrastructure: Current State” to the RFP. Q17: 3.1 Architecture: This is the language form the RFP: Describe at a high level the elements and technologies that make up this capability and their relation to each other. Provide diagrams. What are the advantages of this architecture? Specify any disadvantages or limitations of this architecture. If your solution supports multiple high-level configurations, describe the advantages and disadvantages of each. Describe the logical architecture of the servers that make up your solution. 3.1.5 Hardware Requirements: Provide the minimum and recommended hardware requirements for each server given the scale of our implementation. QUESTIONS: Q17a: How many authorizations per second are required? A17a: See background information in RFP Section 3.0 Performance and Contract Requirements for this information. The directory performs an average of 600 operations per second. Q17b: Are all transactions in SSL? A17b: All Web Access Management Connections are SSI encrypted. SSL/TLS encryption of LDAP connections is offloaded onto separate hardware, so does not affect hardware planning.
  • 16. -5- Q18: 6.3 Consulting Services: This is the language from the RFP: 6.3.1 Initial Engagement-Detailed Implementation Road Map (for Madison Campus): The University Wisconsin- Madison will require a phased implementation of any IAM suite purchased, integrating the deployed capability in each phase with our existing infrastructure and any previously deployed capability. The initial engagement between your consulting services and the University Wisconsin-Madison will therefore be a detailed road map for the succeeding phases. The exact nature of those phases is to be considered negotiable until the road map is complete, but what follows is the University Wisconsin-Madison’s current understanding of the work required to deploy an IAM suite. Provide a detailed Statement of Work for a project that would cover this effort. On your Price Sheet, also give the estimated cost for this project. 6.3.1.1 Implementation Road Map • Policy analysis with multiple University-represented sponsors, constituents, and IT personnel. • Vendor garnering a complete understanding of the existing University identity management components, directories, and manual provisioning processes. • The map itself, with defined phases and milestones within phases. • Provide diagrams describing the migration from existing to new or the integration of existing with new. • Describe the general time frames associated with each phase. • Describe the primary team roles involved in each phase. • Describe the testing plan for measuring the success of each phase. • Describe the training or expertise required to complete each phase successfully. 6.3.1.2 Phase I -Replacement of Custom Identity and Affiliation Manager (UW Madison Special Authorization for Photo ID System) • Policy analysis. • Large data migration of identities, roles and attributes in production. QUESTIONS: Q18a: How many identities to be migrated? A18a: All current identities. Q18b: Is any authoritative data currently encrypted and if so in what format? A18b: Currently pass word data is encrypted but are looking to add for example: • SSN information • Drivers license data. The encryption format is DES3. Data is encrypted in the database and in the directory. Q18c: Where, how and in what format is this information stored today? A18c: RDBMS Q18d: What are the authoritative source(s) that feed the existing production system? A18d: PeopleSoft Mainframe- DB2 and IMS Flat Files
  • 17. -6- Q18e: What is the back end technology for the authoritative source(s)? A18e: PeopleSoft Mainframe- DB2 and IMS Flat Files Q18f: How many roles to be migrated? A18f: All – average of 12 roles per identity Q18g: Approximately how many backend resource attributes are managed/effected by role membership to each role? A18g: Range of 1 to 20 Q18h: Where, how and in what format is this information stored today? A18h: RDBMS and LDAP Q18i: How many user related attributes in the form of geography and other general user information is being migrated. A18i: Average of 30 attributes coming from the four different sources systems. Q18j: Where, how and in what format is this information stored today? A18j: RDBMS and LDAP Q19: All numbered and bulleted points are language from the RFP 6.3.1.3 Phase II -Replacement of Custom Linking Between Authoritative Source Systems • Policy analysis. • Multiple source system data transformations. QUESTIONS: Q19a: How many authoritative sources are in the scope of this phase? A19a: Approximately six. . Q19b: For each authoritative source how many attributes are synchronized between the authoritative source and the backend resources including the identity system? A19b: An average of four attributes that we currently “reconcile”. Q19c: What is the backend technology for the authoritative source? A19c: PeopleSoft Mainframe- DB2 and IMS Flat Files • Moving sensitive data and accompanying security issues. Q19d: What attributes need to be encrypted when stored on backend resources or in the identity system? A19d: Currently pass word data is encrypted but are looking to add for example: • SSN information • Drivers license data. The encryption format is DES3. Data is encrypted in the database and in the directory.
  • 18. -7- Q19e: Is any authoritative data currently encrypted and if so in what format? A19e: Currently pass word data is encrypted but are looking to add for example: • SSN information • Drivers license data. The encryption format is DES3. Data is encrypted in the database and in the directory. • Process for reconciling multiple source data records into a single identity. Q19f: What are the source data record systems? A19f: PeopleSoft Mainframe- DB2 and IMS Flat Files Q19g: What is the backend technology for each? A19g: PeopleSoft Mainframe- DB2 and IMS Flat Files • Process for unlinking improperly linked identities, such as when bad data is submitted from source system. • Process for communicating new identities or changes to identities to downstream systems. Q19h: What are the downstream systems? A19h: Please reference Attachment A: Requirement 2.5.2 of the RFP. In addition, the list is below:  ERP Applications o PeopleSoft Student Administration o PeopleSoft Financial Management o PeopleSoft Human Capital Management o PeopleSoft Enterprise Expenses  RDBMS (local accounts) o Oracle RDBMS (on various platforms) o DB2 on IBM Z/OS o MySQL o MS SQL Server Q19i: What is the backend technology for each? A19i: Attachment A: Technical Requirements: “Section 2.5 Provisioning Accounts and Managing Identities in Client Systems”, contains the detailed information. Q19j: What change information needs to be communicated downstream to each? A19j: All attribute changes or account creation/termination. • Creating pre-production and production systems that communicate with authoritative sources. Q19k: What are the authenticate source systems? A19k: PeopleSoft Mainframe- DB2 and IMS Flat Files
  • 19. -8- Q19l: What is the backend technology for each? A19l: PeopleSoft Mainframe- DB2 and IMS Flat Files Q19m: What information needs to be communicated for each? A19m: All attribute changes or account creation/termination. Q20: All numbered and bulleted points are language from the RFP 6.3.1.4 Phase III -Replacement of Manual or Custom Provisioning to Key Systems • Policy analysis. • Business process analysis with possible consulting service to assist with process change. • Moving sensitive data and accompanying security issues. • Creating pre-production and production systems that provision to external University systems. QUESTIONS: Q20a: What will be the scope of this phase in regards to external university systems? A20a: This phase relies heavily on what you propose in the previous sections of the SOW. Q20b: What is the backend technology for each external system in the scope? A20b: Yet to be determined. Q20c: What type of information / attributes needs to be sent to external University systems? A20c: We are changing this requirement in the RFP. Please reference the replacement page in this addendum it removes the word “external”. Q20d: Is this a push of data to the external University systems or a synchronization of data? A20d: We are changing this requirement in the RFP. Please reference the replacement page in this addendum it removes the word “external”. Q21: Attachment B – Cost Proposal Form In order for us (Sun) to price our software we need to know Full Time Faculty count. We have this data for all UW System campuses (from IPEDS data) except UW-Extension. Can you please provide Full Time Faculty count for UW-Extension? A21: 1,092 Q22: We are vendor that can only provide a response to the user provisioning section of the RFP. In addition, we do not provide a web access management component and we would have to assume that Microsoft AD was the preferred directory services solution for the U Wisconsin. A22: The University will only accept proposals that are for an entire Identity and Access Management Suite of products and related services and training.

×