Monday, July 09, 2007
Batch cycles -- still the heart of business data center culture?
Batch Cycles Used to Make Up the Heart of Computing
I started my “career” in 1970 getting out of the Army, but the first time I worked as a programmer on financial systems in a commercial shop was when I went to NBC in New York City in August 1974 (right after Nixon’s resignation). For all jobs that I had (except one, nineteen months with a health care lobbying consulting firm from 1988-1990), the overnight batch cycle seemed to comprise the department computing culture. (OK, from 1979-1981 I did only design on a proposed Medicare system, but even there I worked on back end reporting and the preoccupating was how batch processing would flow.)
Batch is not hip-hop, and in the “Broken Arrow” world of John Travolta it ain’t “cool” but it was fundamental. The cycle had to finish on time and totals had to balance in time for CICS (or in one company, Datacom DC) files to come up on time for the business day. Programmers had to be on-call for those dreaded S0C7’s (programming problems) or 001’s (usually empty files) or U100’s (usually out of balance). In one job, in the 1980s, systems were self-contained enough that everyone was responsible for his own system. In the 1990s at another company it was necessary to have rotating on-call lists, because of the interdependence of the systems. Of course, there were the dreaded “month ends”. I remember the phrase “End of month is on fire!”
One major result of supporting batch cycles for so many years is knowledge of the meaning of the business processes taking place. In the 1980s, I worked on billing systems for a credit reporting company (Chilton, to be absorbed by TRW in 1989 and spun off as Experian, much of it still in the Dallas area today). The cycle comprised a couple of major parts: processing the day log files (of credit report requests) to collect statistics, and updating the daily billable volume, often applying complicated volume and other discounts and fixed charges. (Another area of the company was feeding credit scoring, well known today as FICO). In the 1990s, I was working in the life insurance and annuity business, and the cycle was a bit more complicated. The cycle comprised (1) new business processing (ISSU-COMM and NBU), including policy print (2) the daily claims administration cycle (with different lines of business at different subsidiary companies on different platforms, including Vantage, VLn, CFO, and various older in-house systems (3) feeds to accounting and salary deduction for subscribing employers, as well as feeds to the agent commission systems. End of month included all the accounting and commission payments and statements.
In supporting a life and annuity processing cycle effectively, one develops an understanding of the core concepts of life processing. The employer required and encouraged all programmers to take LOMA (Life Office Management Association) courses and earn FLMI certificates, by taking up to ten multiple choice tests. Insurance has its own set of concepts (like anti-selection), that become second nature to people who work in the business. One of the most notorious of the LOMA tests was the actuarial math test (“present values”, etc). A background in statistics and calculus does help.
Property and casualty insurance, and health insurance would tend to have similar underlying processes. Property and casualty would emphasize estimates and imaging of accidents or claims events. Health insurance has to meet strict legal privacy requirements in transmitting data among different systems and companies (HIPAA), often with XML.
When one reaches “retirement age” as I did, various issues come up (complicated by the economic dislocations at the end of 2001). One is whether I could return as a mainframe applications programmer after five years, and I could if the re-emerging demand is great enough. Another is whether the user and business knowledge would be useful in selling insurance products, an issue that I will take up in a couple of other blog entries soon. I’ve already taken up “Can techies sell?” on this blog (Oct 2, 2006 – click on the archives link).
Picture: I used to work in the building in Arlington VA that this new building replaces. Progress moves on.