Y2K -- the end is nighwriting

internationalmediainternet-policyprivacylibrariestelecommunicationsrrecommerceforwarded-contentgovernment-infoauto-importedrre-postcommunity-networking
11 min read · Edit on Pyrite

Source

Automatically imported from: http://commons.somewhere.com:80/rre/1997/Y2K.--.the.end.is.nigh.html

Content

This web service brought to you by Somewhere.Com, LLC.

Y2K -- the end is nigh

``` ---

This message was forwarded through the Red Rock Eater News Service (RRE). Send any replies to the original author, listed in the From: field below. You are welcome to send the message along to others but please do not use the "redirect" command. For information on RRE, including instructions for (un)subscribing, send an empty message to rre-help@weber.ucsd.edu

---

Date: Sat, 23 Aug 1997 21:21:31 -0700 From: Michael Dodas Subject: IRS Modernization - Request for Information Newsgroups: comp.software.year-2000 Lines: 170 I just recently read IRS's "Request for Comments (RFC)", which solicits comments for modernizing the IRS's tax systems. This document is the first information I've seen that shows just how desperate the IRS is and how complex the IRS tax systems are. Their systems are literally incomprehensible.

I won't even attempt to describe this document in any type of detail. My comments are merely those taken from the document that "caught my eye" upon my first reading of this document (RFC). To truly appreciate the gravity of what the IRS wants to accomplish, you'll need to read the entire document. Keep in mind, also, that the Modernization effort is intended to proceed as a separate project from the Year 2000 correction effort.

The document, which I will refer to as the RFC, begins with a cover letter from Arthur A. Gross, Associate Commissioner/Chief Information Officer at the IRS. Mr. Gross acknowledges that "the IRS assumed primary responsibility for managing both systems development and integration with less than acceptable results". This statement sets the tone for the IRS's direction of creating a "partnership" with the private sector "stakeholders" to modernize the IRS. Mr. Gross further indicates that it is "myth" to believe that the private sector alone could modernize the IRS, since IRS possesses the necessary "knowledge of tax administration" to build a new system. For all intents and purposes, IRS wants to turn over all of the project management, re-engineering, systems engineer, design and development and integration expertise to the private sector.

I always knew the IRS was extraordinarily complex, but it is more complex than I could have ever imagined. The RFC indicated that the complete Modernization Blueprint consists of seven volumes--count them--seven volumes. It may be a simpler system, but it will inevitably end up being yet another complex monster.

The RFC continues to say that "during the 1980's and early 1990's, effort focused on delivering taxpayer services and compliance functionality together with limited on-line development of stand along "stovepiped" systems with stand along data bases utilizing the principles of distributed computer processing, an approach to computing en vogue during the late 1980's and 1990's. Overall, the IRS computing environment evolved into an extraordinarily complex array of legacy and stand alone modernized systems with respect to both connectivity and interoperability between the mainframe platforms and the plethora of distributed systems." In other words, the IRS succumbed to "fashion technology" solutions which did nothing but complicate their previous efforts to modernize.

To give you an idea of how large the IRS's information system are, consider these statistics from the RFC:

There are three computing centers, with sixty (60) mainframes in ten regional service centers. NONE OF THE MAINFRAMES ARE CENTURY DATE COMPLIANT. There are 62 million lines of code in the IRS core business systems. Duplicate distributed networks have interoperability and connectivity problems and are largely not century date compliant.

IRS mentions "risk" many times in the RFC. "While the risks inherent in Phase III may be nearly incalculable given the aged systems, the absence of critical documentation, dependency on Assembler Language Code (ALC) and the inevitable turnover of the IRS workforce supporting these systems, it is essential to plan and execute the conversion of the Master Files and its related suite of applications". IRS seems to know that it will not be able to retain its technical expertise, who will probably bail for better paying jobs.

The IRS's goal is to canvas "any reasonable strategy to move forward on modernization" while, at the same time, managing the immediate crisis (Y2K) to "stay in business". Given the complexity of IRS, its past modernization failures and the Year 2000 problem facing them, you would have to be insane to believe these goals were obtainable.

The Next Eighteen Months: Staying In Business And Preparing For Modernization:

While searching for executive and senior information technology managers, the IRS received in excess of 800 applications from the "not faint of heart". IRS has an interesting way of describing what kind of job is in store for these people. They'll be luck to keep any of them around long-term.

Rebuild Product Assurance. IRS indicates that staffing levels have sunk to less than 30 percent of the minimum industry standards, and is one of the highest priorities with IRS. The RFC indicated that today, major tax systems changes are not subjected to comprehensive testing prior to being migrated to production. Moreover, the Century Date conversion will place an extraordinary additional burden on the Product Assurance Program. I think what IRS is saying here is that they don't have the staff for a Y2K remediation effort and have obviously only partially completed the inventory phase.

The IRS indicates that "it must undertake and complete major infrastructure initiatives no later than June 1999 to minimally ensure century date compliance for each of its existing mainframes and/or their successor platforms. At the same time, the IRS must complete the inventory of its field infrastructures as well as develop and execute a century date compliance plan for the conversion replacement and/or elimination of those infrastructures." How in god's name is this possible by June 1999 when they haven't even started. Notice how they used the words "minimally ensure century date compliance". What is that going to accomplish. Either you're compliant or you're not.

Basically, the IRS admits it was "wrong-headed" to modernize the legacy systems instead of creating a brand new system. Considering the spaghetti code and systems in place, I would have to agree. On the other had, the IRS is indicating that contractual agreements may be extended for up to fifteen (15) years for the modernization effort. The new system will probably be obsolete before it ever gets off the ground.

The last thing I will point out in the document stood out to me as the most profound of all, for obvious reasons. This is the way IRS describes themself:

"The Information Systems (IS) organization of the Internal Revenue Service (IRS) is a huge enterprise--employing in excess of 7,500 personnel across the United States, budgeted in excess of $1 billion annually and responsible for the design development and ongoing support of a highly complex and vast array of technologies which, taken together, comprise the technology-based engine that powers the IRS. A $1.4 trillion Financial Services Program, IRS business enterprises are unprecedented in size and scope - a Fortune One company - with service centers, district office and regional office operations, staffed by more than 100,000 employees, largely dependent on highly automated process as well as the currency, comprehensiveness and availability of vast storehouses of computerized data.

The latter half of the last decade of the twentieth century presents IS management and staff with unprecedented challenges: fraught with risks and potential for failure; yet filled with opportunity to serve the nation's taxpayers, while contributing to the creation of the largest and most sophisticated technology-based program in business or government".

The above two paragraphs may well be the IRS's epitaph.

In my opinion, the only way the Federal Government can secure its tax revenue collection system is to completely repeal the current United States Tax Code and replace it with a VERY simple one like a flat tax. Any attempt to fix (Y2K and Modernize) is impossible. The IRS is a classic example and sets the standard for systems which are too complex to automate. This level of complexity should be limited to scientific endeavors. I truly believe that it will be easier for NASA to put a man on Mars more easily and quickly than to continue on with the current IRS and tax code currently in place.

This amazing document can be found at: http://www.ustreas.gov/treasury/bureaus/irs/prime/primerfc.htm

Then select Request For Comment No. TIRNO-97-H-0010

It is a 116 page Adobe Acrobat document. I had great difficulty printing the document because of the complex diagrams. I have a HP Laserjet/4 with 4 megs of memory. The only way I could print it was to use a Laserjet/III driver. It worked at the high resolution, but not as well as the Laserjet/4. Leave it to the government to create a document that you can't even print easily!

Happy Reading,

Mike Dodas

-- Mike Dodas

(Remove NOSPAM! for e-mail replies)

Date: Wed, 20 Aug 1997 01:24:00 -0500 From: Arnold Trembley Newsgroups: comp.software.year-2000 Subject: Re: Media sighting: AP news story Organization: AT&T WorldNet Services

Jim Rivera wrote: > > Buried on the inside page of the buisness section of my local paper > (Bellevue, WA Eastside Journal) was a small Y2K item, apparently from AP > sources. The article said that Visa/MC were about to remove sanctions > from banks that issued credit cards with expiration years past 1999. > Visa/MC was quoted as saying that their software was "almost ready".

This story has been picked up by Computerworld. You can probably read it on their web page: http://www.computerworld.com/

I received it as an e-mail summary from computerworld. The story says Visa/MC have achieved a 98% compliance rate, and anticipate a 99.9% compliance rate by the end of this year.

> > This sounds like a successful Y2K project to me, probably because they > started in time. Out of curiosity, if anyone reading this has been a > part of that effort, perhaps they could comment, either for attribution > or anonymously through a remailer, on the ratio of estimated to actual > work in this project. What was the first estimate of the effort? What > is the current reality? Any tips? > > JR

I can comment on this, because I know a couple of people who worked directly on this problem for MasterCard, and I attended an early meeting on this problem.

> This sounds like a successful Y2K project...probably because they started in time.

The reality is somewhat different. I have been working on Y2K for MasterCard since April of 1996. Y2K work has not been full-time for me. I am a programmer, not a manager or even a project leader. My Y2K work was done on evaluating Y2K vendors, code inventory, analysis, estimating, modifying assembler and COBOL date routines, and designing other application program Y2K fixes.

MasterCard was blind-sided by this problem. I suspect Visa was also. We were notified by a large member bank in October of 1996 that there was an urgent problem. Like many banks in the USA, this bank issues their credit cards on a three-year cycle. They suddenly learned that not all POS (Point-of-Sale) and ECR (Electronic Cash Register) terminals would accept credit cards with '00 expiration years. Failure rates of 20% were being seen (some banks issue cards for longer than three years). They were about to issue cards in January '97 that would fail in the real world.

It's very bad for business when the cardholder is turned down at the point of sale. They get mad at their bank, or their credit card association (Visa or MasterCard). If they have another card in their wallet, they'll use that. So the big bank was primarily worried about losing revenue to another bank. Naturally, if the problem goes on long enough, some merchants would lose sales.

MasterCard had not expected this problem to occur. We made internal changes to our network and its applications in 1995 to prevent Y2K expiration date problems. This was before there was any Y2K project. But the POS/ECR terminals are bought or leased by merchants from dozens of competing manufacturers. MasterCard and Visa don't specify how these devices should edit credit authorization messages. We only specify the format of a credit authorization message presented to our networks. From our point of view it was a problem outside our control (a supplier problem), but one we had to solve.

There was very little programming involved in the solution. The guy in the cube across from me did all the programming in addition to his normal workload. Basically, it involved counting all Y2K expiration date transactions world-wide to determine an average rate. Then we searched for POS/ECR terminals that had never had a Y2K expiration date (if the terminal declines the card, the transaction is not presented to our network). It required searching huge multi-volume tape files for a few needles in a very big haystack. It's still going on. The job runs every week, and spins tape for hours. As terminals are identified, the merchants are notified they have a compliance problem, and they are strongly encouraged to fix it.

I went to one meeting in October 1996, and the business people requested a database solution. My boss's response at the time was,"This will take a minimum of six months development time. All my staff is fully committed for the next four months, and you want a solution in two months". We had to sell them on the batch tape processing solution. It was done as production support, outside of normal development and release schedules, and it was ready in about six weeks.

In my opinion, this problem is a classic case of an unexpected Y2K problem. We knew our network did not have a problem with Y2K expiration dates. We assumed that merchant acquiring POS/ECR terminals would not bother to edit a field that we would validate.

The only "tip" I can offer is, if you can't predict what your Y2K problems are going to be, you should be ready to work fast to resolve some unexpected problems. I think these problems will likely be at the interface with other businesses.

STANDARD DISCLAIMER: Although I am employed by MasterCard International, I am NOT an official corporate spokesperson and you shouldn't assume I speak for the whole corporation. I really like working here. It's a great place to work. If I said anything that makes my bosses unhappy, I will be very sincerely apologetic.

Arnold Trembley Software Engineer I (just a job title, still a programmer) MasterCard International St. Louis, Missouri ```

This web service brought to you by Somewhere.Com, LLC.