[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Y2K
I found this very interesting reading.
The implications still stagger me and I have been seeing
it for a couple of years.
I wonder what the state of the Oregon State Tax systems are....
- - ------- Forwarded Message
Date: Tue, 09 Sep 1997 20:21:19 -0700
Subject: Y2K -- the end is nigh
From: Phil Agre <pagre@weber.ucsd.edu>
To: rre@weber.ucsd.edu
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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 <miked@NOSPAM!.utw.com>
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 <arnold.trembley@worldnet.att.net>
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