[an error occurred while processing this directive] [an error occurred while processing this directive]
[an error occurred while processing this directive]

iSIS Modifications Strategy

Various approaches will be taken to address gaps in the software functionality in the following priority:

  1. Modify current business processes/policies to meet software functionality
  2. Develop reports
  3. Develop reports with automated update processing
  4. Utilize third party products from Oracle/PeopleSoft partners
  5. Develop bolt-on functionality without modifications of core Campus Solutions code
  6. Modify core Campus Solutions code

All software modifications require approval of the Project Management Team. Approval of software modifications will be restricted to those modifications that meet one of the following criteria:

Mandatory Regulatory Requirement – There is a Federal or State legal requirement or accreditation requirement imposed by an external agency that cannot be eliminated or changed. The requirement will be cited, subjected to careful review for alternative interpretations, and challenged if reasonable to do so.

Business Requirement - There are policy compliance and reporting requirements mandated by the Kansas Board of Regents or the University’s policies.

Productivity Enhancement - There is a substantiated, well-documented business case, i.e., cost benefit, for the modification based on real costs and savings.

Mission Critical - without this capability, the institution will lose a competitive advantage or capability considered critical to its mission.

If a software modification is approved by the Project Management Team, we will follow the technical guidelines described in the table below, in order to minimize the impact of the modification on future upgrades.

Technical Guidelines for Customizations

Domain
Guideline
Implications

Data Structures

When unable to store required data in provided data structures, we will always add new record definitions rather than augment existing records.

This prevents PS changes to those records from overwriting our own, and prevents impact on other processes that use those records.

Pages and Components

Several techniques may be used to prevent PS changes from impacting custom changes, including the following:

  • Clone and Edit: we may clone existing PS objects and modify them for our use as needed.
  • Sub-pages: when Clone and Edit may be cumbersome, we create links to new data on the existing pages. If a page is changed by PS, only the link must be restored.
  • New Pages & Components: It may be a more viable option to use our own page or groups of pages to access data.

Clone and Edit may be cumbersome. See Sub-pages approach.

 

PeopleCode Programs

PeopleCode is a scripting language that performs work for the user when certain actions are performed in the system. The PeopleSoft PS system contains over 30,000 of these programs. Some approaches using PeopleCode include the following:

  • Make the change and accept the risk.
  • Clone items and change clones: In some cases, it is possible to avoid changing PeopleCode but still alter how a page behaves with this method.

Changes to these programs can be risky for upgrades. However, PeopleTools 8.x added flexibility we can utilize to reduce upgrade risk in some cases. For certain small changes, the risk is minimal.

Online or Batch Programs

Approaches to modification of these items vary depending on what kind of item is in question. Examples of approaches are highlighted below:

  • COBOL Programs: we seek to avoid any modification to COBOL programs. We would either build a new process using another tool, or recommend a “pre” or “post” processing program to be added before or after the delivered process to achieve desired results.
  • SQR Programs: New SQR programs are often created to support custom reporting requirements. Existing SQR programs that must be changed are usually cloned.

COBOL programs are the most difficult to maintain, and over time PeopleSoft is expected to phase them out. We seek to minimize modifications to SQR programs because it can be difficult to maintain these programs when PS makes changes.

Application Engine Programs

Sections of AE programs can have effective dates. If we need different functionality for an existing program, it is easy to create a copy of the existing section, update it, and save with a new effective date. New batch processes will be written using this tool.

Modifications to programs written with this tool represent the lowest risk.

[an error occurred while processing this directive]