Announcements

Betty Le Compagnon (BLC): The mainframe upgrade cost numbers look good. The cost to go to a CMOS machine is $44,000 over five years. With consideration of additional factors (e.g., space), the cost of the mainframe upgrade could actually yield savings. Mike Pickett (MP) added that OIT aims to install the mainframe over Easter Break. MP also added that this price does not include replacing the disk drives.

BLC made a preliminary announcement of a distribution fair on East Campus for next fall. Once OIT finds out what the students are buying and what their software needs are, the distribution fair will coordinate installation of the software. Additionally, Cathy Underwood will coordinate on mailings to students.

John Gallagher (JG) mentioned that Fuqua will be eliminating their mainframe, and was beginning to search for potential buyers of the machine or its parts. JG suggested coordinating with OIT to see if there is value to Duke in these parts.

MP announced that OIT is aiming for a unqiue electronic id for all Duke students, faculty and staff.

Agenda

Report on Coordinating Re-engineering (David Jamieson-Drake (DJD))

DJD illustrated the value of coordination on re-engineering by pointing that Student Information _could_ create problems for other workgroups on campus by selecting a vendor for database without consultation with others. The choice of a vendor _could_ vary widely across groups. DJD said that Duke should aim for coordination in order to recover economies of scales and satisfy common strategic needs, and hoped that the committee could make a recommendation soon.

Melissa Mills (MM) noted that there had been prior discussion of standards for software (both technical and in terms of data content) to facilitate interoperability and flexibility. DJD answered that each application has unique tools to modify data, where each vendor invokes strict rules about changes to the data, and where these rules appear to be proprietary.

Rob Wolpert (RW) asked whether this means Duke should go to a single vendor. DJD answered that the report only calls for "coordination." Some systems (e.g., procurement, general ledger, accounts payable) may have more overlap than other systems, and may imply compelling reasons to stick with the same vendor. This may not be the same for other systems (e.g., student services).

MM asked if the report pertained to the mainframe migration. MP responded that the report should aid movement off the mainframe (e.g., in that selection of the appropriate client-server database could help). MP also added that there are potential equivalences between student services and human resources. MP suggested that the report attend to whether there are incompatibilities between systemes. BLC adds that the report is a piece of the larger coordination problems (in the strategic report).

Annette Foster (AF) expressed concern about making sure that Duke maintains flexibility. By example, AF points that most systems under consideration run on Oracle, which could simplify the data warehousing possibilities. BLC added that it is risky to go with only one vendor, given turnover in the computer industry, but also that Duke had not decided to stay with Sybase. MP added that Oracle will be on campus shortly to provide a demonstration and sales pitch.

Tom DiPrete (TD) asked how quickly should these recommendations be in place. BLC answered that, ideally, these recommendations should be part of the Strategic Plan. TD suggested that it would be sensible to say that no unit should make a decision on a product until the recommendation is settled. RW responded that the suggestion was too strong, but that the needs of other units and the recommendation should be considered prior to purchase.

DJD suggested that it may be most sensible to have each system prioritize a list of vendors. Caroline Nisbet (CN) asked how can this work if all of the systems are on different time lines, and where some are not yet running. DJD suggested that the committee could find out from those which are running about vendors. MM asked if those systems which are not re-engineering needed to communicate with the commmittee now. DJD answered maybe, if we know that other systems are due to change, could attend to possible opportunities, and that perhaps the really important systems should already be in consultation. MM asked about the timing of the mainframe migration (RW: 5 years), and that some systems need to be evaluating vendors now. BLC stated that the goal was to have a detailed plan for migration by July 1.

TD asked where the decision about coordination comes from? OIT? BLC said that the decision has to ultimately come from the senior officers of the university, where BLC would be making a recommendation. CN asked if the need for a recommendation was not already covered by what is already due to the senior officers. BLC responded that the steering committee meets infrequently, and won't necessarily have the information for a technical decicsion. MM asked whether it was appropriate to form a subcommittee to study the data questions. DJD answered that this is probably a strategic decision which needs to go to the sr. officers.

