Critical vs. Non-critical Systems

Most organizations, particularly those in government, make a point of the percentage of mission-critical systems they have repaired. They state or at least imply that the non-critical systems can wait until after January 1, 2000.

Most people may think that this means that it is not necessary to take any actions before January 1 concerning the non-critical systems. This is incorrect. Most non-critical systems interface with critical systems. These interfaces must be turned off or the unremediated systems will feed bad data to the critical systems. In many cases, turning off the systems requires creating dummy interfaces to prevent the critical systems from crashing. Even standalone non-critical systems should be turned off. A user viewing their data may make a wrong decision.

Answers

Do you know anything about mission critical or non mission critical
systems? How did you arrive at "In many cases, turning off the
systems requires creating dummy interfaces to prevent the critical
systems from crashing"? Please give specific examples (from business
functions) of these kinds of non critical systems.

I have been a programmer working on large corporate systems for over
20 years. I know of many non-critical systems at my company that
will not be remediated. An example is an Excel spread sheet that
users upload to the mainframe to add order scheduling data to the
central database. Our company has mandated that no unremediated user
created spreadsheets, databases, etc will be allowed on continue to
exist after September 30, 1999. Our Information Systems department
is now trying to find all those systems, determine their owners, and
figure out how to turn them off. Given that many users have created
such systems throughout the years and their creators are long gone,
this has become a considerable task.

Fewer than 10% of federal computer systems (roughly 6,700 out of
73,000) have been classified as "mission-critical." Numbers are
harder to come by for the private sector, obviously, and the pct. of
mission critical vs. noncritical systems varies by company and the
classification strategy used. A good general number that I've seen
somewhere is that about 15% of corporate systems are being classified
as critical, which is roughly in line with the federal numbers.
Because of triage, most noncritical systems simply won't be fixed in
time.

"If only 10% is truly mission-critical, why not eliminate the
unnecessary 90%" Non critical does not imply unnecessary. Non
critical systems include reporting systems (not necessary for
services but for management), automated training systems (not
necessary for the mission but a more productive means for training),
and those spreadsheets Incredulous referenced. Can't speak for the
company but maybe they only represent a small portion of order
scheduling data. In any event, it's a good thing to "turn off" non-
remediated code in September. This gives the company three months to
react to failures.

Sorry mass, you will continue to get nothing out of my posts for your
brain can not comprehend much.

I would like to clarify a few points that I made in my two earlier
statements concerning this issue. The spreadsheet with the order
data was originally created by a user several years ago for his own
purposes. At some point, we requested that the Information Systems
department set up an automatic interface to load the data. Like
other users, he had always had the ability to enter the data manually
through online screens. The screen program has been remediated.
However, the company has mandated that all user created systems will
be discontined unless their owners can make a sufficient case to
retain them. Since our standard is four-digit years on all
interfaces, the spreadsheet owner will have to convert the format of
all dates if he/she wants to even apply for the continuance of the
spreadsheet's use.

Concerning dummy interfaces, this spreadsheet creates a uploaded file
that jobs on the mainframe expect to exist. If it does not exist,
those jobs will fail. Rather that modify several jobs in the short
time that we have available, we will create an empty (dummy) data
file with the same name as the file that the spreadsheet creates.
The other thing that we must do is make sure that the users are no
longer able to upload the spreadsheet. We will do this by turning
off a menu option.

As of last count, our company has found over 250 such uploads and
downloads between the mainframe and users' PCs.

Incredulous is correct that the non-critical systems will have
problems. For instance, lets say you successfully remediate a series
of database files to use 4 digit dates. Lets further postulate a flat
file extract that is used to generate a variety of reports. The flat
file is now longer by at least 2 (and possibly more) bytes than the
'old' extract. A COBOL suite of programs uses the flat file(s) for
report generation. Guess what happens to the non-remediated COBOL
programs when they try to use the file ----- CRUNCH!!! ABEND OC7
or worse. So either the non remediated programs have to be taken out
of the job stream OR a dummy file(s) is used and useless reports are
generated (quite possibly a simpler "fix"). These "NON mission
critical" items are going to be a real pain.

