UC San Diego & UC Irvine Collaboration Academic Personnel On-Line Review Dawn Reser, Academic...
Preview:
Citation preview
- Slide 1
- 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
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, UCSDviet@ucsd.edu 35