Technical Standards

New software can be housed at SCU in our IT data center or hosted at a data center provided by the vendor. Cost, security, availability, and other factors must be considered before deciding on the best alternative.

• Hosted solutions: Many vendors provide a remote hardware/software platform for clients to run their applications. Necessary SCU data is stored at the vendor's site, with access usually via the internet and fees typically based on usage. The vendor's site must be reviewed by appropriate IT electronic security staff.
• In-House solutions: SCU provides the hardware, operating system, database platform, and network connectivity required to run the application. These costs and setup activities must be factored into any software acquisition plan.

The technology involved in developing software applications is constantly evolving. There are two main prototypes for applications marketed these days. Technology like “cloud computing” could introduce new options in the future.

• Web-based architecture
  Most applications are now developed with an internet, or “web”, user interface. This allows access from PCs using browsers such as Internet Explorer or Firefox. The advantages are that no code will be stored on the PC and access can be from anywhere.
• Client/Server architecture
  In this architecture, code is typically installed on PCs that will access the application database directly. Code can often be run from a server using Remote Desktop, alternatively. This architecture is becoming less popular and poses maintenance and security problems.
• Mobile applications
  IT does not currently support applications on mobile devices such as the iPhone and iPod Touch (“smart” devices) except for the interface to Groupwise. Using such devices to access applications at SCU, such as the PeopleSoft systems, is anticipated at some future time.

All software applications must be developed to run under one or more operating systems. Of the operating systems that are designed to support multiple users, the two most common are Unix or Windows server-based systems.

• Unix/Linux

  IT supports several versions of Unix and Linux and is the preferred operating system for hosting administrative applications. It is more secure and performs better than Windows.

• Windows

  Many applications (all .Net and SQLServer based applications) run on a Windows operating system. IT supports Windows servers also.

SCU's primary hardware supplier for servers is Dell. IT will assist in configuring the server size and options and in ordering the hardware. As part of the total cost of ownership (TCO) departments must plan on periodic replacement or upgrades of hardware platforms in their budgets. SCU does not have a server replacement program as it does for PC replacement.

The database management system (DBMS) is a critical component of any software application. The DBMS supports access by multiple people with acceptable performance, provides security, data integrity, and data recovery functions.

• DB2
  IBM's DB2 database management system is used to support all the PeopleSoft applications and can be used for other applications as well. Many vendors, however, do not provide support for DB2.
• SQLServer
  Microsoft's SQLServer database management system is the alternate choice for IT. Most vendors support SQLServer. Licenses must be purchased to use this product based on the number of persons accessing the application.
• MySQL
  MySQL is an open source product that is now widely used for both local (free download) and enterprise-wide applications (available from Sun Microsystems). SCU uses MySQL in several applications and can support this product.
• Oracle
  Oracle DBMS is a very popular product and is an option for many applications. It is used sparingly at SCU.

IT will help with the decision about which DBMS is best suited for any given software package.

Most software applications need to import data from or export data to our PeopleSoft systems. For example, they'll need student demographic or financial information to populate tables for use at SCU. They may also need to export data to the PeopleSoft Financial System to post charges or revenue. Several methods are available to provide these paths:

• File imports/exports
  The application must be able to import and/or export data from its tables in a prescribed format. If no PeopleSoft interface is provided by the vendor, IT will need to write a corresponding import/export program for the PeopleSoft side of the exchange. This activity must be anticipated and prioritized with IT as part of the project plan.
• SOA capability
  Service Oriented Architecture or “Web Services” technology provides a real-time, online interface between the application and PeopleSoft. This is often referred to as “messaging.” When up-to-the-minute integration is needed, SOA is the best choice. Some vendors provide a messaging interface as part of their package.
• ODBC access
  Open Database Connectivity (ODBC) provides drivers for applications to directly access tables in a database. An application would be given direct access to PeopleSoft's DB2 database tables to facilitate the import/export process. This poses security risks and must be reviewed and customized by IT before implementation.

Novell
Most applications are designed to run over a network to allow shared access from multiple locations. For web-based applications this is transparent. For client/server applications, Novell-compatible protocols must be supported.

Due to the threat of identity theft, security has become a much more important aspect of software applications than ever before. Universities are particularly subject to hacking due to our “openness”.

• Encryption
  Encryption is a technique used to make data unreadable and requires a key or a password to access it. Applications can encrypt particularly sensitive or “covered” data like SSNs or account numbers to provide extra protection. If such data is stored in an application's database, it must be encrypted.
• Interfaces
  As described in “Integration Capabilities” above, there are several ways to interface with other systems. File transfers, if they contain sensitive data, must be encrypted and transferred over a secure, encrypted connection. SOA and ODBC connections will be evaluated for security standards also.
• Authentication
  Software applications must have a way to authenticate only valid users. Typically this is via a sign-on ID and password. Passwords must be encrypted when stored in the database. LDAP (Lightweight Directory Access Protocol) support is desirable as it allows authentication to be routed through Novell directories.
• Authorization
  Once authenticated, access to specific data within the application should be restricted by an authorization scheme of some kind. Usually this is done by creating roles and assigning the user ID to a specific role.
• Remote Access
  Depending on the nature of the data and the application architecture, access to applications from off-campus may require special software such as VPN (Virtual Private Network) and/or RDP (Remote Desktop Protocol). This software helps to secure the connection to and transfer of information between the client and the server.

All hosted or in-house applications will be evaluated by appropriate IT electronic security staff for compliance with “best practices”. Identified vulnerabilities must be addressed before contracts are signed.

Software vendors can vary in size from one or two staff to large corporations. Since the adoption of a software solution can become an integral part of a department's business process, it is important to make sure that the product and the vendor will be around for some time. While there are no guarantees, there are steps that can be taken to assess the viability of a vendor and their support policies and performance. References should always be requested and contacted to evaluate past performance.

• Viability
  • Company size and history
    To insure continued support and enhancements software vendors should have a history of successful product acceptance. Reference calls to existing customers along with vendor provided information regarding their staffing and history are advisable.
  • User base
    The number of customers is one indication of success. A large user base also contributes to company viability.
  • Financial stability
    Most companies will provide you with a current financial statement.
• Support
  • Contractual obligations
    What services will they provide at what time? Pay particular attention to implementation services and time frames. Some vendors have restrictions on how long the implementation can take and on the time to perform an acceptance test. Often, if defaults are found in the software after the acceptance test period is over, little recourse is available. Building penalties for non-delivery of software and services into the contract can sometimes be negotiated.
  • Updates and “bug” fixes
    Vendors should provide periodic updates (enhancements) to their products. What is the frequency of updates or enhancements to the software? Is there an associated cost? Are they included in the maintenance fees?
    Vendors must provide a process for fixing problems or “bugs” in their software. What kind of support is provided for problem resolution? Is it included with the maintenance fees? What are the turnaround times for problems (based on severity?).
    A support agreement must be provided either within or in addition to the contract. The agreement must describe how the vendor meets the above requirements. If these services are not provided an “application support” contract must be purchased.
  • Service Level Agreements
    For hosted solutions a Service Level Agreement (SLA) is recommended. SLAs specify minimum requirements for performance (application “response times”), data recovery times in the event of a disaster and downtime limits (E.G., for maintenance or system problems). To be effective, SLAs must contain penalties for non compliance.