• UC Davis
• IET Home

CAES: Faculty and MSP Recruitment System

Sponsor

College of Agricultural & Environmental Sciences (CAES)

Contacts

Business

Adam Getchell, Julie Fritz

Technical

Adam Getchell, Scott Kirkland

To View Entire Submission

• Faculty and MSP Recruitment System (Draft)
• Process Flow Diagram (added 4-11-2008)

Reviewers

Core contributors to this review included Alex Alfieri (IET), Janet Brown-Simmons (Chair of ADMAN), Irene Horgan-Thompson (Human Resources), Bob Ono (IET), Michele Platten (Human Resources), Eric Prosser (College of Biological Sciences), Katie Stevens (Office of Administration), Joshua Van Horn (IET), Thomas Wiley (UC Davis Extension), and Everett Wilson (Academic Personnel). Comments were also solicited through the Dean's Technology Council (DTC), Technology Infrastructure Forum (TIF), and other similar venues.

Feedback Received to Date (3-27-2008)

Revision History

3-27-08

Initial feedback, along with responses from the project sponsor

Contents

• Reviewer Observations and Comments
• Reviewer Suggestions and Advice
• Questions, Potential Gaps, and Requests for Clarification
• Human Resources Review
• Academic Personnel Review
• Campus IT Security Coordinator Review

Reviewer Observations and Comments

• Many reviewers had questions or concerns regarding potential overlaps between the CAES Recruitments application and HR's upcoming PeopleAdmin system. Both systems will support MSP recruitments, and while academic recruitments won't initially be supported in PeopleAdmin, HR indicates that such support could be implemented later. More detailed comments from Human Resources and Academic Personnel are specifically highlighted below, but it's clear from the breadth of feedback that stakeholders would benefit from additional clarity in this area.
• Perspectives regarding the potential return on investment for the system were mixed. Some reviewers indicated that the system seems well-suited to the requirements of the college. One stated that the application “will result in a cost-savings for the University, while providing a valuable service.” In contrast, another reviewer indicated that the ROI was not clear. Estimating the total cost at around $88,000 based on the submission, the reviewer wondered what savings were anticipated to offset this cost. This reviewer further expressed that the submission was focused more on technical details than on the underlying business case.

Sponsor: This is at least partially due to the genesis of the project. Recruitments wasn't initiated as a campus wide, large scale system mandated top-down. Rather, as part of the normal process of determining the IT priorities for the College, the need for an on-line Recruitment system bubbled up from the College Academic Personnel Unit and corresponding staff within the departments and centers. An existing system, developed by Plant Sciences, was in use already, on a recharge basis. While the system was quite popular, it had a number of limitations that needed to be addressed. When the Deans and Policy Council met, they determined that, based on programming time estimates and other costs, it was a worthwhile investment to create a College-wide Recruitment system, given the workload required per faculty recruitment, and the number of upcoming recruitments. PeopleAdmin and MyInfoVault were considered, but the requirements of the project were outside the scope of these existing projects. Ultimately, the business case was already decided based on staff workload and functionality needed within a particular timeframe.

• At a technical level, reviewers found the CAES Recruitments application to be a well planned and tightly designed enterprise. Based on modern technologies with a clear path for back end upgrades and overall scalability, the system seems well-designed for security and extensibility. It has a solid foundation and will integrate well with other campus applications via the web services interfaces. The usual points of concern (ADA compliance, authentication/authorization, modularization and flexibility of design) are addressed with aplomb.
• Reviewers specifically praised the modularity of the roles management function. By integrating the internal roles management system (CatBert) via web services, the application allows for future use of the Campus Roles Management System when that project is completed. MyInfoVault (MIV) is also mentioned as a potential integration point. In addition, the system makes use of campus authentication (Distauth/CAS), with the ability to use either.  Given the current state of CAS, reviewers felt this was a very good way to implement authentication.

Reviewer Suggestions and Advice

