This chapter provides a closer look at student information systems (SIS). Since most institutions will implement course markings by customizing their SIS, understanding SIS capabilities and limitations is paramount.

Many institutions use third-party SIS. These systems have developed a wide array of preset capabilities and functions, but can be limited in terms of customizations due to the system environment at different organizations. Banner, Powercampus, Jenzabar, and Peoplesoft are popular suppliers, and they will be discussed in detail at the end of this chapter.

Some institutions have chosen to develop their SIS in-house. Although these systems typically have similar functionality to third-party systems, they require a heavy investment of time, money, and personnel to develop and maintain. However, such in-house systems are also created with specific institutions’ needs in mind. While not exportable to other institutions, such customization can be a benefit to institutions with specialized needs.

Due to the potential specificity of in-house systems, which may not be generalizable, this chapter focuses on the properties of commonly used third-party systems. However, similar principles can be applied to in-house systems.

Functions

Institutions depend on an SIS to provide a central location for information on student attendance and grades as well as tools for general administration and reporting. The central features that an SIS offers are as follows (G2 2019):

• Information management
• Reporting
• Individual education plan creation
• Admissions management
• Billing and payment
• Student information management
• Student portal so that students can track their own progress
• Parent portals for K-12 applications
• Registration and scheduling
• Gradebook and transcripts

Putting all this information into a central system maintained on campus or in a cloud-based service has a number of benefits, including facilitating communication between students and instructors, facilitating interdepartmental communication, increasing security for student records, providing a “one stop shop” for students to manage their education, and providing a single place for the institution to get reports about student progress or other information that can be used for planning or evaluation (G2 2019).

Third-party SIS providers have developed a wide array of preset functions that are often complex. For example, Banner includes a mechanism for students to search for classes and view class details, campus store links, course descriptions, syllabi, class attributes, restrictions, instructor/meeting times, enrollment/wait-lists, co-requisites, prerequisites, mutual exclusion, cross-listed courses, linked sections, and fees. Many colleges take advantage of these capabilities, using their SIS to both monitor student information and display the schedule of classes.

An SIS may also work well with other systems such as university scheduling software or systems developed in house. These systems complement the features of the SIS, providing a more comprehensive set of administrative tools or focusing specifically on generating dynamic course schedules (Acalog Catalog Management 2020). Compatibility with other institution software systems allows an SIS to grow beyond its innate data collection and management capabilities to provide a more integrated and interactive experience for campuses.

Customizing the SIS

The success of any technical customization depends heavily on clear communication about requirements and expectations. As early as possible, for any system, a planning team should be formed that includes representatives from all groups on campus that have a stake in the outcome (e.g., information technology [IT], website groups, campus store, registrar or records office, faculty representatives, student representatives). Part VII (Case Studies) offers examples that demonstrate how addressing technical issues is often less difficult than undertaking the planning work needed to make them possible. Thus, sage advice from the case studies is to start simple and build in more complex functionality later, implementing a viable product instead of getting hung up on perfecting an ideal. Often, neither local IT nor vendor IT support has much control over the complexity of changes requested and sometimes has the difficult task of telling people their requests are not possible given the timeline or resources available.

When beginning to plan a customization, stakeholders should discuss their needs and requirements with the staff or vendor who runs the SIS so that their options are known and understood. Identifying the goal of the change and then consulting with whoever maintains the SIS is the best way to implement that goal in a reasonable amount of time and with a reasonable amount of effort. Such change may be feasible using central IT developers who maintain the SIS on a day-to-day basis. Feasibility can depend not only on the ability of developers to change the underlying database, but also on their availability to make the change and maintain that change in the future. Other changes may require returning to the vendor for assistance with updates, but these will likely come with an associated cost. For example, Mt. Hood Community College, along with four other Oregon schools, were able to work with Jenzabar to obtain a software enhancement that would allow for course marking, splitting the cost along FTE. Determining a cost-benefit analysis as to whether to make customizations internally or through an outside vendor should be a part of the environmental scan.

When considering local customization, it is also important to remember that starting from scratch may not be necessary. Many SIS providers have a large consumer base of higher education institutions, and with these come  a range of preexisting customization options and communities of users to help with changes. For example, even though Banner is a proprietary software, it is such a heavily used system that Ellucian makes Banner’s source code available to their customers (Ellucian 2020). Accessing this code directly can aid greatly in any customization plan. Further, because their customer base is so varied, some common customizations can actually be built into Banner. Good communication with the vendor about needs and future desires is key. Many organizations have a designated person within their IT department to communicate with vendors about technical problems and requests, so identifying that person—and communicating course marking needs clearly—should help the process.

