March 1999

Volume 14
Number 12

The Case For Boole-A-Base

Howard Strauss, Princeton University

Eighteen months ago, the IT department of Euphoric State University (ESU) adopted Boole-A-Base (BAB) as its only supported desktop database product. It chose BAB because BAB was a full-featured database product complete with an object-oriented macro language and a compatible interface to the other desktop applications that ESU now has installed on nearly every faculty and staff desktop. BAB was a giant step up from File Manipulator and Processor (FMP) and Queries By Exertion (QBE), the two previously supported and widely used desktop database products at ESU. ESU=s IT team had recently adopted the industrial strength database package Prophet for University-wide applications. Since both Prophet and BAB use SQL, BAB databases can easily be migrated to Prophet if that ever becomes necessary.

The ESU IT team knew that the switch to BAB would require a great deal of effort on the part of both the IT staff and ESU=s users, so there was a lot of planning and gnashing of teeth involved before making the transition. The IT team felt that the necessary training for users in BAB was beyond anything that they or ESU could do themselves. Therefore they contracted with a certified BAB training organization to train about two dozen key users in twenty critical departments. These trained people would train others as necessary. They also obtained a site license for BAB and installed it on all desktop machines even somewhat likely to use it. Concurrently, all of the help desk staff was given extensive training in both BAB and in FMP to BAB and QBE to BAB conversions.

While there were the expected delays and problems in switching databases, the adoption of BAB went smoother than anyone expected. In fact, eighteen months after the decision to switch to BAB, the number of users and applications using BAB was threatening to overwhelm the BAB IT support effort. Before the IT team could formulate an appropriate response to the growing problem, Liz Kravtiz in the Dean of the Faculty=s office and an early adopter of BAB, organized an ESU BAB users group consisting of every BAB user and support person she could find. To their first meeting she invited some key IT staff members including the head of the help desk, the manager of the data warehouse, the head of academic computing, and the manager of the advanced projects group. The first few items of their preliminary agenda (shown below) reflected their concerns about the adequacy of IT BAB support.

The BAB Users= Group Agenda: 1) What each of us is doing; sharing projects 2) Training staff in BAB 3) Hiring and using BAB consultants; obtaining programming help for BAB 4) Lack of IT support; what to do about it; what we need.

Liz Kravitz was amazed to see the huge turnout. More chairs had to be brought in to accommodate what would otherwise have been a standing-room-only crowd. As the representatives from over thirty departments introduced themselves and briefly explained the BAB projects they were working on, it became clear that BAB was being used quite differently than FMP and QBE. While those early database packages had been used for simple supplementary office systems, BAB was being used to implement critical mainstream office functions of great complexity. Even more surprising, a few departments were using BAB to implement university-wide systems. No one but the central IT office had ever done such a thing before.

The Projects
The Registrar=s office was tracking signups for limited-enrollment courses. Another of their BAB databases kept track of departmental honors, and yet another tracked student applications to professional schools. The Dean of the Faculty=s office was building a system that determined what resources (computer equipment, CD-ROMs, furniture, etc.) were allocated to faculty members. Another BAB application allocated graduate student salaries to various research projects, and yet another tracked the search process for each open faculty position.

In the College of Fine Arts, every department seemed to have a BAB database that included machine-readable copies of students= major projects. A similar database was being built in the College of Architecture to track each student=s development and to have an on-line, searchable version of student portfolios. Every department represented had at least one BAB database that tracked departmental honors, awards, and achievements. Managing graduate student research was another area where BAB databases were becoming critical. And nearly every department represented had a shadow purchasing database underway to do more detailed tracking than the central MIS systems provided.

While some systems were quite small consisting of just a single table or two, one system had 60 tables, 80 reports, and almost 400 different queries! Almost all BAB systems consisted of an amalgam of local data such as departmental honors, and data obtained from the central data warehouse system or from other central MIS systems. While the central systems had layers of security and record-level authentication, the derived BAB systems tended to be much more open. Also, in almost every case, a change in the layout of central system data would require revisions to all BAB programs that used the data elements or tables that were changed.

In the past, the data in these supplementary FMP and QBE databases had been updated once a week or so and printed reports had been distributed to those who needed them. BAB was being used quite differently. Data were entered continuously from many networked departmental computers. Printed reports were still produced, but most of the database queries were done in real time on-line.

The Training
While a few departments included staff with IT skills, most did not. FMP and QBE had been handled by clerical staff that had shown some interest and aptitude and had received some cursory training. While more extensive training had been available for BAB, for all but the simplest projects the users who had managed FMP and QBE found BAB Ceven with the extra trainingC more advanced than they could handle. Even running some of the BAB systems was technically challenging for the support staff in a typical academic department.

Departments with more technical people fared no better because they tended to take on more challenging tasks. While clerical people struggled just to decide on reasonable database table structures, in departments with IT people, whole systems that included many macros, scripts, multiple databases, and automated tasks were being proposed and implemented. In all of this, there was concern about security, authentication, authorization, data integrity, backup, backout, and the rest of the issues any professional database designer would worry about. Usually, however, these issues were mostly ignored because of their difficulty and because there was simply too much else to do. And furthermore, these systems ran just within a single department so it appeared that the data security threats were not that pressing.

