PHASE I
Weber State University (WSU) is beginning an initiative to replace its administrative systems in the areas of student services (admissions, records, financial aid and registration), Financials, and Human Resources. The new systems will include a state-of-the-art “package” of integrated software applications, and supporting hardware. The applications will efficiently support the university’s existing and future core business processes that embrace: teaching, public service, community partnerships and research.
In February 2001, WSU distributed a Request For Proposal (RFP) for consulting services to assist in the assessment of its administrative information systems requirements, the evaluation of software options, and the development of a preliminary project plan and general functional requirements.
Broadly speaking, the projects of this magnitude include the following three main phases:
- Phase I: Initial Environmental Assessment and Planning
- Phase II: RFP Generation and Vendor Selection
- Phase III: Implementation
In March 2001, after a competitive process, WSU selected Kaludis Consulting to assist with Phase I of the project. Phase I is expected to be complete by 6/30/01.
Phase I: Initial Environmental Assessment and Planning
- Key Tasks
- Individual Interviews
- Group Interviews
- Walk through Processes
- Pose Big Questions
- Deliverables: Consensus and Vision Statement, Key Scenarios
2. Executive Summary ---July 11, 2001 ATAC Presentation
3. Goals/Expectations and Deliverables:The overall goal of Phase I is to ensure a successful institution-wide selection and later implementation of the new administrative systems, by achieving the following detailed goals:
Phase I – Initial Environmental Assessment and Planning Goals Include :
For Deliverables and Results Please Refer to:
- Employing inclusive project management and change methodologies Phase I.a
- Developing a solid framework of project vision/goals and guiding principles - Phase I.b
- Assessing the WSU campus’ readiness for change Phase I.c
- Assessing resources and required funding Phase I.d
- Determining a manageable scope for Phases II and III Phase I.e
WHY CHANGE?
SYSTEM 1032 RISKS
Since the mid-1980's, Weber State University has depended on a database system called System 1032 and its accompanying programming language (PL 1032) for the bulk of its student services data processing. A major impetus behind the Information Technology Infrastructure Project (ITIP) is the declining customer base and support for the System 1032 family of products. The following is a detailed analysis of the risks associated with continued dependence on System 1032.
Background - As of February, 2002, System 1032 was still the foundation architecture for the university's home-grown mission critical student system, STAARS. In addition to handling basic admissions, registration, financial aid and student records data processing, WSU's cashiering, accounts receivable and time and attendance systems are also written in System 1032. The risks of continued dependence on System 1032 fall into four categories:
- Resources. The applications on System 1032 were developed in-house and carry the risks of any in-house developed system, including dependence on the abilities, personalities, nuances and availability of the programmers who built them. WSU is at particular risk with STAARS because the system was developed and enhanced without any unifying methodology, standards or documentation.
Examples of the problems that result include what happens when one of the System 1032 programmers is on vacation or out of the office and one of their applications breaks. The affected users either have to:
(a) wait until the programmer gets back to their office, (b) hunt them down and see if they can come in and fix the problem, or (c) try to walk someone else through the process over the phone. Over the last couple of years cross training has become somewhat more common, but there are still several applications that only one person knows in depth enough to effectively troubleshoot.
- Data Integrity. WSU's System 1032 applications were developed and enhanced without the benefit of a data model or data standards. This has led to some duplicated and questionable data elements. In addition, until recently the programmers from both Administrative Computing and Financial Aid have retained an ongoing ability to manipulate data in production. This means that programmers have on occasion deleted and/or changed data in production to solve immediate processing problems. The systems were built without internal controls and therefore lack many of the checks and balances typically built into administrative and (particularly) financial applications.
With no standards or data models to follow, WSU programmers have had the freedom to design and develop as they see fit. This makes it very difficult for a new programmer to pick up on someone else's code since everyone has a slightly different programming style. But, as mentioned above, the larger problem is the freedom they have had with the data. In these instances, there is no supporting documentation or log files to indicate why the changes were made or at whose request.
- Vendor Support. Although Computer Corporation of America (CCA) has not yet announced discontinuance of support for System 1032, it is clearly a rapidly diminishing component of their business. The last new release for System 1032 was in 1999. In early 2001, they released a new version of the System 1032 ODBC component. WSU chose not to implement the new version because we learned we would be the only customer using this version of this particular component and felt the accompanying risk would be too high.
WSU requested very little assistance from CCA in 2000-2001. A few problems were encountered in July 2001 when a major hardware upgrade was implemented. At that time, WSU learned that System 1032 support was now limited to Monday through Friday, 8 AM to 5 PM Eastern time. CCA now has only one person supporting System 1032 and that person may also be supporting other CCA products.
Unfortunately, WSU continues to experience technical "quirks" with System 1032. For example, there is an increasing incidence of batch processing failures with a System 1032 SAD error. Each failure requires approximately on half hour programming effort to resolve. This is clearly a System 1032 problem. Although the required remedial effort is generally minimal, the problems generally occur in the middle of the night. The WSU Database Administrator is familiar with most of the System 1032 "quirks," but the situation is clearly not ideal.
There is a concern that if WSU asked for too much technical support from CCA they might decide it is no longer cost effective to provide ongoing support for the product. Accordingly, WSU reserves technical support calls for only the most serious problems. When System 1032 becomes an unsupported product, WSU will be on its own to troubleshoot and support the underlying database architecture. WSU does not currently have access to the System 1032 source code, which is likely written in C and Assembler programming languages. There are currently no programmers on the WSU support staff with significant expertise in these languages.
- Complexity of Applications. The STAARS applications have been developed and enhanced over the years to satisfy changing business requirements (e.g., quarter to semester conversion), mandatory changes (e.g., Year 2000), the personal preferences of new people in different functional roles and other factors. Many programmers have worked on each of many different programs. In the absence of documentation, data standards, programming standards and methodologies, the programs have become very complex with an excessive number of twists and turns (sometimes referred to as "spaghetti code"). A change in one area can impact information in several layers throughout the application. It now takes considerable time to bring a new programmer up to speed on both System 1032 and the applications.
Unfortunately, this is a problem that compounds over time. With no real data dictionary or model of the system, the more the system changes the worse it gets. The application code is becoming less efficient over time because few, if any, of the programmers have a definitive picture of the underlying model. For example, the Database Administrator has noted procedures duplicated by programmers because they were unaware that one already existed. This intensifies the data integrity issue because each programmer codes a procedure a little differently and may come up with different processing results for the same data. Undoubtedly, there are many duplicated procedures that are unidentified because of the lack of unifying controls or standards.