Despite these provisions, there are still some cases where an organization cannot dedicate the resources—whether time, money, or effort—needed to make a change. In these cases, institutions should consider low-tech solutions, like stand-alone lists of low-cost classes that can be presented to the students outside of the schedule of classes. Still, this strategy can present several challenges, including making sure students are aware of the existence of the list and will see it before registration. Even if an SIS is customized, a separate list of classes with open educational resources (OER) or other designations can serve as a useful reference document, whether exported from the SIS or collected independently. Lower Columbia College continues to use such a list alongside their course markings to help advisers guide students to OER classes and promote OER on campus.

Limitations on Customization

The systems themselves are fairly versatile, yet users requesting customizations will likely experience resistance to change. In this section, the possible limitations will be listed out for the system environment at different organizations.

Overall Operating Budget

Organizations with a proprietary SIS can have vastly different experiences on limitations. Organizations with more money will have more resources to put toward customizations, and will usually have more influence over the vendors involved. Two organizations can have the same system but, based on their overall level of funds or influence, have very different experiences, especially when it comes to new customizations.

Service-Level Agreements

As an organization searches for an SIS, it engages in negotiations with the vendors. This negotiation includes what systems the SIS has to integrate with, how much training and customization will happen, and a whole host of other agreements outlining who will do what. These details are decided and in writing before the system is implemented. These service-level agreements are not public facing documents. If an organization has lots of local resources, they may negotiate for more access to the source code or background database of the system. Or an organization can negotiate for more ongoing support and customizations. The service-level agreement may stipulate how many hours of work the vendor can give to further customizations, or it may set a price for changes beyond what is stipulated. The important thing to remember is that unless an organization is in the middle of transition from one system to another, they will already have signed this agreement and be working within its limitations. The local IT staff, or vendor contact that people will work with to get course markings done, will have little control over what has already been agreed to and will be constrained in ways that may not be obvious.

The Complexity of the Customization

Regardless of the system or the agreement, simpler customizations will have a greater chance at success than more complex requests. An institution’s SIS is a large software package written in code, which should be infinitely customizable. In theory, no change is outside the realm of possibility if it’s logically consistent. However, not all customizations are equal. Some customizations requests could be easy updates by people at an organization adding a value to a list, others could be simple database updates, while others would require full software rewrites to implement. Companies and local IT may reject customizations based on an assessment of the return on investment of the time and the level of complexity for the customization.

With any locally created customizations of vendor supported systems, there are a few issues to consider (Davis 2018). If upgrades happen with any regularity, then customizations may have to be redone. It is also possible for upgrades to render a customization as implemented difficult to re-implement, and a new solution has to be reworked. Creating custom code can also lock down aspects of a system, which may make future changes difficult. The more aspects of the system a change touches, the higher the chance that this will be a problem. Finally, local customizations can shift the burden of maintenance off of a vendor and onto local IT staff, which could be a lasting problem. If the campus IT staff balk at a change, then it’s probably because their cost-benefit analysis indicates that the requested customization and subsequent maintenance would be inappropriate to include in their current workflow and resource limitations. Listen to their professional input, and ask if there is a different way to reach the goal that would be more reasonable.

Local IT Resources

In general, the more high-level local IT an organization has, the more they will customize in house, even with priority software. Institutions without high-level local IT will rely more on the company for customizations. The quality of local customizations is highly dependent on the skill of the people involved, and there might be a learning curve for working with a new system. An organization customizing using local resources should allocate plenty of time for local IT to orient themselves to the codebase. They are working under extreme scrutiny and may be very cautious. Vendors will often provide a test system so that changes can be trialed, but this is not always the case.

Customizing the  SIS for Open and Affordable Resource Use Marking

Many institutions, including those explored in this book’s case studies, have customized their SIS to indicate open and affordable resource use in their schedule of classes. The most common path appears to be designating these courses as an “attribute” in the SIS, an implementation followed by CUNY, Houston Community College, Kansas State University, Kwantlen Polytechnic University, and several SUNY institutions. As CUNY says in their case study, attributes are already a common way to indicate specific features of a course—for example, “Writing Intensive”—and as such are already within the scope of an institution’s usage of the SIS. Some coding may be required to implement these new attributes, as Tompkins Cortland Community College describes, and further customizations may be needed to allow for a specific display of the information, such as with Kansas’s icon. However, as Kwantlen Polytechnic University found out, the process is not necessarily that difficult. In fact, the ease with which they were able to implement the ZTC, or zero textbook cost, attribute inspired them to create additional new course attributes.

Institutions not using attributes have identified other places in the schedule where it is easy to add a new piece of information. Lower Columbia College was able to identify an unused tag in the system and reappropriate it. Portland Community College already had a customization in their system which had added a finance code. Since this section was already visited every semester by those entering course information, it made sense to add the new designation for open and affordable resource use there (fig. 9.1; Klaudinyi et al. 2018).