• Due to the heavy use of web services at all levels of the application, such services should be well documented as early as possible, if that has not already been done. One of the main reasons for using web services in a SOA is to allow you to easily interchange modules as new technology or services become available. To facilitate that type of independence/flexibility, and strengthen the future viability of their system, good documentation of the web services is advised.
• The application is described as not yet fully ADA compliant. This should be complete before a general roll-out.
• The sponsor provides a visual of the database, but there is no visual of the process flow. Without a process flow diagram, it is not clear what the application does at a business level, nor what the major changes are between versions 1.0 and 2.0.

Sponsor: Per this suggestion, we've prepared an additional process flow diagram.

Questions, Potential Gaps, and Requests for Clarification

Information Flow

Departments outside of the CAES Deans Office may not realize that use of the proposed system provides the CAES Deans Office with information they usually wouldn't have (e.g., gender and ethnicity information), as well as information that could potentially be requested under the freedom of information act (e.g., title code, as used in the upcoming voting module). These issues are most likely quite resolvable with the support of the Office of Academic Personnel, but it is a loose end that isn't covered in the submission.

Use Beyond CAES

The proposal indicates that the system will be offered more broadly to other schools and colleges.

Q: Is this application going to be shared freely or held close to CAES?

Sponsor: The intent is to make the application available to the general campus for use on an opt-in basis.

Q: What cost will other schools need to plan for when desiring to join in?

Sponsor: We anticipate that the funds provided by the Offices of the Chancellor and Vice Provost for Recruitments 2.0, which will be architected for potential campus-wide use, should cover costs for general use.

Q: Can colleges use the code and create their own internal system customized to themselves?

Sponsor: At this time, we do not believe it is beneficial to fork the code for Recruitments 2.0; we have very specific architecture and coding guidelines, and we don't believe that appropriate quality control could be maintained across multiple versions of the code and application. However, due to our development environment, we could work with interested units with sufficient programming experience in .NET to provide access to our source code and project management system, Team Foundation Server, so that they would have the ability to check in desired feature changes. As with all changesets in TFS, they would be audited according to coding, security, business, and architectural standards.

Q: Who will provide/fund the ongoing maintenance, support and development on a long-term basis?

Sponsor: CA&ES Computing Resources Unit is committed to providing ongoing maintenance, support, and development of Recruitments. However, the reality of this process is that requested changes would be vetted with stakeholders and evaluated for both technical and business process impact. Once evaluated, if the change was requested by CA&ES, it would probably be handled internally via the allocation of additional CRU programmer time. If the change was requested by other units, arrangements would have to be made for additional developer time and/or resources.

Q: Directed more generally to the campus at large: with various departmental systems becoming candidates for campus-wide use, how will UCD manage/integrate the variety of back-end technologies?  What are the long-term costs of doing so?

Integration/Overlap with Related Systems

Reviewers noted the potential for integration with other campus systems such as EDMS, MyInfoVault, and PeopleAdmin, indicating that such integration is a good idea and should be looked at closely. 

Q: Are there any plans to link this application from the HR web site?

Sponsor: Recruitments is already fairly linkable – each position posting has a parsable URL which could be included on the HR or other sites. Recruitments 2.0 has RSS feeds, and other web services are being discussed for inclusion.

Q: How does the proposed MSP recruitment feature of the new system interact with or replace Job Machine II and/or the upcoming PeopleAdmin system? Does the proposed MSP recruitment feature feed into those centralized systems or is it a shadow system?

Sponsor: Most MSP Recruitments are already delegated, so the Recruitments application would convert this process from a manual one to a web-based version. As such, there wasn't a centralized system to feed into; however, we could provide feeds via Web Services to an appropriate source. We try to avoid creating shadow systems whenever possible, but the reality is that many systems don't have all of the data we need, in a format that we can use, with the ability to make updates automatically. We continue to work with the data stewards of the relevant data sources to minimize the use of local data marts whenever possible.

