In-store search station/WMU

The Story

In 2000-2001, I was working at a large manufacturing company that had a hideously outdated but hugely expensive mainframe business system which they couldn't afford to upgrade, despite much agreement that this was needed. The software -- which was the expensive part -- was called ManMan, was written in FORTRAN running on (I think) a PDP-11 or maybe a VAX, and required further programming in FORTRAN if you wanted to make it generate any new reports or anything.

Nonetheless, it became clear that PCs running Windows were the tool of choice for actually getting stuff done with the data.

The FORTRAN people had created several "data extracts" which were run at the home office in Syracuse, NY and dumped fresh data nightly to our network down in Athens, GA.

So without a lot of difficulty, modern computers could have read-only access to data that was no more than 24 hours old at any given time.

This wasn't enough, however; we needed to be able to access more data, and we needed to not be dependent on the two or three FORTRAN programmers up in Syracuse (who had fish to fry other than our penny-ante operation of a hundred or so people). They couldn't just dump a dataset on request -- I'm not sure why, but this was apparently Difficult. For one thing, the database was not what we could call "relational", so it may be that the only way most the data could be meaningfully viewed was via the many "reports" available through the text interface.

What we worked out was basically a data-driven screen-scraper which connected via a TCP/IP socket (working title was "Socket to the ManMan"), plus a special "report" on the FORTRAN side which would "display" any other report requested in a format which could be easily screen-scraped, and accept data to be entered in as well. (I'm probably not explaining the mainframe side correctly; again, we mostly had to take them at their word that this was What Was Possible.)

So now we could read or write any data we wanted just by putting it in a queue on the MSSQL2000 server. Another computer sitting in the back room would patiently read requests from this queue and slog through the mainframe screens (which sometimes would lock up or time out) until the request was filled, then log the results back into the output queue; other applications would update their (MS Access or MSSQL) database tables from that queue.

After that, any further manipulation was a piece of relative cake.

The web wasn't as ubiquitous then (by the time I left they were only just starting to think that maybe they should set up a web server for in-house stuff) so we were focused on desktop apps in Access or VB -- like the infamous "Where's My Unit?", which was written over a period of several months so front desk people could answer the eponymous question when customers called on the phone.

So it was plenty worthwhile to write a fairly complex desktop application just so we could answer phone questions from maybe a few dozen customers in any given month.

The Point

Getting the data between the mainframe and more modern systems was the big headache, but we were able to do it with an IT department consisting of 2 full-time programmers (who had multiple other projects to work on) and a couple of interns (same).

And even though there was no customer "demand" for a front-end application to track unit assembly progress, it was cost-effective to write one in order to reduce staff hours spent digging the information up via the mainframe text interface. Ed and I wrote the design docs (actually, I think he did most of the design work), and I did most of the coding over a period of maybe 3 months. (I don't think the interns were even involved.)

It seems pretty clear to me that Target (and Kroger, and Lowe's, and Home Depot, and Whole Foods, and Weaver Street Market, and any large store that uses modern PCs at the checkout) has already done the heavy-lifting of getting the data into a modern system. I doubt they have a ManMan-equivalent albatross to deal with; while we were wrestling with that, Target was probably busy converting all their business systems to Oracle or MS SQL.

Writing a web interface just to look things up in a database is pretty trivial -- the work of an afternoon. If you want to do it properly and have design documents and everything, you might stretch that out to a couple of weeks. Add a couple of more weeks to fully integrate it with your corporate site.

The full-blown app I'm describing here would take longer, yes, but the additional features could be pushed out to the next revision; the question is why there's no "Where's My Product?" feature on the web site -- especially when it could be leveraged later on to provide those additional features.