Skip to main content

Technical Standards

This section include the technical standards for the IT software acquisitions.

Jun 6, 2014

Basically, new software can be housed here 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 will provide a remote hardware/software platform that can be used by clients to run their applications. Any necessary SCU data would also be stored at the vendor's site. Access is usually via the internet. Fees are typically based on usage. The vendor's site must be reviewed by appropriate IT electronic security staff.
  • In-House solutions
    In this case SCU provides the hardware, operating system, database platform and network connectivity necessary 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. Basically, there are two 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 will need to import data from or export data to our PeopleSoft systems. For example, they'll need student demographic information or financial information to populate tables for use at SCU. They may also need to export data, for example to the PeopleSoft Financial System, to post charges or revenue. There are several ways to provide these paths:

  • File imports/exports
    The application must be able to import and/or export data from its tables in some 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 will have to 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, on-line 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 be able to directly access tables in a database. So, 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.

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 requiring 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 applications 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 (Light 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.