Vol. 20, No. 9 • October 2000

• THE VIEW FROM THE TOP LEFT CORNER • Turnkey Systems Solutions by Michael Schuyler

About that time I talked with Jim Speight, president of Ulisys, a software company that has come and gone, about the same issues. He said they had sold a system to a small library where the librarian who was assigned to computer duty had burst into tears, sobbing that she couldn’t handle all this newfangled computer stuff. So Jim’s partner sat down and apparently wrote a large script file that automated some of the procedures. From then on Ulisys billed itself as offering a “turnkey solution.” Walk into the computer room. Turn the key. Walk out.

I don’t remember the old Geac 8000 system as being exactly “turnkey.” In fact, I remember a lot of batch files, liberator cards, and programs to compile in languages such as “Zopl” (acronym for “our programming language” with a Z in front of it to make it sound cool). There were also numerous tapes to back up, transfers to initiate between databases, and quite an arcane system of buttons to push to get the original Deep Thought to boot up.

Those old systems, then, were never turnkey. Today, in our more modern age at the dawn of the new millennium, you can pretty well forget the idea that there ever will be turnkey systems. Compared to today, our old systems were simple! Today it’s not so much a matter of them being more complex, but that there is a proliferation of them. We once had one set of programs to worry about. We used to have Circ (Circulation), Marc (Marc Record Management System), Cat (Online Catalog), and Dog (we split the catalog into two for load-bearing purposes). Other than a couple of Apple II computers in the business office, that was it.
 

Here an NT, There an NT, Everywhere an NT
Today we run classic Dynix, a great program running on a UNIX platform. Then there’s WebPAC. We need an NT server for that. And there’s RSS, the Resource Sharing System. We need another NT server for that. Then there’s Telecirc. (You guessed it: another NT server.) Payroll takes its own NT server. So does Websense, our filtering system. There’s also WebMail and IIS (Microsoft Internet Information Server) to run our Web pages, except that RPA (Remote Patron Authentication) won’t work properly with IIS, so we have to run Apache as well.

Done? We haven’t even gotten started. Novell runs all the office applications and printers. Linux runs the mail server. Solaris runs the NetConnect equivalent. Then there’s Cisco: the caching engine, the PIX Firewall, and the Ciscos themselves. If you’ve never encountered the command language Cisco uses, you have not yet lived a full life. Now even hubs have operating systems all their own.

I didn’t mean to slight the office productivity software, starting with MS Office itself, over to Access and SQL databases, then everything from Outlook (use that and go get Symantec’s anti-virus) to some cool Quiz program someone grabbed off the Internet for $100 and expects you to now have memorized. Then we bought a signage package, which absolutely must run on a different database called FileMaker, from a fellow who is just so angry that we can’t easily accommodate his Macintosh computer. Instead we’ve got more operating system variations than we used to have computers, which themselves have outnumbered the staff by 2 to 1.
 

The Solutions Are Elusive
Each one of these operations takes expertise specifically tailored to the issues at hand. Learning how to tweak the robotic voices in Telecirc is far different than learning the intricacies of table relationships in Access. UNIX, if you were really going to learn it instead of just get by, isn’t just an operating system; it is a way of life, and it will take you that long to really learn it. It’s pretty much the same with any of the major systems you have—Cisco, Novell, Web design tools, you name it. The majority of these systems have what trainers call a “steep learning curve.”

With a small systems staff and a very wide breadth of responsibilities, the typical library system is in for some trouble, particularly where budget strains are a way of life. However, the solution to my mind is a steady and complete dedication to training. This dedication is not just from management staff being asked to fork over dollars for more expensive classes, but also from systems staff who must be chosen based partially on their own dedication to learn more about their own systems.

By any measure, training is expensive. A typical week-long IT (information technology) course can easily cost $2,000. Multiply that by the number of systems staff members you have, and I know many libraries will plead poverty. If you must throw in travel and lodging, it gets even worse. A full set of five certification courses to become a Microsoft Certified Systems Engineer, for example, costs approximately $10,000. A complete Cisco certification costs twice that, though few achieve the guru “Internet Engineer” certification.

In our state of Washington the state library has seen the need for this sort of training and used LSTA funds to help offset the tremendous cost. Today there’s no reason why anyone who wanted to couldn’t become certified with the MCSE designation for about $2,000 total. This is just one state, of course, but there’s no reason why other states couldn’t take the same route.

There’s a big market in this. Take a look at http://globalknowledge.com for an example of this kind of training. There is some criticism of these certification programs, saying that they turn out “paper engineers.” Leveled at people who take certification courses without any real-world experience, I would have to agree, but I doubt this is a typical circumstance. It’s something to think about when you’re hiring someone who may be attempting to change careers, but the vast majority of library systems staff have a lot of experience already. The combination of training and experience is, I think, the best of all worlds.

To “get certified” you have to take a series of tests from a place called Prometric (see http://www.prometric.com). The tests are done via computer in a controlled environment and cost about $100 apiece, so certification tests for the MCSE alone cost about $700. If you fail an exam, you get to pay them an additional $100 for a re-take. Our “deal” with systems staff is, “We pay for the course; you pay for the exam.”
 

We’ve Reached the Wall
In terms of expertise, we have reached “the Wall” in several areas. Seen on a graph, a steady, slow rise of a line from left to right suddenly encounters a 90-degree barrier in the middle of the graph. In dBase or Access, for example, you really can design and maintain a pretty nifty database using a couple of files and treating them as “flat-file” databases. But sooner or later you will be unable to do more or better work without learning how to program in the database language. This means understanding relational tables and subsets and actually writing code that will execute. It’s a far different environment than simply sorting columns and adding records to a flat-file system.

Our “Wall” today is in Web design. I feel we’ve gone just about as far as we can with both the skill set we have on staff and the tool set we have available to use. We used FrontPage to get moving. The 2000 version is really not all that bad, and it doesn’t mess with your HTML code the way older versions did. It was an expedient choice because we had to make a lot of changes as fast as we could. (See for yourself at http://www.krl.org.)

The next step is to develop advanced Web pages using things like active server pages (ASP) and to integrate an SQL database into the Web design. We have to get fancy on forms and be able to handle e-commerce transactions. The only problem is that we don’t yet have the skills to embark on this little journey. It’s going to take some serious resources and commitments on the part of participating staff to either take it on themselves, or farm it out.

I suspect all of us dealing with these issues have expected that, in the future, computers would become easier to use, and that our systems lives would become easier as computer interfaces began to resemble automobile interfaces: Turn it on, point it in the right direction, and go. Instead, systems design and setup have grown ever more complex as they have segmented from one large, but consistent package into a proliferation of tailor-made solutions—all different, all requiring expert maintenance. In other words, the easy days are behind us.

It all makes me pine over my dBase programs from long ago. Give me dBase, Lotus version 1A, WordStar, and DOS. Put me in a corner and leave me alone. I think I’m gonna cry.
 
 

Michael Schuyler is the systems librarian for the Kitsap Regional Library System in Bremerton, Washington. His e-mail address is michael@krl.org.