This document is an HTML formatted version of a printed document. The printed document may contain agency comments, charts, photographs, appendices, footnotes and page numbers which may not be reproduced in this electronic version. If you require a printed version of this document contact the United States Securities and Exchange Commission, Office of Inspector General, Mail Stop 11-7, 450 Fifth Street N.W., Washington, D.C. 20549 or call (202) 942-4460.
Audit Report No. 257 September 9, 1997
OIT has made progress in its efforts to implement client server (C/S) applications. Under client server, processing is distributed between the client (the personal computer), and one or more servers (the mainframe or network file servers).
Among other accomplishments, OIT has established client and server development branches, improved hardware and operating system software capabilities, acquired commercial off-the-shelf software, adopted communications and interface standards, and implemented several C/S applications, with more planned. A contractor is currently considering ways to improve OIT’s efficiency and effectiveness, including additional outsourcing.
We are making several recommendations to improve OIT’s planning and management of C/S initiatives. Some relate specifically to C/S, while others are more general. Our recommendations include scheduling periodic meetings of the Executive Advisory Committee; implementing full life cycle costing; deciding which projects are major; improving project planning; implementing data dictionaries; defining data ownership policy; and considering needs of all user offices.
OIT and the Office of the Executive Director provided written comments (attached) and verbal comments, respectively, on the draft report. Generally, they concurred with the report’s findings and recommendations, which have been modified as appropriate to reflect the comments.
Objectives and Scope
Our objective was to evaluate OIT’s planning and management of client server initiatives. Rather than focusing on specific client server applications, we reviewed the underlying processes for implementing C/S. During the audit, we interviewed Commission and contractor staff, reviewed available documentation, and performed limited tests of controls.
The audit was conducted in accordance with generally accepted government auditing standards from November 1996 to June 1997.
OIT decided to move to a client server environment to improve service to users, reflect changes in technology, and capitalize on infrastructure improvements already made. Under client server, processing is distributed between the client (that is, the personal computer), and one or more servers (mainframe or file servers).
In deploying client server applications, OIT seeks to provide Commission specific applications (by modifying off-the-shelf software, or developing custom software), empower the end-user (by allowing the user to access data and generate reports), and re-engineer the Commission’s data infrastructure (by simplifying access and reducing redundancy).
The Office of Applications Development within OIT is primarily responsible for software development and maintenance, and includes Client and Server Branches. Other OIT offices provide the necessary hardware, software, and telecommunications to run C/S software.
OIT has recently implemented several C/S applications, including On-Track (for the Office of Administrative and Personnel Management); Administrative Proceedings System and Release Log System (for the Office of the Secretary); and Esperant-CATS (for the Division of Enforcement). We developed a table (see Appendix) to depict the status of OIT’s C/S initiatives.
The Office of Information Technology has several accomplishments to its credit in its efforts to implement client server. It has established separate client and server branches in the Office of Applications Development, has implemented several C/S systems, and more are under development or planned. Meanwhile, it has improved the communications and network infrastructure used by C/S applications, begun establishing a database administration function, and adopted communications (TCP/IP) and interface design (Microsoft Windows) standards.
OIT has hired a consultant (Coopers & Lybrand) to conduct an assessment of its organization and staff skills. It is considering various options, including outsourcing, to improve its efficiency and effectiveness.
We are making several recommendations to improve OIT’s planning and management of client server. Some are general, while the others relate specifically to C/S. The general findings (Recommendations A-H) are described first below.
Executive Advisory Committee
To improve senior management oversight of information resource initiatives (including client server), an Executive Advisory Committee (EAC) was established in 1996. Its members consist of the Chief Information Officer (CIO), the Executive Director, and the Chief of Staff from the Chairman’s Office.
The first meeting of the EAC was scheduled for December 1996, but was postponed because the then Chief of Staff left the Commission. Since then, the Committee has not yet met, nor has it approved a charter for its activities. Although the CIO and Executive Director meet regularly, oversight from the Chairman’s Office is desirable.
The Office of the Executive Director (OED) should schedule periodic meetings (for example, quarterly) of the EAC.
The OED should prepare a charter of the EAC for approval by the EAC.
Life Cycle Costing
OIT estimates life cycle costs for its system development initiatives on project initiation forms. Life cycle costing is used to help ensure the selection and implementation of cost effective systems.
OIT’s procedures for recording and tracking life cycle costs can be enhanced in several ways. It has not formally defined criteria for deciding which of its system initiatives will be considered major. Major systems should receive special management attention, including detailed life cycle costing.
Also, OIT only estimates costs to implement a system, not maintenance and support costs over its useful life. OMB Circular A-109 includes maintenance and support costs in its definition of life cycle costs. Excluding these costs gives an incomplete picture of total system costs.
Finally, OIT needs to start tracking actual costs (in addition to estimated costs) for its major systems. Actual costs help measure performance against objectives (as required by the Government Performance and Results Act of 1993) and assist in making decisions about systems.
The Office of Information Technology, with the concurrence of the Executive Advisory Committee, should issue written guidance for identifying major system initiatives. The guidance should indicate what additional controls (for example, full life cycle costing) will be imposed on these systems, and which current and planned systems (for example, EDGAR) are considered major.
OIT should include maintenance and support costs in its life cycle cost estimates.
OIT should track actual costs for major systems.
The development of client server systems typically involves all four sub-offices within OIT. The Office of Applications Development develops the C/S software; the Office of Central Services provides the servers (hardware and associated operating systems and databases) used to support the C/S system; the Office of Communications and Systems Support provides the personal computers, network connectivity, and customer help desk support for the C/S system users; and the Office of Project Management and Analysis provides the budgetary and contractual resources needed to develop and implement the C/S system.
To some extent, these offices plan and track projects within their own offices, but no one office has responsibility for overall planning. As a consequence, OIT does not have assurance that all needed steps are properly coordinated, and carried out in the right order. For example, security plans are not being defined before systems are being released for production (see recommendation K).
OIT should ensure that critical tasks and milestones for systems development projects are identified, tracked, and coordinated by a planning office reporting to the Chief Information Officer.
The position descriptions (PDs) of the OIT Office Directors do not reflect their current responsibilities and the November 1995 reorganization. PDs are a management control to help ensure that staff are aware of their responsibilities.
OIT should update the PDs of its Office Directors, and review the PDs of other staff to ensure they are current.
OIT staff frequently conduct meetings with staff from other Commission offices, both to define user requirements for C/S systems and for other purposes. Based on our observations and discussions with staff, the effectiveness of these meetings varies. Sometimes, time is spent on tangential issues or the material is not presented well.
OIT should provide facilitation training to appropriate staff.
OIT needs to establish better procedures to ensure that all potential users are identified and their needs fully considered in initial design efforts. For example, at the onset of the development of the Secretary’s administrative proceedings tracking system (APTS), the Offices of the General Counsel (OGC) and the Administrative Law Judges (OALJ) were involved in the initial prototype reviews. However, APTS was not recognized at that time as the solution to tracking systems requirements of these offices. It was later determined that APTS would be the best solution for both OGC and OALJ.
In addition, OIT needs to ensure that data integrity controls are not compromised in the development phase. In the APTS example, a look-up table (that assists in standardizing data entry spelling of various named participants/entities) was programmed into the initial system, but its use was not made mandatory because the Secretary did not require it. Look-up tables and other edit checks promote data integrity.
OIT should establish procedures to ensure that all potential users are identified and their needs fully considered in initial design efforts. In addition, OIT should determine what controls (for example, edit checks) are required as part of the initial design effort. These requirements and controls should be addressed in any systems development methodology adopted and used by OIT.
System Development Methodologies
OIT has not yet adopted a methodology or suite of methodologies (examples of methodologies include prototyping, JAD RAD, paper modeling, and the spiral or waterfall) to guide its system development efforts. As a consequence, it risks omitting key steps in the system development process.
A methodology serves as a management control which helps promote consistent results and provides a way to measure the effectiveness of the process. An undefined methodology can lead to excessive costs, delays, and systems that do not meet user requirements, are difficult to maintain, or lack adequate security and data integrity.
OIT should adopt a methodology or suite of methodologies for system development, and develop mechanisms to ensure the methodologies are followed. The Appendix contains an excerpt from the Department of Treasury’s Information System Life Cycle Manual.
Security and Contingency Requirements
OIT does not have a defined process to analyze security and contingency requirements as part of client server system design. As a consequence, these requirements were not sufficiently addressed for several systems.
For example, On-Track and APS were put in production without having a security plan in place, while security requirements (such as firewalls and encryption) were not initially identified for PC DOCs, currently in development. The audit log features of SQL Server, an important security feature, were not activated timely. OIT does not have a contingency plan to support applications in production if the Operations Center Sun Microsystems servers experienced an outage.
OIT should implement a process to analyze security and contingency requirements during client server system design. It should assign responsibility to specific staff for developing security and contingency requirements and plans.
OIT has not yet implemented a data dictionary for its database management systems (ADABAS and Sybase SQL Server). A data dictionary contains detailed information on data items, including their attributes and definition. As more client server applications are developed, proper data definition will become critical to prevent data redundancy and data integrity problems.
OIT should implement a data dictionary for Sybase SQL Server (OIT plans to migrate ADABAS applications to Sybase).
As more client server applications are implemented, the amount of data will increase, as will the importance of the data base management system (DBMS). In a DBMS, the data are maintained independently of the application programs. Several applications may use the same data item.
Control matrices identify which data bases and data elements are associated with each application, to help ensure data integrity and security. They also show which applications can change data, and how the data are changed (that is, created, updated, or deleted). The Appendix includes examples of control matrices.
OIT should develop control matrices for the data bases it uses.
Data Wwnership Policy
OIT has not yet established a data ownership policy. As a consequence, the ownership of data for which OIT has custody is not clearly defined.
Ownership would normally be assigned to the office which primarily uses the data. The owners have oversight responsibility for the data, and determine who has access, as well as the level of access.
OIT, in consultation with the Executive Advisory Committee, should establish a data ownership policy, and assign data to owners in accordance with the policy. OIT should inform owners of their rights and responsibilities under the policy, and OIT’s role as the data custodian.
OIT has not standardized the names for client server systems. For example, the system in the Secretary’s Office is variously referred to as OS, APS, and APTS, while the Blue Sheet Tracking system is also known as the Large Trader system. The absence of naming conventions causes confusion.
OIT has also not standardized the naming conventions for storing data files electronically. Standard file names give information about the type of data or application associated with the file.
OIT should adopt uniform naming conventions for identifying systems.
OIT should adopt file name conventions where possible.