Critical vs. Non-critical Systemsgreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
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.
-- Incredulous (email@example.com), March 02, 1999
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.
-- Maria (firstname.lastname@example.org), March 02, 1999.
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.
-- Incredulous (email@example.com), March 02, 1999.
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.
Is this trouble? Oh shucks no.
-- Don Florence (firstname.lastname@example.org), March 02, 1999.
This problem is completely ignored by the media.
If only 10% is truly mission-critical, why not eliminate the unnecessary 90% now?
Methinks this would be a bit problematic.
-- Steve Hartsman (email@example.com), March 02, 1999.
Gee Maria, you do understand the need for substantiation afterall. Too bad we don't get very much out of you with your postings. Perhaps that will change?
-- (firstname.lastname@example.org), March 02, 1999.
"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.
-- Maria (email@example.com), March 02, 1999.
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 (firstname.lastname@example.org), March 02, 1999.
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.
-- RD. ->H (email@example.com), March 02, 1999.
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?
-- Old Git (firstname.lastname@example.org), March 02, 1999.
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.
-- Martin Tickle (email@example.com), March 02, 1999.
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.
TRicky one, isn't it!
-- Nigel Arnot (firstname.lastname@example.org), March 03, 1999.
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.
-- Nathan (email@example.com), March 03, 1999.
Here's a new article on mission-critical systems:
"Some U.S. Agencies Redefine Mission Critical to make Y2K Deadline"
-- Kevin (firstname.lastname@example.org), March 03, 1999.
One further observation:
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!
Somebody please tell me that this isn't happening!
-- Martin Tickle (email@example.com), March 04, 1999.
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.
-- Maria (firstname.lastname@example.org), March 04, 1999.