Project: January 1996: NTSI (New Technologies & Solutions, Inc), Braintree MA
This brief project produced an internal Web site at Fidelity Investments, giving their people access via their Web browsers to the company organization information that is stored in Sybase databases.
The reasons for doing this can be summarized quite simply: While Sybase, like most commercial databases, comes with a set of sophisticated database access tools, using them requires extensive training, limiting access to a small number of people. But people find web browsers easy and intuitive to use. So if the database information can be presented in Web format, the database becomes usable by almost everyone. This approach works quite well.
The work consisted of writing and/or modifying a collection of scripts, mostly in sybperl (perl extended with Sybase access function). The scripts extract data from the Sybase databases, and build a set of several thousand html files, all connected via hyperlinks. The files show what the database knows about the company's people, departments, and teams.
A typical starting place is the "search" page. This has a conventional field to fill in with search keys, and a "search" button. If you type the key "bill", you will get back a list of names like "Bill Smith", "George Billingsley", and the Billing department. Each item in the list is a hyperlink. If you follow a personal link, you get a page that is basically like a business card, showing the person's name and department, a picture if one is available, and any teams the person may be on. Phone numbers and email addresses may be included, if the database knows them. There's a place for a link to the person's supervisor. Most of these fields are hyperlinks, of course.
If you follow a link to a department or team, you get a page showing a list of its people, plus assorted department-related information. Most of the fields are hyperlinks, of course.
An interesting aspect of some of the pages is the inclusion of Fidelity's "MBO" program information. Most managers have a list of objectives, including a brief descriptive title, and longer description, plus possibly a date. People, department and team pages for which MBO information exists have an "MBO" button. Pressing it gets the relevant MBO list. For a person, the list is the entire list of objectives. For a team page, the MBO button produces a list filtered for that team, showing only the objectives that are related to the team.
An interesting aspect of this job was that it was partly developed by a team that had been dismissed before I came on board. It was semi-functional, but there were a lot of bugs. There were also problems caused by the widespread use of absolute pathnames, so that moving to a new directory or a different machine produced lots of failures. My job was basically to debug their perl code. Most of this wasn't explained before I agreed to do the job. By the end of the month, it was pretty much all working, and the only problem was getting them to fill in all the holes in the information in their database.