Q: Given the present status of PeopleAdmin, how does this application fit within the big picture? (Does it provide functionality not in PeopleAdmin? Does it duplicate features of PeopleAdmin? Is it an improvement over PeopleAdmin for the features it provides?)

Sponsor: To our understanding, PeopleAdmin was never intended for Faculty Recruitments, and a single faculty recruitment system could never be mandated for the campus, given the national system used by Mathematics. Additionally, the timeline of deployment, and the general experience with large centralized systems deployment on campus made us comfortable with the prospect of moving forward to create an application that best suited the needs of academic recruitment.

Alternatives

Q: To what extent were other similar institutions polled for information about systems already developed for faculty recruitment? Can we leverage something that has already been developed rather than building our own?

Sponsor: We looked at both the national faculty recruitment system in use by Mathematics, as well as Plant Sciences system. Plant Sciences provided documentation on the business rules in use in their system, and were extremely helpful in explaining both their business rules, and particular functionality. Additionally, we had further input from our Academic Personnel Unit, who had extensive familiarity with the Plant Sciences system. In a sense, we took the Plant Sciences system and re-implemented it from scratch using the best architecture, tools, and programming expertise we had available.

Priorities

Q: Assuming that development capacity is limited in CAES as it is elsewhere, has CAES considered the adverse impacts to other projects that pursuing this effort may create? 

Sponsor: We evaluated the requirements and timeline for this project in comparison with all other projects that the departments and College had, and the Deans and Policy Council allotted our programming time accordingly.

Timeline and Budget

Q: What amount of time will it take to develop this system?

Sponsor: Recruitments 1.0 was developed by Scott Kirkland, now our Senior Application Architect, who worked on it from June 2007 until October 2007, in consultation with Julie Beal, Director of the Academic Personnel Unit and her staff. Of course, knowledge in the tools, programming expertise, and frameworks took longer to develop, and was supported by Mr. Kirkland's aptitude, work ethic, and training.

Other web services (e.g. CatBert, our Roles Management System) were developed to support the needs of other applications developed by the Computing Resources Unit, and were architected to be as extensible as possible (e.g., CatBert has been through 2 revisions, and was preceded by an older system which was rewritten from scratch).

Q: What savings will there be to offset the cost of the proposed system to the University?

Sponsor: We think that 4 months to develop a usable system was a very economical investment that has already paid back its cost in staff time savings.

Q: The cost associated in training of users is $10,000.  Is this $10,000 included as a part of the labor estimate, is it in addition?  How many users are included in the $10,000 training estimate?

Sponsor: We think that the $10,000 estimate covers the total staff salary time of any training that needs to be conducted to use the system. This estimate is frankly not very firm, because we don't really know what the training needs will ultimately require. It could be off by an order of magnitude in either direction, but we think the simplicity and user-friendliness of the program will greatly decrease training costs, rather than the opposite.

HMTL Theme, CSS and XHTML Support

Reviewers identified HTML theme support as a great feature, and asked several questions about web mark-up and skinning.

Sponsor: All web pages are styled via CSS. We use transitional XHTML 1.0 because that's what Visual Studio 2005/8 uses. Until strict XHTML 1.0 becomes supported in the majority of browsers and toolsets, we don't see a particular business advantage to using it, although we do design for 504/508/ADA accessibility. Skinning at this point is limited to fairly simple graphics which represent the departments.

Security for Uploaded Files

Reviewers asked several questions about the content and security of files uploaded by applicants.

Q: Do the stored applicant PDF files contain any Personal Information?  Are these files scanned for such information? 

Sponsor: We don't solicit Personal Information (such as SSN or driver identification number) per the definitions of PPM 310-22a, nor do we provide fields in the database for that information. Applicants would have to insert such information into their references or other documentation for us to get them. As for scanning the uploaded PDF files for personal information, there doesn't presently seem to be a tractable way doing so automatically. All current scanning tools are manual, and all stored documents are PDF.

Q: Is the file system where the PDF files are stored encrypted? 

Sponsor: No; however, this could be done if needed.

