SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : 2000 Date-Change Problem: Scam, Hype, Hoax, Fraud

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Bill Wexler who wrote (163)10/5/1997 9:03:00 PM
From: Done, gone.   of 1361
 
TESTIMONY OF GEORGE MU¥OZ
ASSISTANT SECRETARY OF THE TREASURY
FOR MANAGEMENT/CHIEF FINANCIAL OFFICER
HOUSE SUBCOMMITTEE ON GOVERNMENT
MANAGEMENT, INFORMATION
AND TECHNOLOGY


APRIL 16, 1996

From link provided:
exchange2000.com

Introduction

Representative Horn, distinguished members of the Committee,
ladies and gentlemen. On behalf of the Department of the Treasury
and Secretary Rubin, I want to thank you for the opportunity to speak
with you about the Year 2000 Date Transition, more commonly known
now as the Y2K problem.

I want to commend Representative Horn and this Committee for
taking the leadership to bring this important issue before Congress.
As you have heard from the other witnesses in this hearing, it is
essential that the Federal government begin defining the government
solution for the century date change and, by drawing attention to it
at this level, much needed resources can be focused on that process.

I would also like to applaud OMB for having taken the initiative to
sponsor the Interagency Committee work that has recently begun.
GSA and NIST are also to be commended for their part in developing
recommended guidelines and standards.

Credit is also due to those agencies like Social Security and
Department of Defense which have demonstrated foresight in
initiating projects within their own departments. I also want to
recognize the Financial Systems Committee of the Chief Financial
Officers Council (CFO) for their leadership in this effort. In
addition, I would like to thank the Treasury Office of Security and
the Office of Information Systems as well as our bureau information
technology officers for having identified this issue and coordinated
our response.

I plan to present here not only the position of Treasury, but, as
Executive Vice Chair of the Chief Financial Officers Council, my
comments will reflect information gathered from several state
governments, Federal agencies, and the CFO Council's Financial
Systems Committee.

My comments today will briefly address the three main components
of the Year 2000 Date Transition:

The reality and severity of the problem;

The additional risks in the Federal environment and how we in
Treasury are addressing the problem; and

Finally, lessons learned, opportunities, and recommendations
for successfully moving into the 21st Century.


Severity of the Problem

A description of the problem here may be repetitive of what my
colleagues have presented, but I would like to define the issue from
the financial perspective. Clearly, if a solution were delayed, we
would be courting disaster and may be facing chaos.
That would not happen.

When I use the term "problem," I am referring to the challenges that
I and many other managers have to assure that key systems will
process smoothly into the next century. It is a challenge which we
will meet. I am confident that systems in the Treasury Department
and other agencies will work on January 1, 2000. As others have
said, the challenge comes from the inability of some computer
systems to process dates after 1999 accurately.

It is not a problem that is limited to either the Federal government
or other public sector information systems. It is widespread
throughout the public and private sector information systems,
systems that impact our lives daily. It involves deeply embedded
manipulations that have the potential to affect almost all automated
systems, from small, single user systems, to massive transaction
systems.


In reviewing the missions of our agencies, the effect of Federal
government computer processing on the American economy becomes
abundantly clear. For example, in the Treasury Department, we have
large, extensively complex systems:

Treasury collects $1.4 trillion annually through IRS, Customs
and ATF, representing over 97% of the total Federal revenues.
Last year, 250 million returns were processed.

The Treasury Financial Management Service (FMS) oversees a
daily cash flow in excess of $10 billion and issues over 800
million payments totaling over $1 trillion each year for all
executive agencies.

The Customs Service collects over $20 billion in duties, taxes,
and fees. They assist in the administration and enforcement of
some 400 provisions of the law on behalf of more than 40
government agencies and process 456 million persons and 127
million conveyances a year.

Public Debt auctions $2 trillion marketable Treasury securities
annually. They issue and redeem 150 million savings bonds
annually and they account for the $4.9 trillion Federal debt and over $300 billion in annual interest charges.