In last month's Senate food supply hearings, Sen. Bennett talked about
non-critical systems. He said he talked to the person in charge of
deciding which of the Senate's systems were critical or non-. He
found out that this person didn't think copy machines were critical,
whereas Bennett thought they were, just from a purely copying point
of view. What wasn't mentioned at all is that in larger
organizations, one has to enter a user number and file number via a
keypad on the copier. This information goes to the accounting
function of the system for billing. Now, I don't know if this
transfer of information from a Y2K-ready copier would cause the main
computer to blow up or what, but it seems like this it might. Can
someone with more technical expertise answer this?

How do we determine whether a particular system is critical or
non-critical? It seems to me that unless a thorough Business Impact
Analysis is conducted for each organisation, then the terminology may
mean one thing to company A and something quite different to company B
- or even Government USA!

I work in the area of Business Continuity Planning and from what I
have seen, there isn't much happening on the business side of the Y2K
contingency planning. Perhaps the situation is different on mainland
USA? Please let me know.

The example I've given before of a large non-critical system is that
of the bonus-points systems that many retailers use.

If you can't operate your tills, you can't run your business.

But if you are forced to suspend issuing bonus points (and to
discontinue the vast data warehousing operation behind them) the
business will keep going.

For how long? This depends on the competition. If everyone has done
the same, then customers can't use this as a reason to go elsewhere.
But if the store down the road is business-as-normal, you may have a
big problem with vanishing customers.

This is why we don't just do away with non-critical systems now.
Someone else wouldn't, and they'd use the competitive advantage that
the non-critical systems give them to steal your customers.

Is management even capable of accurately determining what is and is
not mission-critical? I'd venture some huge mistakes have been in
this regard. I would also like to suggest that the time-saving
estimates in this approach to Y2k remediation have been grossly
over-stated.

The same data may take many paths through an organization (breadth).
Some data is passed from one system to the next, sometimes traversing
a dozen or more systems before being archived or deleted (depth). All
data paths must be considered in terms of breadth and depth when
determining "criticality". If these concepts have not been
considered, we will have the situation where data comes into an
organization and is unable to take an accustomed and necessary path,
or it eventually hits a wall along a particular path.

To solve the breadth problem, the crude approach is to close off all
paths that cannot be remediated in a timely fashion, rendering them
"non-critical", regardless of the protestations of those users
affected in their ability to perform their duties. Note that even
this initial filter requires reprogramming at some level to prevent
the data from entering the newly "non-critical" system.

The expectation is then that the remaining paths will be fully
remediated, or a least remediated to some usable degree. However, if
these remaining data paths consist of several discrete systems,
each of these nodes must be remediated as well. Bypasses must be
explicitly created (more work), or the unremediated node must be made
to appear transparent to the data (still more work). All of these
dependencies in the remediated path (some of which may be circular)
must be considered and correctly addressed.

In effect, the arbitrary division into critical and non-critical
systems frequently creates much additional work in order to correctly
and reliably support this division. Frequently, one just doesn't have
the luxury of "turning off the system" without undue side effects.

From the furore of Critical Systems redefinition, one cannot help
wondering whether the "systems are running the business" or if (as it
should be)the "business is running the systems"!

If agencies and departments are so radically able to redefine systems
that were previously deemed critical into a non-critical category, I
would submit that this is evidence of the former, rather than the
latter modus operandum.

What this means is that services that are truly necessary from a
business viewpoint could be compromised if the supporting systems were
not deemed to be critical by the "shifting sands" method, with the
result that services fail whilst so called critical systems pass!

Kevin I owed you an answer on "progress is being made" comment. You
have lots of links on negative news, I have seen lots of links on
positive news. (I wish I had the rolodex you have). We could agrue
the points on these various links, spin, exargeration and so on. My
progress comment comes from the fact that companies are spending
money. Nothing more. I don't want to get into how much, not enough,
slow progress, rapid progress, just progress.

Now a comment on the above link stating the number of critical
systems decreases. As a company (and the gov) goes through this
remediation process, they inventory their systems. This has never
been done before in this magnitude, the entire enterprise. As they
progress through the process they begin to find that some systems
were actually a piece of another system in their original inventory.
Some could be categorized as two separate systems and then some could
be combined. Also companies have found that some systems were not
even used, just left after an upgrade or just obsolete. This could
also cause the number of critical systems to go down. These systems
would be decommissioned. Don't look too hard here. The explanation
is that companies (and the gov) refined their initial estimates. I
view this as a good thing and progress is being made.