Q: Are the files that are uploaded scanned for viruses/malware? 

Sponsor's response: Not at this time; however, the upload process uses a file upload service which performs some checks to ensure it is a PDF document (see below).  

Q: Are the files ever loaded into the application in such a way that malicious code could be executed?

Sponsor: We take great care to address the security and reliability of our programs.

Files are not directly uploaded to the SAN, but use a file upload service which stores files using randomly assigned names which are referenced via database entries. The files themselves are only ever handled internally by the file upload code.

All data handled by the application is wrapped within the context of a Data Access Object (DAO) generic class, which has defined properties depending upon what type of object it is (example, PositionDAO, FileDAO), all with inherited properties from the generic DAO. In turn, DAOs are passed around using Business Logic Layer (BLL) classes, which perform sanity checking using Validators, which can know the type of object they are validating, and hence, what types of properties it should have. Once the BLL has validated the DAO, it is then persisted using whatever methods (object-> database or object-> file); in the later case, there's also the use of the TryParse method in .NET to perform further sanity checking prior to bytestream conversion.

As we find further test cases we can expand the scope of the validators, for example, the GetFileDao().Save() method saves an object which is then passed to the ValidateBO<File>.isValid() method; we can simply add additional checks as needed to ValidateBO, which will automatically be invoked. Note the whole method is wrapped in a Transaction, which can be logged or rolled back as needed. The following code snippet demonstrates the approach (note that Exceptions are expensive in .NET, so we don't throw them for typical branches):

if (ValidateBO<File>.isValid(file))
      {
           SaveReferenceWithWatermark(fileUploadReference, file.ID.ToString());
           currentReference.ReferenceFile = file;

           using (new NHibernateTransaction())
           {
                daoFactory.GetReferenceDao().SaveOrUpdate(currentReference);
           }

           Response.Redirect(FormsAuthentication.DefaultUrl);
      }
      else
      {
           lblUploadStatus.Text = "There was an unexpected error uploading your file";
}

Q: One of the administrative functions (2.a.ii.1) allows text including HTML mark-up to be uploaded. Is this text checked for proper HTML formatting? Is it checked for javascript or other code?

Sponsor: HTML markup is stored as templates in the database, with TryParse and business object validation. Almost all internal objects in the program follow business rules enforced on them via the Business layer as described above.

Auditing

Q: Praising the application's integrated auditing function, a reviewer asked for additional details regarding the audit tables/logs.

Sponsor: Auditing can be done on a very granular level using NHibernate; it is possible to record every single SQL statement and its results into the database. These permissions are typically handled by the programmers and database settings. For performance reasons, auditing is not usually enabled, but further work could be done to provide for some default levels of auditing in the next revision.

Code Migration

Q: Is version control in place to control what is being done by various programmers?

Sponsor: As previously mentioned, we use Microsoft Team Foundation Server, which is based on SharePoint with a SQL Server backend. Team Foundation Server gives the usual version control facilities (check-in, reversion, branching, merging) plus auditing (check-in policies, code test invocation, code analysis and coverage, external tool invocation), plus project management (alerts, bug tracking, tasks, workflow), plus automated builds (nightly, continuous, etc.)

Q: Is a separate development instance of the application/database used for rolling out code changes and updates?

Sponsor: We have development, test, and production instances. Development versions are for day-to-day programming; a proposed production version is then rolled to test via MSI mechanisms (plus the few manual tweaks, which we try to minimize). Test to production migration is done systems staff, rather than programmers (who may be on hand to advise).

Vulnerability Scanning

Q: Has the system been tested for vulnerabilities using the Watchfire application?

Sponsor: We checked into this very early during the Watchfire project, and initially pushed for inclusion of the Watchfire APIs so that builds of Recruitments could automatically invoke a Watchfire scan. Unfortunately, the Watchfire APIs require the full desktop version, which wasn't purchased, and Watchfire itself currently does not handle CAS authentication very well. We remain interested in using Watchfire for application security testing, but it is difficult to do so for a project of this nature at this time.

Human Resources Review

The business need for an electronic recruitment system as described in the CAES Faculty and MSP Recruitment System submittal resonates strongly with Human Resources.  Recently, HR submitted the PeopleAdmin project for administrative review under Policy 200-45.  The PeopleAdmin project is an automated position description, recruitment and applicant tracking system.  The business need for automation of these processes is clear, and central Human Resources has funded and is implementing a system that will automate staff compensation, classification and recruitment actions including MSP actions.  This is a significantly wider scope than the CAES project.  The need for each college to assume the cost and ongoing maintenance for automated functionality of MSP recruitments is being addressed with the implementation of PeopleAdmin.  In discussions with the CAES Director of Human Resources, HR was able to provide information about PeopleAdmin that answered both the concerns and requirements of the college. 

Automated faculty recruitment actions can be accommodated within PeopleAdmin, however, that is not within the scope of the current project.

In summary, the staff side of this project is already being addressed through the PeopleAdmin Project with an implementation date of September 2008.  PeopleAdmin will provide applicant tracking, recruitment, online screening, online position management and a historical record of all actions related to individual positions.  This mitigates the need for stand alone, college-specific applications to support the MSP recruitment process.

Academic Personnel Review

When asked to comment on the potential overlaps between CAES Recruitments and PeopleAdmin, the Office of Academic Personnel responded as follows.

Faculty Recruitments

Because Mathematics uses a nationally-based recruiting system, we do not foresee any academic system becoming mandatory. That being said, for academic recruitments we prefer CAES Recruitments over PeopleAdmin:

• Cost: PeopleAdmin development is far more expensive. There would also be significant costs for any future changes.
• Personnel time: Academic Personnel does not have the person power to explain the academic process to an outside vendor. In contrast, the CAES system is already extensive and the programming team has direct access to business users via an agile development philosophy.
• Usability: CAES Recruitments is extremely well-designed from a customer perspective. In addition, many of the planned add-ons are UC Davis-specific (e.g., voting procedures, interim & final recruitment reports, possibly academic recruitment plans).

In summary, for academic recruitments the CAES product is better and can move more rapidly to maintain a superior position. Since UC Davis has not yet moved a project from a Dean's office to a campus wide level we need to be conservative in projecting success, but barring unforeseen problems it's difficult seeing PeopleAdmin's cost, time commitment, and quality becoming comparable enough to justify using it.

MSP Recruitments

We do not have an opinion regarding MSP recruitments, beyond cross-academic/MSP recruitments in the School of Medicine. (Because the academic side is more demanding/cumbersome in its requirements, we would recommend performing these as academic recruitments and sharing the data.)

Campus IT Security Coordinator Review

To the extent that recruitment applications handle personal information, they could represent additional risks to the university should unauthorized access be gained to the application or data. While the use of SSL encryption is documented in the project description, the integration of application vulnerability scanning into the development/maintenance process is not mentioned.  If the application will provide access to personal identity information, Web application security scanning should be formally identified as an integral part of the development/maintenance program for the application and supporting database. Use of the campus licensed Watchfire AppScan Enterprise solution could be a starting point. Watchfire also produces AppScan Desktop which offers greater support for Web services.

Sponsor: We checked into this very early during the Watchfire project, and initially pushed for inclusion of the Watchfire APIs so that builds of Recruitments could automatically invoke a Watchfire scan. Unfortunately, the Watchfire APIs require the full desktop version, which wasn't purchased, and Watchfire itself currently does not handle CAS authentication very well. We remain interested in using Watchfire for application security testing, but it is difficult to do so for a project of this nature at this time.

We've programmed the application defensively to ensure data is properly inputted, validated, and persisted using Data Access Objects and Business Logic Layers. The application does not collect personal information, as currently defined in PPM 310-22a:

“personal name along with Social Security number, California driver identification number, financial account information, health insurance information, or medical account information”