I have described these key activities to provide you with a sense of
diverse areas of potential impact and the magnitude of work needed
to address these seemingly simple date problems. It is important to
stress that the business of the Federal government is intricately
interwoven with the commerce and welfare of the rest of this
country as well as other nations. Because of those critical
relationships, it is essential that we in the Federal government
address the Year 2000 problem aggressively.


Before I go any further, I think it is important to address a question
which naturally emerges from a cursory examination of this problem:
"Did this problem arise because of someone's negligence?" To this,
we emphatically respond: NO!!! Not many years ago, computers were
not measured in gigabytes and terabytes, but in kilobytes. As is
often quoted these days, people today have computers in their homes
that have more storage space and processing capacity than many
mainframes of thirty years ago.

In those days, saving storage space in computer files was critical to
the efficient operation of systems that used very expensive
resources. As a result, software was developed to solve complex
technical problems and serve intricate, critical business needs using
only two digits for the year. Many of those systems are still in use,
which is a testimony to their quality but also, to the complexity and
cost of migrating these systems to newer technology. These systems
are central to many of our most critical operational functions--they
are at the heart of the Year 2000 problem.

The enormous scope of this conversion effort is only clear when the
steps involved locally within an organization are multiplied across
the world-wide enterprise of information systems. Resolving Year
2000 issues will require extensive examination of applications, data
items, and systems. While the legacy systems are the most likely to
include the two-digit year, we must be sure that all dependencies
have been identified and addressed.

For some Year 2000 compliant systems, complex interfaces will need
to be built to handle data to and from systems that may or may not
be compliant yet. Typical of most organizations, within the portfolio
of Treasury production systems, not all systems will be updated at
one time, requiring complex configuration management as sections
of code are made compliant.

Bridges will have to be built between systems as changes are
introduced. Firewalls and other protections will need to be
developed as part of contingency plans to ensure the success of
critical system if interfaces fail. Comprehensive test environments
will have to be built to ensure that applications can successfully
process 21st century dates.

Finally, all of this must be accomplished while still operating these
systems for critical production activities.


Government Environment

As we prepare to address this issue, it is important to recognize the
realities of the environment in which these conversion activities
will take place in the Federal government.Many Federal systems are
larger and older, and perform unique tasks so they are less likely to
be included in the Year 2000 upgrades provided by vendors. Simply
put, our challenge is greater than that faced by the private sector.

In addition, there are some obstacles to resolution of the problem,
which hinder, rather than support, the technical and project
management efforts to move the Federal Sector forward toward full
compliance. Those obstacles include the limitations of the
acquisition cycles, dwindling pool of experienced personnel,
application systems unique to the Federal sector, and a huge
inventory of legacy software and hardware. Further, as opportunities
to cut expenditures are sought, the budget environment may limit
aggressive conversion activity in favor of continuing current
operations.

Given the size of this effort for the Federal government, sufficient
quantities of competent vendor support services are absolutely
essential. There will be fierce competition for technical contracting
services to assist public and private organizations world-wide with
this conversion effort. The longer the Federal government agencies
wait to purchase these services the higher the costs and the more
likely all competent sources will already be fully committed. In this
regard, the recently enacted Information Technology Management
Reform Act of 1996 should help immensely to provide flexibility in
acquiring the needed technology and systems.

Personnel issues are another category of Federal government
difficulty. Work on this problem is occurring at the time of
downsizing the Federal workforce. We must be careful as we
downsize to maintain the critical expertise we will need to address
this Year 2000 problem.

One of the most significant features of the government environment
is the huge inventory of legacy software. Many times that software
is characterized as being monstrously complex and run on outdated
hardware. As can be seen from the attached charts, the Federal
government has large numbers of older mainframe systems which
may be suspect. For many of these legacy systems, the vendors who
originally provided the software are either no longer in business or
not upgrading these early versions of their products. Funds may be
required to upgrade or replace that software, in order to ensure the
continuing operation of systems.

