UC San Diego & UC Irvine Collaboration 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 8 th, 2011 University of
California, Merced Campus
Slide 2
At the Department Level: Candidate / Candidate Alternate
Department Staff Department Chair Voting Faculty Departmental Ad
Hoc Committee Dean Staff Dean Academic Personnel Office Committee
on Academic Personnel (CAP) Executive Vice Chancellor/Vice Provost
At the Division/School Level: At the Campus Level: Faculty Review
Process
Slide 3
THE FACULTY MERIT REVIEW JUNGLE
Slide 4
1. Department Staff assembles the file 2. Candidate reviews and
certifies file 3. Copies made for Voting Faculty 4. Faculty review
and VOTE 5. Department writes recommendation 6. Recommendation
routed to CHAIR for signature 7. New copies made for Faculty to
review again. 8. Department copies file for Candidate 9. Candidate
reviews and certifies again 10. Department copies file for Dean 11.
Dean returns file to Department Process starts over: - more
meetings - more photocopying - more signatures - more emails THE
FACULTY MERIT REVIEW JUNGLE
Slide 5
Dean reviews & makes recommendation Academic Personnel
checks file for accuracy Copies made for Committee (CAP) Additional
information required File returns to DeanDean returns file to
Department Process starts over: - more meetings - more photocopying
- more signatures - more emails DEEPER INTO THE JUNGLE
Slide 6
Slide 7
Slide 8
History in a Nutshell 8 UCSD Review 2008 UCSD Recruit 2009 UCI
Review 2010 Both Review 2011
Slide 9
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 UCIs
Recruit at UCSD Oct 2009 Recruit launched at UCSD Lessons learned
9
Slide 10
Background, continued Collaboration continued with Review Oct
2009 began to implement UCSDs 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 10
Slide 11
Where We Are Today Oct 2011 external referee letters and chairs
personal statement Release date to be determined Electronic Archive
Above scale salaries 11
Slide 12
Vision Long Term Strategic Plan Identifies the business needs
Identifies systems 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
12
Slide 13
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 13
Slide 14
Achieving the Vision through Collaboration Making the Wish List
Manageable Shared Solutions Shared Resources Streamlining &
Refining the Business Process Software as a Service 14
Slide 15
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
Slide 16
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
Slide 17
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
Slide 18
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 18
Slide 19
Multi-campus Collaboration Musts Full support from executives
Frequent, high-quality communication Clear roles &
responsibilities Collaborative requirements & verification
Acknowledge and fix whats broken Empowered team members Documented
vision & purpose Memorandum of Understanding Documented Service
Level Agreement
Slide 20
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 products features
20
Slide 21
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 clients system
Data Security Protect clients data from exposing to other clients
Collaborate with multiple set of stakeholders 21
Slide 22
Principals for Moving Forward Develop campus-agnostic solutions
Solutions should not be specifically designed to solve UCIs 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. 22
Slide 23
Solving Branding Challenge Transform APOL to UCIs 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 23 UCSD UCI
Slide 24
Solving Customization Challenge Implement Universitys specific
business process: Facultys bonus and File Summarys output Solution:
Apply Strategy, Adapter and Factory Method Patterns 24 UCSD
UCI
Slide 25
Solving Interoperability Challenge 25 Authentication: Integrate
with clients Shibboleth Authorization : Clients roles + APOL roles
Data Integration: Roles Facultys info Facultys history
Directory
Slide 26
Solving Interoperability Challenge, continued 26 Enabling
Authorization - Cross-campus authentication capability and
integrating the Review roles module with UCIs 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
Slide 27
Solving Data Security Challenge APOL contains sensitive review
data that must be secured and isolated 27 Solution: Encapsulation
data through: Users roles Hardware Software Configuration
Slide 28
New Features SDLC 28 Gather Requirements Requirements
Validation Construction Requirement Docs Final Requirement Docs
Change Control Board Integration QA UAT Sign-Off Go-Live QA Build
Alpha Build Beta Build Change Request Updated Requirement Docs Est.
Release Date WBS Change Request Requirements Validation Change
Control Board QA
Slide 29
Final List Defects and Minor Enhancements SDLC 29 Patch Meeting
Construction Deploy Estimate Effort Enter Issues Integration
Defect/Enhancement List Candidate List LOE & Propose Schedule
Alpha Build Beta Build Sign-off QA Patch Meeting QA
Slide 30
Development to Deployment 30 User Test Go-Live DevelopmentQA
Staging Production Training Development UCSD Servers UCI Servers
User Test Go-Live DevelopmentQA Staging Production Training
Integration Test
Slide 31
Project Management Tool 31
Slide 32
UCIs Implementation Effort 32 Business Process Mapping UCIs AP
Offices UCSDs AP Offices Integration Efforts UCI & UCSDs AP
Offices UCI OIT Kim, Ray, David, Henry and others UCSD ACT
Jennifer, Chris and Matt Branding & Customization Development
Efforts UCSDs ACT
Slide 33
Ongoing Collaboration Effort 33 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
Slide 34
Questions and Answers..... 34
Slide 35
UC San Diego & UC Irvine Collaboration Academic Personnel
On-Line Review Dawn Reser, Academic Personnel Services, UCSD
[email protected] Joan Tenma, Academic Personnel, UCI [email protected]
Max Garrick, Office of Information Technology, UCI
[email protected] Viet Truong, Administrative Computing
&Telecommunications, [email protected] 35