Everyone knew that more training was necessary, but they also knew that most of the people who were working on BAB were not really programmers and would likely never be able to do macros, scripts, and the like. Also, when these people were doing BAB stuff, they were not doing the work they were actually hired to do, and that work had not gone away. If anything, BAB systems created much more work.

The group felt that the training problem could not be totally solved by even the best training and support. Departments without IT people needed some now, and those with them already needed more of them, and more skilled people at that. Of course they did not have the budget to hire them.

Hiring and Using BAB Consultants
Since hiring new people was out of the question for most departments, many had taken to hiring students or consultants to build their BAB systems. Graduate students were more reliable and seemed more BAB savvy, but undergrads were cheaper. Unfortunately only juniors and seniors seemed able to handle the complexity of BAB, and they soon graduated; often before a project was done. No student provided enough documentation and every new student had a long getting-up-to-speed period that slowed the project down and upped the cost. And getting students to do a real needs assessment that included actually talking to end-users seemed more than one could ask for. Many departments told tales of projects that never came close to working or that worked badly. Also, competition for students that knew BAB was becoming so intense that they were demanding higher hourly rates mid-project. Many departments suggested that the central IT group could hire, train, and manage a cadre of skilled BAB student consultants who could work on departmental projects. It would be nice if IT would pay for them as well.

Departments with more complex needs and bigger budgets had hired outside consultants. It was discovered in the meeting that several departments had hired the same consultant who was implementing similar systems for several departments. Another department had learned that their outside consultants were actually some IT people from a nearby community college and that they were using a few of Euphoric State=s IT programmers as consultants.

In every case, the use of consultants was quite expensive, though the quality of the work was fairly high. But it quickly became clear that the systems they built could only be maintained by the consultants who built them. And the consultants knew little about the central university systems already built and, worse yet, about those being planned. There would never come a time when the departments or the central IT staff would ever be able to take over these very complex systems. Thus departments were developing a long term dependent relationship with a group of consultants. Much of this dependency was caused by the departments lack of experience in managing software contracts and projects.

Lack of Information Technology Team Support
A survey was handed out by the IT team to get a better feel for what they were up against. Laughter erupted when the question AWhat is your current budget for BAB database development?@ was asked. Few departments had any BAB budget. BAB was just one more thing they somehow had to fit in.

The question, AWhat can IT do for you?@ caused quite a stir. Dave Marlin from Facilities pointed out that after projects were done they often didn=t work quite right and no amount of effort seemed adequate to fix them. AWhy can=t IT give us some people to look at a finished project and help us to get it to work?@ This remark seemed to open the floodgates.

AWhy weren=t there naming conventions for database fields?@ IT protested that there were such standards, but no student or consultant seemed to know about them. In fact there were many standards, conventions, and plans well known to all IT folks that BAB users and consultants never heard about.

AThere are features in BAB that we have never been able to get to work and that we probably don=t understand. Can=t there be an IT person available to explain these to us as we hit them?@ AWe=d like IT to add security and authentication to our systems.@ AWe=d like IT to help us plan our systems. Getting some planning done early will save us tons of work.@ AWe=d like IT to work with our consultants. We don=t really know how to manage a programming project.@ And so it went, with users asking IT to take over every aspect of the BAB work, except, of course, for centralizing and controlling the project itself.

Only one person had a success story. Sue had just recently been hired by the School of Scholarly Studies (SSS). Her first job was to convert an alumni FMP database to BAB. It was clear to her early on that converting it would take months of tedious effort. She then discovered that there was a central database that contained all but three of the fields in her database. Indeed, her database extracted most of its information from the central database. Not understanding how silly the suggestion was, she asked the central DB folks to add her three fields to their database. Of course they refused.

But Sue did not stop. She talked to the VP for computing, mentioned the problem to the VP for alumni relations, and showed her managers that the conversion would tie her up for most of a year. Finally she was able to convince someone in the MIS department and the three fields were added. Suddenly the database was no longer needed at SSS since they could use the central database. Sue thought this was a wonderful outcome and wondered why the IT managers weren=t more receptive to this kind of solution.

Sue=s story was quickly dismissed by the IT people in attendance. What had happened with her was an anomaly and really had nothing to do with supporting BAB. The next question on the survey was presented and the group proceeded to engage in a lively discussion for the remainder of the meeting.

What=s an IT Group To Do?
The BAB software deployment seemed too successful to the IT group. Now that they had unleashed this monster there seemed no affordable way to support it. Even simple BAB projects rapidly grew and as they grew they inevitably required extensive use of links, macros, and system design and integration. While in the beginning, it looked like BAB could be used by anyone who could master a word processor, it turned out that BAB actually required real programming skills; something found in few departments. No help desk support could completely solve the problem, but if the problem were solved, extensive additional help desk support would be needed. Departments needed systems analysts and programmers. Often they needed many of them and needed them full time for extensive periods. Jumping into systems that had already been built would be a disaster. IT had to intervene during the earliest planning stages to ensure the project would be successful and would fit in with other University systems.