Finally, the testing environment for implementing the solution may
require duplicate resources for a limited period of time. There has
never been a time when so much code was being examined, changed
and tested at the same time. Not only will most of the software in
each agency be changing, but simultaneously, most of the code in
every other interfacing agency will also be changing. The rigorous
testing environments required to implement such a complex scenario
will require careful planning.

Budget cycles for purchasing much needed services, software, and
hardware require extensive multi-year projections and must be
submitted months and years in advance. It may be difficult to
finance a conversion effort of this magnitude within existing
program funds.


Treasury Year 2000 Initiatives

As I stated earlier, Treasury's systems will not fail at the beginning
of the next century. To ensure that, we have already begun necessary
steps to address the Year 2000 issue. Every bureau within Treasury
has made progress towards the Year 2000 solution and some have
made significant progress within their information systems in
resolving the Year 2000 problem.

The Department has been an active participant in the OMB
Interagency Year 2000 Committee since its beginning in
December 1995.

A Treasury-wide group has been established to highlight the
problems, work the issues, and share lessons learned.

Milestones have been given to bureau information technology
executives which will provide a vehicle by which the
Department can track progress.

The bureaus are at various levels of progress. Some bureaus
have completed one or more of the following key steps in the
Year 2000 conversion process:
- used four-digit year fields for many years; - completed
conversions for legacy applications; - developed
blueprints; - inventoried systems; - evaluated tools; or -
identified potential systems at risk..

The bureaus have been requested to include estimated Year
2000 costs in the FY 1998 budget submissions.

Our Chief Financial Officers are aware of the issue and are
monitoring the compliance of fiscal systems across Treasury.

Lessons Learned

Turning now to what can be done, I would like to discuss the lessons
that have been learned, the opportunities that we have for making
improvements, and how Congress can proactively address the Year
2000 problem.

No silver bullet.
There is no one solution for all situations because
of the inherent complexities. Huge legacy systems are full of
homegrown routines, adapted for specific agency requirements, many
of which have dates. There is no way a quick fix or new product can
address all of the embedded date usage. The only solution is
addressing each technical problem internally and coordinating the
project centrally.


Planning is paramount. The temptation to rush in and attack the
technical problem is great, especially with the added pressure of the
inflexible deadline. This would be a huge mistake. Planning is
essential because approaching a project of this size must be done
strategically and tactically. Thinking outside the box may give us
the chance to evaluate opportunities to improve business processes
and computer processing. Taking the additional time to plan is
imperative and will prevent costly errors later, when there will be
no time to recover.

Good project management is essential. The challenge of project
management in an effort of this size is unprecedented in the
information systems environment. This is not strictly, or even
primarily, a technical problem. Treasury's financial systems,
especially those related to revenue collection and disbursement of
funds, represent the crossroads of financial activity for the Federal
government. Consequently while addressing the Year 2000 issue,
Treasury must also ensure that the integrity of all existing
financial systems is maintained during this conversion. We cannot
off-load these processes while we make corrections to them. It is
analogous to trying to repair a Boeing 747 while in flight.
Managing
all of the components simultaneously while continuing to execute
the mission is absolutely imperative.


More effort than expected. Planning and testing, which are critical
to success in this effort, are requiring significantly more resources
than expected. Neither the government nor industry has ever attacked
a computer systems problem this massive or pervasive. The brittle
nature of the homegrown systems, the monumental coordination with
external agencies, the heterogeneous existing technical environment
all contribute to the complexity, and therefore to the effort, of this
project.

More costly than expected.
As the effort was underestimated, so
was the cost. Because of all the elements that must be brought to
bear (planning, testing, project management, unexpected hardware
and software upgrades) cost estimates continue to rise. And, as
increasing numbers vie for the same limited number of service
providers, rates may escalate as well. A year ago initial projections
indicated that anticipated costs would be less than $.50 per line of
code. Today, current industry metrics reflect that estimates have
risen to $1 - 2 per line. Even this number primarily reflects
conversion costs and may not include testing, hardware
replacements, and systems software upgrades.


