4:00 - 4:05 – Announcements (5 minutes)
4:05 - 4:30 – Duke Kunshan University Update – Jennifer Francis, Bob Johnson, Chris Derickson (15 minute presentation, 10 minute discussion)
What it is: Duke Kunshan University will welcome the inaugural undergraduate degree class in August of 2018. They will offer undergraduate students a Duke-quality education and academic experience culminating in a Duke University degree and the opportunity to live and study in both the US and China.
Why it’s relevant: This presentation will review readiness for the fall semester and changes within Duke and the Office of Information Technology to help augment IT support for Duke Kunshan University during this epic milestone.
The number of applications for the Duke Kunshan University undergraduate program has exceeded expectations with 3143 submitted for 225 available slots. 251 international applicants have been admitted. Most of the applicants are from mainland China with the rest coming from over 50 countries. The decisions have gone out, particularly on the international side similar to the way this is done in the United States. The "yield" process for those students has started. The PRC (People's Republic of China) process is different in that this happens after the GaoKao exams are completed. Of the 225 slots, 175 will be PRC candidates.
Regarding faculty positions, last year DKU had 1300 applicants for Fall 2018 in Natural Sciences and Engineering, Social Sciences, and Humanities. The review process included search committees and Skype interviews with about 60 candidates coming to Duke's campus in May for in-person interviews. There were 24 candidates for final interviews at DKU with 24 offers extended (22 accepted). The program start date is expected to be August 27, 2018. DKU recently held "Campus Days" and of the 800 invitation letters sent out, 795 were accepted within 24 hours indicating high interest in the institution.
There are a lot of projects to complete to meet the anticipated first-day-of-classes date of August 27. Some of the projects are relatively straight-forward but others like "One Card" and "PeopleSoft HCM" (Human Capital Management) are more complex. DKU has matured as a graduate school but expanding into the undergraduate world is new to them. OIT staff will be onsite to provide assistance with allocating resources and setting a realistic IT agenda. OIT staff have been working with the DKU administration and operations team and believe the project goals are attainable and realistic given the time frame. The incoming number of students may be low enough for simpler processes, but the intent is to establish an infrastructure that can handle a larger population. For that reason, projects have been prioritized so that the ones that are not necessary for the fall start date have been deferred until next year. One complicating factor is that it has been difficult to retain staff in some of the technology positions. For the next 5 months, the director of IT at DKU will be assisted by an OIT staff member at least until the launch of the undergraduate program.
The SISS implementation at DKU has been broken into two phases with Phase 1 nearing completion. Phase 1 includes admissions, student recruitment, accounts and records, and advising. PeopleSoft is a hosted solution out of Chicago but there is an intent to use the cloud-based PeopleSoft option when it is ready. Key system integrations that need to be in place before opening day include authentication, identity management, general ledger, banking, Sakai, housing, and campus card. Authentication through Shibboleth is almost completed. Identity management still needs work. They are currently working on the general ledger integration with YonYou financial systems. An interface needs to be developed with the China Construction Bank for issuing refunds. The Sakai integration needs to be in place so the courses and the rosters are populated allowing enough time for the faculty to create their course content. It is difficult to get textbooks into China so there will be a heavy dependency on digital documentation. The housing system also needs an interface with PeopleSoft.
The guiding principles for Phase 2, starting in July running through December, is to use as much delivered functionality as possible with minimal customization and complexity and enable DKU to be as self-sufficient as possible with the Duke main campus serving in an advisory role. Huron has been an implementation partner with the modules in Phase 1 and the goal is to optimize their expertise going forward as production support.
The DKU Readiness Assessment was divided into phases. Phase 1 included 3 "waves" with Wave 1 focused on Admissions. This system is live and has been successful. The challenges are that this is new and processes are not established. There are some suggestions for automation and the planners are setting expectations to defer this until processes are documented. Wave 2 is devoted to student registration, advising, and financials with a current focus on user acceptance testing. Wave 3 focuses on recruiting and marketing. The Oracle Cloud Recruiting product is a part of this wave. One of the challenges is that these products are "North American-centric" and use an email address as a primary identifier for access to the recruiting tool. An email address is not a reliable identifier in China. They're moving towards a "go live" date in June.
As far as SIS Phase 2 starting in July, responsibilities will be divided so that Duke serves in an advisory capacity. There may be some activities that are handled by DKU alone such as automated test loads where DKU has already done this. There will be some tasks that DKU and Huron will complete because the financial aid module is the first one that Huron is responsible to deliver. There are some tasks that DKU and Duke will do such as applicant self-service (something Duke understands very well). And there are things that the DKU and the vendor would complete such as delegated access for bill payment with the China Construction Bank.
For Gap Analysis, there are issues in staffing as far as the student information system is concerned. We can supplement that staffing and have identified three areas: an experienced functional leader/administrator, a functional or business analyst, and a technical developer. As far as the risks in the timeline, there is a tendency to have a "scope creep" and business processes are constrained by "vanilla implementation."
As much as possible, Duke is trying to pass on its expertise in implementing systems. One of the challenges is that we have a very customized system and are trying to limit this at DKU. That said, we can provide information on best practices when customization is necessary. This also applies to faculty who go over to China to teach in that they may not have the same amenities or customizations in the system. There are challenges in enabling certain Sakai modules when there is uncertainty of the ability of the module to work in the DKU system.
There has been heavy involvement from Duke leadership and staff with DKU and core functional offices including the registrar's office, financial aid, the Provost's office, and faculty. One of the challenges has been the 12 hour time difference (meetings are 7 to 9 in the morning or 7 to 9 at night). There have been times when Duke staff traveled to DKU. This included a full-time SIS employee who helped with graduate admissions and business processes. OIT has also contributed, with one administrative person and one programmer working on-site for several months. Some technical issues require on-site assistance such as testing the batch process for importing DKU rosters from Peoplesoft into Sakai. There is also a Sakai upgrade requiring vendor support. The Duke Security office has assisted with a policy for the collection of sensitive data using Strong Box (a Duke Box customized tool). These are just a few examples of the interdependencies between Duke and DKU.
The gaps that have been identified are "short", "medium", and "long-term". The short-term gap is that the residential management system needs to be Shibbolized for administrative access. The medium-term gap is that DKU is using the Sponsored Accounts tool with Duke SAP dFac as the system of record. The faculty will need a different system to support DKU's implementation of an Identity Management system. Once this is in place, the Sponsored Accounts tool can be decommissioned for DKU. The long-term gap is that DKU faculty will need to develop their own process for making faculty appointment, promotion, and tenure (APT) decisions. They are unable to use the modules that we use an SAP.
Q: How many matriculates do you expect?
A: 251 international students were admitted and DKU is anticipating between 25% and 30% yield, a "best guess" (for the PRC acceptances, the estimate is 35%-50%). This is because the process is different since there is no contracting until after the GaoKao exam is completed and educational choices are ranked. For Fall 2019, there are 1500 applicants applying for 20-25 positions at DKU and it is likely that there will be a more selective process for which candidates are brought to Duke. There are complicating factors involving immigration, legal, taxation, human resources, Duke, and DKU procedures.
Q: For the project list, are new items being added faster than they get removed?
A: Yes and gap analysis is one of the main items on the agenda for the OIT staff arriving on site at DKU.
Q: We understand DKU to be a separate instance of the student system. Students will not be added to Duke's system until graduation. What happens if the student leaves the program? Will they eve be added to Duke's system?
A: No, they will not. They won't be considered Duke students until they complete their degree. This differs from Dukes policy which is that if a student attends two semesters, they are considered an alumni. The Duke transcript does not exist for a DKU student until the student receives a degree.
4:30 –4:45 – Grading Assist Tools – Dev Dabke (10 minute presentation, 5 minute discussion)
What it is: Burgeoning enrollments in the Computer Science and Electrical and Computer Engineering departments (measured in hundreds rather than dozens in core courses) put great pressure on giving students timely feedback about their work. ECE/CompSci350 is a digital design course where students develop software models of complex digital systems that requiring testing and evaluation. As head undergraduate TA for this course, Dev Dabke was in a good position to understand the challenges and opportunities presented by automating aspects of project grading. At its core, AG350 is an autograder, but it provides extensive and controlled feedback; a snappy user experience; and a secure and convenient tool for instructors to deploy tech-based assignments.
Why it’s relevant: AG350 is an ambitious project that will provide current and hopefully future generations of Duke students a renewed grading feedback experience; the framework of AG350 could be relatively easily retargeted to other courses that involve creating software artifacts that require testing.
Several courses at Duke use an "autograder". Characteristics of a good autograder include consistency, speed, and the ability to provide comprehensive feedback. Even a small project with 25 lines of code can still bog down a teaching assistant. For that reason, several courses at Duke, especially in Computer Science, are using an autograder. The enrollment for CS201 was 268 students. It's not feasible to hire a lot of teaching assistants for reviewing the coding assignments which means there is an opportunity to programmatically grade these projects and handle this workload. "AG350" came as a result of this opportunity. The goals or requirements for this project were first, that it could test projects. The application should also be secure, scalable, and accessible.
The team that developed this tool were made up of 5 undergraduates covering the "stack" from the user interface to the core infrastructure using Microservices (an architectural style that structures an application as a collection of loosely coupled services). The application was intended to be scalable so that if a large class submitted projects, additional VMs could be spun up to meet the demand. The choice of Microservices architecture was a compromise between flexibility and development time. The individual services communicate with each other and there is a centralized code base. There are multiple technologies in the stack held together with javascript using best practices for version control and code documentation to develop a better code base.
The user interface and logo were developed by the same user resulting in a cohesive project and the disability alliance was consulted to make sure the application met accessibility requirements. The creators also have continuity plans in place with 3 sophomores on the team to continue work on the AG350 autograder application.
Q: Talk about the security of this application and the privacy of a student assignment.
A: The developers were operating with the intent to ask for only what is needed during the authentication and authorization phase. The developers have imported modules that are handling authentication and authorization. They have not integrated Shibboleth but are working toward that.
Q: How are you getting feedback to the students?
A: They are working with the teaching instructors to rework them for the autograder. The autograder supports granular feedback. For example, one of the assignments is to calculate velocity and position of planets and the autograder will show all input and output with support for showing specific details surrounding what the student used for input and the expected output compared to actual output.
Q: In terms of language targets, is the infrastructure neutral as long as it is a language that can construct well-defined test cases?
A: They have a good sense of the languages in stacks that are used in the courses. At this time there are 5 stacks. As needs evolve, someone from the team can introduce a stack. The developer's view is that the autograder is more accurate if it's given a framework for evaluating the project.
Q: Would you consider a feature suggestion that would encourage students to start preparing earlier for their projects? An example would be a series of hidden test cases students can examine and use that are only accessible for a short activation period.
A: As we continue developing AG350, we do want to work with instructors to make the tool have practical useful features like the one suggested. They have experimented with using custom QR codes on exams with paper tests.
Q: Is the name of the tool associated with course?
A: It was used in many courses including AG350 but that was just the name of the project. In AG350, the students design their own pipeline processor that runs in hardware and in software that needs to be tested to make sure the computer works correctly.
Q: How are you handling the security concern of running unknown code from unknown sources from multiple users in the same environment?
A: The test cases and environments are containerized which allow them to change the configuration as needed including disabling networking.
Q: How many faculty are working with you on this project?
A: About a half dozen.
4:45 - 5:15 – Endpoint Management and University IT Security Updates – Richard Biever (20 minute presentation, 10 minute discussion)
What it is: Duke University IT support staff can utilize a number of endpoint management services to support efficient maintenance of computing devices. Tools such as SCCM (System Center Configuration Manager), Casper, and BigFix allow IT staff to automate their support and ongoing maintenance of managed devices. One of the most important and popular network security products available, anti-virus software, is undergoing a change from Symantec to Crowdstrike. Endpoint management services enable IT staff to automate the process of uninstalling and installing important software like anti-virus protection on managed devices.
Why it’s relevant: Unknown or unidentified devices on the network are a risk to every other device on the network. Having visibility into all devices on the network is critical to protecting Duke’s data and computing resources. Endpoint management tools provide Duke IT with an accurate inventory of the devices on the network, their patch status, and to whom they belong. This update will also include why Duke made the decision to move from Symantec to Crowdstrike and the value added in protecting Duke’s network and our devices.
Computers are an extension of ourselves. It is important to take care of these devices, protect them, and keep them patched. Duke-owned devices must have software agents installed that verify they are remaining patched, are running approved antivirus, and are encrypted (laptops). Antivirus options for personal use are available from software.duke.edu.
5:15 - 5:30 – Planisphere Update – Paula Batton and Sean Dilda (10 minute presentation, 5 minute discussion)
What it is: Planisphere is a web application that allows primarily IT staff to monitor Endpoint Management systems including network traffic and registrations. It is integrated with Casper, SCCM, BigFix, Proteus, DHCP, and Radius logs and allows for tracking the lifecycle of endpoints; including current states of security patching, encryption status, warranty expirations, and much more.
Why it’s relevant: OIT developed Planisphere to allow for ease of reporting and monitoring of endpoint devices across campus. This presentation will highlight the state of Planisphere today and what we have learned about what is on our network.
Planisphere came about after inquiries from the IT council and the Security Office to have visibility into ownership and patch management of Duke-owned equipment. Planisphere presents the aggregate data from these data sources into a single tool saving time and improving accuracy. Planisphere functions as an inventory tool and lets viewers know current activity and location for a device.
Previously, staff would have to use as many as six different tools in order to determine the location of a single piece of equipment and who owned it. This was compounded if you were dealing with multiple pieces of equipment. Planisphere makes this activity much simpler. It goes out and queries all of the data sources (JAMF, Big Fix, SCCM, and several networking tools and logs) and looks at identifying factors (MAC address, the serial number, etc) to create a unique entry for every device on campus. All available information is presented, more if this one device is seen in 15 different systems or less if it was only seen on the network.
There are several different use cases for Planisphere. The first is the end user. Transparency was a primary requirement for this tool. Users with a Duke netid can go into Planisphere and see information about equipment assigned to or associated with them. Planisphere shows network entries, what operating system it believes is running, and the data sources that contain information about these devices. Links to these data sources are in the tool and accessible if the user has privileges.
The second use case is IT staff. For them, Planisohere is an inventory and reporting tool. Planisphere permits IT staff to update incorrect data. Staff can also add custom fields which provides flexibility and customization and can include unique data like fund codes. Staff can also use Planisphere to generate reports on departmental devices. These custom reports use filters to exclude data not relevant and can be exported to a CSV file. The URL to that report can be saved and revisited so that staff can execute the report again which is updated with the current data.
The third use case is troubleshooting. A device may be causing trouble on the network. It is possible to search Planisphere using the MAC address or hostname. In fact, Planisphere was useful during the project to get all Duke computers enrolled in an endpoint management system. Planisphere was able identify equipment on the network but not being managed.
Another use case is handling the "quarantine" of compromised equipment. The previous process was labor intensive and time-consuming and involved multiple systems. Meanwhile, users who may have been affected would call the Service Desk who could not always determine if a quarantine was in effect. Planisphere was expanded to support this function with information on the reason for the quarantine. Users can see if they are affected without having to contact the Service Desk. If a machine is actively involved in a security incident, the Security Office can quickly put that machine in quarantine and contact the user.
For future directions in Planisphere, the developers are working to add Crowdstrike data and import some patch information. The Security Office currently runs reports to determine if certain critical patches have been applied and must visit multiple tools to get this information. We want to pool all this data into Planisphere. Ultimately, the goal for Planisphere is get this into the hands of the faculty, staff, and students who can see what is happening with their computers or their identities.
Q: Does Planisphere have the capability for an API and is there documentation for it?
A: Yes. There is a documentation link on the page. These tools were were developed in an "API-centric" way.