Of course, there is also the possibility that making a change might not be so easy. In the case of Mt. Hood Community College, the only option for customization was a software enhancement, which incurred a fee from their vendor, Jenzabar.

Indicating open and affordable resource use in the SIS is often further complicated when it must be reported in multiple ways. For example, SUNY has implemented a system-wide back-end reporting option in the SUNY Institutional and Research Information System. This tracks OER courses for data collection, such as success and retention rates. However, SUNY schools implementing a front-end marking to be visible to students for registration must do it using an entirely different process in a different platform. CUNY, on the other hand, requires its instructors to use the same system, but report textbook information in one area while another is marked to indicate that the course is ZTC. Similarly, Houston Community College reports open and affordable resource use within one system but requires tagging the course in both the Course Attribute fields (fig. 9.2) and the Course Material Type field (fig. 9.3) on the Textbook tab. The former allows students to search for classes with the attribute and tracks these courses for data purposes while the latter allows the “Textbook Savings” note to display alongside a description of the class. Such complications demonstrate the importance of identifying the goal of course markings and how they are to appear before starting the implementation.

Products

This section provides an overview of common SISs and their customizability. Support tools offered by the vendor to enable course marking are described. Approaches to the student-facing appearance and navigability of course markings are explored, and how these various approaches might affect staff workload is addressed.

Banner by Ellucian

Banner is used by 1,400 organizations worldwide (Ellucian Banner 2020). For all versions of Banner, Ellucian has a variety of tools, techniques, documents, and source code to customize the software for individual institutions. The software is easily customized for themes, and advanced administrators can add audit fields and deploy extensions. Organizations can also manage their extensions through Git (Ellucian 2020), and the company provides some tutorials on how to accomplish this. Hiding a field, changing the order of tabs, and changing the text of a label, are among the options available in the self-service client, or portal. The self-service client enables a non-IT person to make customizations in a system. While Banner is the only SIS on this list to make a point of mentioning their self-service client, many systems have similar options. Banner has been successfully used to implement course markings for OER. For example, Kwantlen Polytechnic University successfully implemented OER course markings utilizing Banner and found that adding a course attribute was an easy change. The attribute has made it easier to identify the impact of the course marking because reports can be generated using the OER attribute.

PowerCampus by Ellucian

PowerCampus is used by 200 colleges and universities and is designed for smaller institutions, as compared with Banner (Ellucian PowerCampus 2020). Nicolet College implemented their course marking in PowerCampus. In their implementation, the course markings show up as a course note below the section it was attached to on the course schedule. Their technical implementation was swift, taking only two weeks; however, students are not able to search and limit results by OER.

Jenzabar

Jenzabar was founded in 1998 as an online community for professors, students, and administrators. In 2000, it started producing enterprise software solutions for higher education (Jenzabar 2020). The company has two solutions, Jenzabar One (used by 1,300 institutions) and Jenzabar SONIS. Jenzabar SONIS is designed for smaller institutions. Jenzabar CX is the cloud-based version of the software. Mt. Hood Community College implemented OER course markings in Jenzabar CX. They had problems with trying to limit the text field to accept text and not code.

Peoplesoft

Peoplesoft Campus Solutions is a side product of Oracle’s PeopleSoft human resources software and therefore has a history of flexibility and integration. Oracle claims to be competitive with other SIS providers in their ability to integrate Campus Solutions with other software and to tailor it for each institution. Customization in an existing SIS, however, will have already been done, and support for local changes will depend on individual institutions’ agreements and resources.

The University of Texas at Arlington has implemented free and low-cost course markings in Peoplesoft as Course Attributes available in the “Additional Search Criteria” of the schedule of classes (fig. 9.4; Reed 2018).

OpenSIS

OpenSIS was designed as an open source alternative to proprietary SISs and in some ways has comparable features. Even though the software is open source, most organizations pay to use the hosted option, which provides technical support and troubleshooting. OpenSIS also offers openSIS-Surge, which is a cloud-based version. Because it is open source, customizations are possible but entirely dependent on local resources. The software is written in PHP and MySQL, which are common languages for developers. None of the case studies in this book use OpenSIS or any open source software, so there may be less of a community available to help those that decide to implement open source solutions.

In-house developed Systems

With all in-house developed systems, the options for customization are dependent on the organization and the resources available. Since a vendor is not involved, contracts are not a problem and upgrade concerns are not as much of a formal consideration. However, in-house developed systems are dependent on local IT resources, so if the system does not have good documentation or the people who designed it have left the institution, changes may take longer and be more of a resource burden.

Similarly, local institutions will require local maintenance and awareness of the back-end, which can make any future changes difficult, such as those required for adding a new course marking designation.