This section include the technical standards for the IT software acquisitions.
Jun 6, 2014
Hosted vs. In-House solutions
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.
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.
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.
Database Management Systems
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.
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.
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 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 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 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.
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.
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.
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.
Vendor Viability and Support
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.
- 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.
- Company size and history
- 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.
- Contractual obligations