Whitepaper repository

A diagram of priorities, listing the network as a foundation that nothing else would work without, then servers & systems built on top of the network, then identity & access. Built on identity & access is security, then commodity services like email, the learning environment, or document storage/collaboration, then user support. The most narrow element, dependent on everything below, is the specialized services for individual units that are unique to their disciplines, or help them compete with other schools.The documents listed here are works in progress and explore needs and questions from a point in time. They are typically meant to be starting places for larger conversations, not a finished product that can be set on a shelf somewhere. This repository may reflect work or experience that is several years old, but still reflect a thought process or context that can aid forward-looking work. If you have any questions, or would like to discuss a document (and context of the time) in more detail, please contact its-ea@listserv.unl.edu.

  • 2014, April: rough look at the processes involved in employee offboarding. This was an early part of a multi-year effort that changed both the practice and culture of deprovisioning services for employees on the Lincoln campus. That effort involved technical, business process, user training, and alignment between distributed HR and IT teams.
  • 2014, May: document that explores dimensions of data (expanding upon the necessary classification of data risk). This process was part of an investigation in how to change a culture of treating all data the same—avoiding unnecessary expense and redundancy in (backing all data up 4x in different locations, for example). When we can store, protect, and back up data according to its needs and level of risk, we make better investments & meet user expectations.
  • 2015, August: exploring functional alignments in ITS offerings. This document explored the organizational investment in "run," "grow," and "transform" as the University started to investigate a centralization of IT resources across campuses.
  • 2017, February: the ITS-03 policy (in public comment stage on the ITS policy page) is the result of a need to define IT Risk and who owns it—as a foundation for many other policy and practices. After consultation with BTAA and other peers, we opted to use Indiana's IT-28 policy as a foundation as it was a mature, established policy that had significant work around it. We modified the policy to meet specific Nebraska requirements. While the Indiana policy is more focused on the risk presented by under-protected physical computers, the Nebraska policy also addresses the risk presented by cloud-based services.
  • 2018, January: In light of budgetary pressures and changing IT funding models, it is valuable to examine transparent criteria and clear expectations for what makes a service a common good. This has been an ongoing look, finally revised to the attached (very) rough draft in September of 2019.
  • 2018, October: In partnership with the University data office, this draft policy establishes guidelines for the use of student data—focusing on acceptable outcomes rather than trying to maintain a list of acceptable data or practices in a very dynamic environment.
  • 2019, February: as the University relies more on service providers instead of in-house solutions, we are more reliant upon contracts. This document establishes reasonable guidelines for which software renewals warrant a full review, versus those that can be streamlined.
  • 2019, March: simple spreadsheet that starts to list some of the possible states & considerations for affiliate and volunteer users. As resources that are important to university operations, but neither faculty, staff, or student, it can be difficult to find a home for these users—let alone clear business rules to govern them.  The nature of their relationship also varies... some may never set foot on campus, but need access to sensitive data or systems while others, like a delivery driver or a contracted lab technician, might need access to sensitive areas like residence halls or controlled equipment, without needing access to a computer. Many are somewhere in between.