Presentation Transcript

1. UC San Diego & UC IrvineCollaboration

   Academic Personnel On-Line Review Dawn Reser, Academic Personnel Services, UCSD Joan Tenma, Academic Personnel, UCI Max Garrick, Office of Information Technology, UCI Viet Truong, Administrative Computing and Telecommunications, UCSD UCCSC August 8th, 2011 University of California, Merced Campus
2. Faculty Review Process At the Department Level: Candidate / Candidate Alternate Department Staff Department Chair Voting Faculty Departmental Ad Hoc Committee At the Division/School Level: Dean Staff Dean At the Campus Level: Academic Personnel Office Committee on Academic Personnel (CAP) Executive Vice Chancellor/Vice Provost
3. THE FACULTY MERIT REVIEW JUNGLE
4. THE FACULTY MERIT REVIEW JUNGLE Process starts over: - more meetings - more photocopying - more signatures - more emails 1. Department Staff assembles the file 2.Candidate reviews and certifies file 10. Department copies file for Dean 6. Recommendation routed to CHAIR for signature 8. Department copies file for Candidate 11. Dean returns file to Department 3. Copies made for Voting Faculty 9. Candidate reviews and certifies again 5. Department writes recommendation 7. New copies made for Faculty to review again. 4. Faculty review and VOTE
5. DEEPER INTO THE JUNGLE Dean reviews & makes recommendation Academic Personnel checks file for accuracy Copies made for Committee (CAP) Process starts over: - more meetings - more photocopying - more signatures - more emails Additional information required File returns to Dean Dean returns file to Department
6. History in a Nutshell
7. Background Application began at UCSD as single-campus installation 2005 – research into available software 2006 – user groups 2007 – development began 2008 – Phase I in production Collaboration with UCI began with Recruit Feb 2009 – decision to implement UCI’s Recruit at UCSD Oct 2009 – Recruit launched at UCSD Lessons learned
8. Background, continued Collaboration continued with Review Oct 2009 – began to implement UCSD’s review at UCI July 2009 – implemented Phase 2 for UCSD May 2010 – implemented Phase 3 for UCSD Aug 2010 – implemented at UCI Nov 2010 – single code base version 3.5 for both UCSD and UCI Mar 2011 – version 4.0 implemented for both
9. Where We Are Today Oct 2011 – external referee letters and chair’s personal statement Release date to be determined Electronic Archive Above scale salaries
10. Vision – Long Term Strategic Plan Identifies the business needs Identifies system’s general goals Identifies who will utilize AP On-Line Identifies the required functions, including a “wish list” Lists the planned components of complete AP On-line suite of services Created in collaboration http://academicaffairs.ucsd.edu/_files/aps/docs/AP_On-Line_%20Strategic_Plan.pdf
11. Vision – Long Term, continued Planned modules Service Modifications Career Achievements Compensation Reporting Seamless integration between e-Recruitment Plan, Review, and Recruit Interface with other campus data sets All developed in collaboration
12. Achieving the Vision through Collaboration Making the Wish List Manageable Shared Solutions Shared Resources Streamlining & Refining the Business Process Software as a Service…
13. What is “Software as a Service”? San Diego hosts APOL Review application for Irvine San Diego & Irvine jointly determine product direction Core developers located at San Diego Service governed by Service Level Agreement Application branded to meet campus identity & graphics standards
14. Disparity in Online Processes in UC UC System has a wealth of online processes At a local level, one campus may use an inefficient paper process while another uses a custom-built Web application Software as a Service (SaaS) can bridge this disparity in online capabilities If the conditions are right We can deliver low-cost, best-of-breed apps to all UC campuses
15. Multi-Campus Creates Efficiencies One hosting campus, many customer campuses Resources ($$$) focused at the provider campus One code base, many branded sites No code forking. All enhancements assumed to be shared by all campuses One operations team, distributed support and training Provider campus must create operational efficiencies or risk becoming overwhelmed with tech support, work requests, product change requests, etc…
16. Multi-Campus Creates Best Practices Constraint: minimize customizations One application & code base Objective lower cost vs. build-your-own Solution: jointly determine process Requires: strong partnership between UCI & UCSD Academic Personnel & IT End result: going forward, UCI and UCSD Implement best practices from each campus Eliminate sub-par practices where possible
17. Multi-campus Collaboration Musts Full support from executives Frequent, high-quality communication Clear roles & responsibilities Collaborative requirements & verification Acknowledge and fix what’s broken Empowered team members Documented vision & purpose Memorandum of Understanding Documented Service Level Agreement
18. Savings Through SaaS Single development team Hosted and supported by one university Collaborative Testing Single source code for multiple APOL instances Customizations and brandings through configuration Business collaboration on product’s features
19. The Saas Challenge Branding Provide UCI users with a familiar look and feel Customization Accommodate business process disparity Interoperability HR, roles and SSO data remains on client’s system Data Security Protect client’s data from exposing to other clients Collaborate with multiple set of stakeholders
20. Principals for Moving Forward Develop campus-agnostic solutions Solutions should not be specifically designed to solve UCI’s Review implementation. Instead, solutions should be reusable so that other campuses may more easily implement APOL Leverage existing technologies When implementing the multi-campus components of APOL, use open source frameworks or design patters where possible. This approach saves development time by allowing developers to take advantage of proven and well-documented technologies Maintain one code base One code base for all campus-specific branding and customization required by each campus.
21. Solving “Branding” Challenge Transform APOL to UCI’s looks and feels: Images: campus logs, colors, screen layouts Campus-specific language: alert messages, email notifications Review file: required artifacts Solution: Apply Spring Theme Business Logic driven by configuration UCSD UCI
22. Solving “Customization” Challenge Implement University’s specific business process: Faculty’s bonus and File Summary’s output Solution: Apply Strategy, Adapter and Factory Method Patterns UCSD UCI
23. Solving “Interoperability” Challenge Data Integration: Roles Faculty’s info Faculty’s history Directory Authentication: Integrate with client’s Shibboleth Authorization: Client’s roles + APOL roles
24. Solving “Interoperability” Challenge, continued Enabling Authorization - Cross-campus authentication capability and integrating the Review roles module with UCI’s access control system Apache Shibboleth Enabling Data Integration - Bidirectional integration provide a means for exchanging data between Review and UCI databases RESTful SOAP Web Services
25. Solving “Data Security” Challenge APOL contains sensitive review data that must be secured and isolated Solution: Encapsulation data through: User’s roles Hardware Software Configuration
26. New Features SDLC Final Requirement Docs WBS Requirements Validation Alpha Build Requirements Validation Requirement Docs GatherRequirements Est. Release Date Construction Updated Requirement Docs Change Request Change Control Board Change Control Board Beta Build Go-Live Change Request Integration QA QA UAT Sign-Off QA Build
27. Defects and Minor Enhancements SDLC Final List Patch Meeting Patch Meeting Defect/Enhancement List Candidate List Estimate Effort Enter Issues Construction Alpha Build LOE & Propose Schedule Integration QA Sign-off QA Beta Build Deploy
28. Development to Deployment UCSD Servers Staging Production Training Development QA Development User Test Go-Live Integration Test Integration Test Staging Production Training Development QA User Test Go-Live UCI Servers
29. Project Management Tool
30. UCI’s Implementation Effort Business Process Mapping UCI’s AP Offices UCSD’s AP Offices Integration Efforts UCI & UCSD’s AP Offices UCI OIT – Kim, Ray, David, Henry and others UCSD ACT – Jennifer, Chris and Matt Branding & Customization Development Efforts UCSD’s ACT
31. Ongoing Collaboration Effort Development and Resources: 1 technical project manager 3 Java developers Ongoing support from infrastructure, DBA and Middleware members Business Support UCI resources UCSD resources Product Management UCI resources UCSD resources
32. Questions and Answers .....

33. UC San Diego & UC IrvineCollaboration

    Academic Personnel On-Line Review Dawn Reser, Academic Personnel Services, UCSD dreser@ucsd.edu Joan Tenma, Academic Personnel, UCI jtenma@uci.edu Max Garrick, Office of Information Technology, UCI max.garrick@uci.edu Viet Truong, Administrative Computing &Telecommunications, UCSD viet@ucsd.edu