One idea was for IT to hire and manage a group of students, consultants, and full time BAB designers. These people would be charged out to departments who needed BAB help. IT would train them, pay them, and ensure that what they did was consistent with central IT goals and systems. But the cost of hiring and managing such a group was prohibitiveCeven if departments would agree it, which it appeared they would do only if IT absorbed most or all of the costs of these people.

While IT saw the downside of BAB=s success as the danger of many departments clamoring for IT support that IT could not afford to deliver, there was a far worse downside. BAB=s success was causing data anarchy. Independent University and departmental systems were being designed haphazardly by people without any real depth in system design or programming. Although departments were proving resourceful in creating systems with what seemed like few resources, in fact the systems they were building were far too expensive. Many departments were duplicating the same work, many systems had false starts and had to be rebuilt, and departments were pouring resources into BAB that should have been going elsewhere. However, as expensive as the systems were to build, the real costs of these systems were looming later as they inevitably would tangle the University in a data jungle that would require extraordinary effort to cut through. No future central innovation in managing data would be possible with this myriad of independent systems in place.

Analysis
IT cannot afford to provide the BAB users with the support they need because IT has tried to turn their users into advanced database designers and experienced object-oriented programmers, and that is not possible at any cost. Many clerical folks will never become programmers even if they had they had the desire, and many academics, although expert in their own fields, will never code even a simple macro. IT has required their BAB users to understand the inner workings of complex IT systems when all they really wanted to do was to manage their offices. The result has been anxiety that will soon evolve into chaos.

People who want to commute between their offices and homes are not required to learn to be auto mechanics, yet that is like what IT is asking of its users. Worse yet, they are asking each of them to build their own engines and cars. Even if IT could train them to do this, users would crowd the roads that IT could not afford to build, nor could IT build them quickly enough. Instead of teaching commuters to build and maintain their own engines, we could just teach them to drive. And then we could put them in smart cars that are easy and safe to drive. But better yet, we could just teach them where the bus stops are and provide superb public transportation. Not everyone can or will use buses, but adding buses and bus lanes to our highways is something we can afford to do and something that directly addresses our users= needs to just get to work.

IT already has the equivalent of a public transportation system. It is the central databases and warehouses and their associated systems that are a valuable institutional resource. It has been a long historic struggle to change data from a personal or departmental resource to an institutional one. The advent of personal computers should have made sharing this resource easier and thus more effective. It should not have, as was done at ESU, been the reason to turn this resource back to departments and individuals.

IT needs to regain control of this resource. The needs of the BAB users should be examined to see what changes to central systems would obviate the need for user departments to build their own. The best way to support BAB development is to make it so that departments no longer need to do it. Will there be departmental revolts if this is done? No, departments never wanted to be in the software development business anyway. IfC and this is quite a big ifCthe central systems can meet the data needs of departments, the users will cast away their database templates and consultants with gusto.

Realistically, not every department=s needs will prove appropriate for inclusion in the central systems, but the number of these exceptions must be kept low. For most exceptions, the IT team needs to build BAB tools for both users and programmers. To be effective, both users and the IT team need to be armed with the best software tools. The user-level tools would be used by users for simple systems that do not fit within the central IT systems. The programmer-level tools are for more complex systems, and they will be wielded by the IT team, not by users.

In all cases, the IT team will not be able to anticipate or code every possible user report and data manipulation. Here again what is needed is good software tools that will leverage the distributed nature of today=s computing. The IT team needs to turn control, display, analysis, and management of institutional data over to the departments and people that are authorized to have it. It must not give to users the design and programming of systems that manage, secure, authorize access to, and maintain the integrity of institutional data.

How can IT afford to support the BAB users? Only by getting them to stick to their knitting and by having IT assume its traditional responsibilities. The BAB users group actually grew out of the IT team=s abdication of its responsibilities. By understanding the real problem and providing the real support its users need, the IT team will add real value to ESU and avoid the hopeless task of trying to support its users in doing something they should not be doing anyway.

Howard Strauss is Manager of Advanced Applications at Princeton University and is a frequent contributor to this publication.

Top of article

The Edutech Report is a monthly publication of Magna Publications

The EDUTECH REPORT is published each month by Magna Publications www.magnapubs.com, 2718 Dryden Drive, Madison, WI 53704; 800-433-0499. President:William Haight whaight@magnapubs.com; Publisher: David Burns dburns@magnapubs.com; Managing internal editor: Rob Kelly robkelly@magnapubs.com. Content provided by contributing editors Linda Fleit lfleit@edutech-int.com and Thomas Warger twarger@edutech-int.com. Subscription Customer Service custserv@magnapubs.com. Copyright 2004. All rights reserved. Authorization to photocopy items for specific clients is granted by Magna Publications for users registered with the Copyright Clearance Center (CCC) Transactional Reporting Service, provided that 50 cents per page is paid directly to CCC, 222 Rosewood Drive, Danvers, MA 09123. Phone: 978-750-8400; www.copyright.com. For those organizations that have been granted a photocopy license by CCC, a separate system of payment has been arranged. One-year subscriptions: $199. Discounts available for multiple subscriptions.