MP suggested that the document needs to clarify what is "desirable" from what is "necessary." MM suggested that the ability to cross platforms, and maintain interoperability was critical. DJD added that the individual choices of units could be good if were solo choices, but that collectively the choices could lead to impossibilities for interoperability, or would be too costly. Jeff Chase (JC) asked what is the space of possiblities? What damage would be done by making the wrong choice? There are only a few systems out there, and are moving to interoperability. What is the cost of having too many tools on campus? Is it redundant staff, or that the systems can't share information? MP responded that the costs are more likely to be money and time rather than an inability to share information. JC added that the vendors of higher level systems should be interested in interoperability. BLC said that there is variation here, where some systems (e.g., SCT) are making an explicit choice of one system (e.g., Oracle) to exploit the advantages of the one system w/o having to support others. Anne Beckwith (AB) asked what were the advantages to the vendors of restricting to one platform? DJD suggested the answer was money, although all claim added functionality.

RW noted that we were out of time on the first agenda item, and asked how to proceed. MM moved that ITAC ask BLC to present the report (with minor amendments) to the senior officers for their attention. There was no further discussion. Motion carried by a voice vote.

Draft Interim Data Subcommittee Report (DJD)

DJD: The idea of the report was to elict advice from ITAC members on whether the Data Subcommittee was on the right track, and to identify where incomplete portions of the plan are.

Summary of the report: The first part is definitional, suggesting that the most fruitful area of attention would be on "people." DAFT/BPA already have an implicit model of how to pull things together for "money," and thus it makes sense to turn the committee's efforts to where less work has been done.

Situation Assessment: Duke is coming to the end of an era of discrete legacy systems. Interfaces are not defined. No one knows what is identical across systems. All systems are poorly documented, and not collectively well-understood. This represents an opportunity for openness w/o full integration.

DJD described the goals as "vanilla," turning to the final section on recommendations.

1. To document the overlap on current institutional data. This would be useful for the redesign. The report recommends that OIT develop the knowledge database.

2. Work redesign efforts should think about resolving some of the interface questions, eliminating gratuitous redundant data elements.

3 and 4 represent new institutional data.

3. Develop a high level "person" data base with directory information (name, address, numbers, email). This would require the cooperation of functional areas across campus. Such a data base represents the most common form of information across campus.

4. Create a "data warehouse" to facilitate access to information that cuts across functional systems. This would make it easier to support management across functional databases.

RW asked if #4 is a virtual or physical entity? A machine housing data, or agreements about data format and interchange? DJD answered there are different ways to go here. SAS has a virtual mode, where the "data model" is the design of the data warehouse. RW asked would this be the "gold copy" of the data? DJD answered no, that it would be what best supports data interchange. MP added that a plus of the former mode would be stability of the data system when other parts crash. AB asked if the warehouse would be archival? DJD said that the warehouse should build in archival information, to facilitiate longitudinal studies.

DJD added that feedback from ITAC committee members could be sent to DJD or any of the other committee members.

DJD wanted to emphasize the philosophy behind the report, in paragraph 2 on page 1: to change to a mode of data custodians instead of data owners.

Other business

Jim Dronsfield: The year 2000 approaches. What preparations are underway as an institution? MP answered that some systems (e.g., SISS) are already facing the problem. Also that replacement of the mainframe systems would address the problem. CUFS is already able to solve problem. Added that the year 2000 problem is present all over campus, and that people needed to know where the vulnerability was.

RW closed with the agenda for the next few weeks.

  • Revisiting the interim strategic plan in 2 weeks, also a discussion of wiring.
  • Meeting on money and funding of information technology in 4 weeks.
  • Interim report of the student computing committee in 6 weeks.

Minutes taken by John Brehm