User login

Navigation

The story of my involvement with Tymnet - an early data communications firm

This story was a bigger deal than I realized while I was living it, in 1981.

The story is that I started my career in the library field, where I worked briefly with a colleague in the Palo Alto library who was pursuing her degree in telecommunications at the time. She became a manager at Tymnet in its earliest days, and hired me to be their "Data Administrator" Not database administrator, but rather the person who was put in charge of the data of the company in general - its accuracy and meaningfulness.

This was in early days of business computing. I saw things like the first workplace where everyone had a terminal on their desks, and not a typewriter in sight, and a network control facility that looked like a scene from a scifi movie at the time (1981) - floor-to-ceiling CRT's in an amphitheater setting, like a NASA control room.

I soon found that I could not do the job of administering the meaning and quality of the data in the current state of Tymnet's enterprise technology. As a part of Tymshare, computing was basically free to employees, and every department built their own local files to manage themselves, and these little local files had all different formats and consistency. I took half of my little team (starting at about six people, growing to about a dozen over a couple of years) and let them be secret programmers. The other half concentrated on the data quality processes, while the secret programmers built a parallel structure that we populated from the little local files.

We started in the central structure of all the switching nodes and the processing hosts that were networked on behalf of customers. We concentrated on the first problem of a database that gave the network control personnel accurate access to the contacts in all the data centers, who could be called about technical problems. We then added all the connections (hard-wired in centers, AT&T long lines between centers). We began to provide the structure for parsing the billing stream that came off nodes, so that we had accurate port-level pricing of dial-up service, via different billing schemes, such as kilo-character throughput, and 800 and WATS surcharges. We used the lines info to check the monthly phone bill (the biggest expense for the company - even more than salaries). It was the difference between what we charged and what AT&T charged us that was the basis for the "value add" of valued-added network. Our database became fed in real-time by the network supervisor node to check the accuracy of our configuration, and was fed by the order processing system (and my group created a work-flow for the order processing staff). We kept track of the code versions in all the nodes, and when the company had a crisis of running out of 4-digit octal numbers for node numbers (very shortsighted design, by the way) our database helped manage the transition to a more expansive numbering scheme. Oh yes, we also started our sites records from the fixed asset accounting system of the parent company, because when we started no one knew exactly which sites were part of the network.

We did all this with no more than a half-dozen developers, at the max. At one point, the vice president of operations stopped me in the hall and announced that he was unhappy that he could no longer run his company without my database (which was kind of news, because I wasn't really supposed to be doing any programming -- just "cleaning up the data"). This wole experience taught me the unbelievable power of the skunk-works, which was confirmed a few years later when I ended up going to work as the Data Architect for Pacific Bell, and saw how much harder it was for them to do anything meaningful with 3,000 employees (plus Bellcore!) than it had been for me with my tiny skunkworks group.

A key to our success was working directly with the people who did the jobs of running the network -- network controllers, code generators, asynchronous and synchronous network engineers, order processors, the billing department, and telco bill reconcilers. We used to go out for pizza together, where I got to know a senior network engineer, who I eventually married. (Hi Carleen!)

Part of the secret of our success was incredibly productive development environment, called MAGNUM, that was available on all the Tymshare machines we used. It was wrapped around one of the first implementations of relational technology, so that programmers had a relational data structure embedded in the programming language -- no impedence mismatch or "middleware" between the application code and the database storage.