Testing is the key According to industry estimates, the actual
conversion may represent only 10 -20% of the total effort. The
critical component, testing, will actually consume most of the
resources: 45 - 55% of the total effort. With so much of the code
being modified, we must verify that, in the process, we do not break
something that was not broken.
Certifying those changes will be
essential to continuing our normal processes. The remaining 25 -
35% is accounted for with required planning.

Standards facilitate process. A recommended standard for data
exchange was developed by NIST and endorsed by the OMB Interagency
Committee recently. Such standards will help to create much needed
common ground for project coordination and data exchange between
government agencies and the business community.

Good solutions - Bad solutions. There are several ways to approach
this project. Anyone who promises to quickly and cheaply fix the
problem is offering a "silver bullet" and clearly is not doing us a
favor.
The Year 2000 problem emerges from the context of the
technical and organizational environment in which it was created
and in which it resides. And it will require the functional and
technical stewardship of the individual government owners to
correct it.

Allow agencies to perform their own solutions. The key to success
is that the converters must know the systems. Each department and
agency internally has the best perspective on what should be done to
resolve the technical issues. In-house expertise is your best
expertise.

Chain is only as strong as its weakest link.
Government agencies and
the business community continually exchange data, creating
intricate interdependencies. Those interdependencies create
potential weaknesses that are not related to the internal health of
systems, but to those external groups upon which certain processes
and business functions are dependent. Firewalls can be built to
protect each agency's information assets, and that covers the
possibility of unconverted data. But if their systems fail and data is
not available, contingency plans are needed.


Opportunities -- Silver Lining

Coming Out Ahead. If we address these problems correctly, some
significant benefits can come out of the effort. We will not only
ensure survival but also improve practices. Specifically, we will end
up with a more complete, accurate and usable inventory of hardware
and software assets; a comprehensive evaluation of our capabilities;
relevant metrics and measures; streamlined project management
practices; and the technical infrastructure to improve tracking,
accounting and transitioning. This information is what was
envisioned under the Government Performance and Results Act in
terms of well-defined outcomes and performance measures,
resulting in better service.

Leveraging Government Resources. An immediate benefit of multiple
agencies working together is the opportunity to leverage tools,
expertise, and best practices. Already, OMB s Interagency Committee
has put a website in place to facilitate the exchange of best
practices and project experience (http://www.itpolicy.gsa.gov).
Software routines that have been developed for the government have
also been exchanged. The development of common approaches and
standards will benefit the government by using common resources to
build benchmarking frameworks and to encourage franchise funds for
sharing products and deliverables.

Next Steps

Expand OMB Year 2000 Interagency Committee. OMB has demonstrated
leadership in establishing the Year 2000 Interagency Committee to
provide a forum for exchanging information and making Year 2000
recommendations. This Committee should be expanded to include all
agencies and formally chartered. While each agency would be
responsible for ensuring Year 2000 compliance for its information
systems, the Committee could provide high-level direction to
agencies for resolving the Year 2000 problem. Its responsibilities
would include the development and communication of Year 2000 data
exchange, contracting, and software procurement guidelines.
Likewise, the Committee would facilitate the exchange of
strategies, best practices and resources across the government.

As a first order of priority, each agency must assess its own
systems for vulnerability to the Year 2000 problem, decide which of
the systems to convert, prioritize its application inventory, and
prepare a Year 2000 conversion project plan. As part of its
prioritization, each agency must, with a very critical eye, identify
which systems will be upgraded, what solutions will be employed,
and which systems will be replaced. This battlefield triage is
absolutely necessary to protecting the most vital systems from
failure.


Support from Congress. Congress can assist the Federal community
by understanding the enormity of this challenge. I commend you,
Representative Horn, and your Committee for having taken leadership
in promoting Year 2000 awareness. An increased awareness of these
issues will be critical when considering legislative requirements
that will result in new tasks that affect information systems. In
addition, understanding these issues will be essential as budgets are
being considered. In fact, financial resources are needed to address
all the tasks discussed in the testimony heard today.

I would like to thank this Committee for the opportunity to speak to
this issue which is so important to our financial and Federal
community.
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext