In-Depth

Factories vie for Year 2000 fixes

• By Rich Seeley
• July 19, 2001

Are they high-tech sweatshops doing Cobol piece work by hand in a process as out of date as the code they are correcting? Or are they the answer to an I/S manager's dream? It depends on who you talk to. The so-called year 2000 factories have ardent advocates -- usually and not surprisingly -- among the firms that operate year 2000 factories. However, other voices in the software industry are either cautionary or down-right deprecating on the subject of factories. Some say I/S managers should keep year 2000 projects in-house.

There are differences of opinion, even among operators of year 2000 factories. Are you safer with factories that are onshore versus offshore? Should you send your code out on tape or disk? Or should you allow far-flung programmers to work on your system via a network connection? When your software goes to the factory, what's the best fix? Windowing or date field expansion?

When exploring the issues surrounding factories, it is not all that easy to get everybody in the software industry to agree on a definition. Some industry leaders even dispute whether "factory" is the correct term.

"The term factory is used in the industry kind of loosely," said Art Chait, general manager and vice president for the services business of Zitel, an information technology company based in Fremont, Calif. "You can buy some software, train [staff], put them in the back room and you can call it your own factory. And there are other companies that will sell you factory services, which is really access to their [staff] guys sitting in a back room. There, you've got the kind of sweatshop operation where the work is either done by hand or with tools for semi-automated work."

Chait is an advocate of what he calls "the highly automated factory," and as an example of this kind he points to MatriDigm Corp., which Zitel helped start a year and a half ago. It is a 100-employee factory based in San Jose, Calif. MatriDigm uses proprietary software which Chait said automates the analysis and fixing of year 2000 problems in Cobol applications, so that code runs through the system as smoothly as a car going down an assembly line.

Jim Johnson, director of the EDS Global Renovation Centers, Austin, Texas, sees the factory issue somewhat differently, beginning with the fact the EDS is shunning the term factory. Because the company is targeting the Fortune 500, it felt a smokestack image would not be helpful in recruiting Ph.D. computer scientists for its year 2000 renovation teams. So EDS runs Renovation Centers, which offer corporations several levels of service including one that totally takes over the enterprisewide job of providing year 2000 compliance. EDS also offers a second level of service providing the code fixes but leaving the I/S department to do everything else -- from the preliminary analysis to final testing. Although he runs what others in the industry would call a factory, Johnson said he also understands the pros and cons that would lead an I/S department to keep a project in-house.

"To me what it boils down to is the strategic direction of an organization regarding the application," Johnson said. For I/S, it probably makes sense to go out and buy some tools and do the work in-house, continued Johnson, "if they view it as a competitive advantage and something they've always worked on in-house, and they never want to let it out of house. But if they bought a package and contract out by the hour for people to maintain it, then it makes sense for them to outsource."

However, the decision to stay in-house is further complicated by human resources and departmental culture issues in I/S departments, according to Dick Kearney, partner in charge of KPMG's Boston-based Year 2000 Practice.

"The first place you would want to have the fix done is in your own shop," said Kearney, who advises clients around the world on year 2000 issues. "Obviously the people working on the system doing maintenance have the inside track as to what the nature of those systems are, what the intricacies of the systems are, how they can help test."

But Kearney said the typical I/S shop frequently does not have the staff for the job and what staff it has is not used to working on code in the assembly line fashion that factories have adopted.

"The problem usually comes down to not enough resources in the timeframe allowed," Kearney said. "Even using your own I/S shop to do all the fixes, the mentality has to change from one of maintenance to one of production line, which is similar to what happens in a factory. What we say is 'picture it as if it's an assembly line at General Motors or Ford and that line has to keep moving.' That's the mentality you would have to employ if your in-house shop is going to do the work.

This is difficult culturally because maintenance usually done in an I/S shop doesn't have the visibility and deadline pressure that you would have in new development. The year 2000 cannot be handled with a maintenance mentality. You need a production, drop-dead deadline mentality. That's the challenge for I/S managers."

If the work cannot be handled by the I/S department, managers have two other options, according to Kearney. The job can be farmed out to a factory in the U.S., or the company can set up its own in-house factory, separate from the I/S shop.

"We have a client who sets up a separate facility for fixing and testing," Kearney said. "They are staffing it with people from both inside the company and outside. This factory is run as a production-line environment."

A contrarian view of the whole factory concept comes from Bob Bemer, president of Bob Bemer Software, Dallas, Texas, and the inventor of the ESCape sequence for workstations.

"I figure if the vendors had the solution, they'd be applying it on your site rather than at their site," said Bemer, who has plans to release his own automated software solution for the Year 2000 Problem in the next few months. The 77-year-old computer scientist, who first published the warning about year 2000 date problems in the February 1979 issue of InterfaceAge, said the best people to fix the code are the people who know the applications.

"The factories don't have the live user environment and load," Bemer said. "You send it to India and they send it back, and you put it in the live environment and it doesn't work. You send it back to India again. It's tough, even by the Internet, to go back and forth. The factory doesn't have the identical hardware, so they can't configure it for the testing.

They don't know the time constraints. Maybe the program only runs between 10 p.m. and 1 a.m. Without the live environment, how do they know that? You not only have to transmit your programs to the factory, you have to transmit the knowledge of the environment and who runs it, what sort of a load is on it, what machines are connected to it."

Offshore versus onshore

Zitel's Chait agrees with Bemer to the extent that he advocates an automated solution and has doubts about the capabilities of offshore factories. "The offshore factories are offshore for only one reason -- they're manual sweatshops using cheap labor," Chait said. However, Mastech Corp., Pittsburgh, Pa., which operates a factory in India, touts its ability to maintain security, communicate with I/S mangers and work live on systems in the U.S. via a direct satellite link.

"While we have systems that mirror our clients environments, what we really do is try to tie into their systems," said Larry Mulhern, Mastech's national sales manager. "We have a satellite link from the factory in Bangalore, India, to company headquarters in Pittsburgh. Our programmers are typically working on clients' systems."

To provide the vital human communications link, Mastech puts a U.S. team on-site at the client, so the I/S staff has someone from Mastech that they can talk with face-to-face to discuss project management issues.

"This is the same concept you do for an on-site project," Mulhern said. "There's a core team of people to interface with the client directly. The difference is that we take the programmers and move them offshore. And typically in an application development project, the programmers aren't talking directly to the I/S managers or department. There's always a go-between. We put our team on-site to do just that. The personal communication that is required for the successful completion of a project is critical."

Charles Hershey, director of the year 2000 conversion at New Holland, North America, Inc., in New Holland, Pa., said that based on his experience as a Mastech client, communications with the offshore factory have been excellent.

The company, which manufactures tractors and other heavy equipment for agriculture and construction, currently has one Mastech consultant on-site while the programmers in Bangalore are working remotely on a pilot year 2000 project. Mulhern said the company maintains a ratio of one person at the U.S. customer site for every six programmers working in India. Mulhern said Mastech has built "an ultra-modern" 35,000 square foot office building in the business district of downtown Bangalore, which he said is known as "the Silicon Valley of India." He describes the typical setup of rows of cubicles populated with programmers working at networked PCs. It is a place where Dilbert would feel at home.

Mastech's Bangalore facility has its own satellite uplink so that it circumvents India's antiquated telecommunications infrastructure. Direct via-satellite communications is part of a proprietary methodology Mastech developed for a geographically dispersed project team. For project issues, Mastech uses an IBM Lotus Notes-based system to track all projects. Clients, such as New Holland, have access to that Notes system so they post memos and questions for the programmers in India.

"They don't have to worry about the Bangalore time zone difference," Mulhern said of Mastech's clients. "They don't have to worry about getting the person before they go home, or calling them at midnight trying to reach them. They can post questions on Lotus Notes and be sure they'll have an answer the next day."

As for the security question, Mulhern said Mastech usually does not send code out of the country. The Indian programmers dial into the customer's computer.

"If somebody has an IBM mainframe in Lancaster, Pa., our programmers are actually working on that system," he said. "Clients like this a lot for a number of different reasons. One is, they can actually see the work being done on a day-to-day basis. They can go in and look at overnight [compilation results]. This gives them a sense of control. Secondly, it gives them a better sense of security because the code has never left their premises."

On the home front, MatriDigm, headquartered in California's Silicon Valley, does take code off site, although Chait said that for the military and other agencies the company is developing a portable version of its proprietary automated system which it can take into a secure environment. But the preferred procedure at MatriDigm is to go to the customer site, do a preliminary analysis of the Cobol applications, determine what needs to be fixed, and copy that code onto CD-ROMs that are taken back to the factory in San Jose where the applications are repaired. Identifying problem date code is not always easy, Chait said, which is why he advocates automating the process to ensure that the code is thoroughly tested to identify dates. (See Fig. 1.)

"That's critical because we're dealing with spaghetti code that's been modified sometimes playfully, sometimes less than playfully," Chait said. "Sometimes it's been disguised. You find dates in the middle of serial numbers. You find dates named after, in one case, German sports teams. There's no indication and no documentation that it's a date."

Windowing versus expansion

Once the automated system at MatriDigm has identified the dates, the code is fixed by installing windowing into the application. Chait said a typical customer might request windowing that is 20 years forward and 80 years back. In other words, two-digit dates under 20 are year 2000-plus, those over 20 are 1900 dates. This kind of window could be fixed or sliding. With a sliding window, the software continues to assign centuries to dates based on 20/80 or whatever formula as the years pass.

"Windowing is the cheapest, fastest, simplest way to fix data," Chait said. "Expansion causes you to change your storage system and control language and it has a significant impact. As a result, most companies are coming to the conclusion that they only want to do expansion where they absolutely have to and windowing everywhere else."

However, as with many other issues in the Year 2000 Problem, the value of windowing is debated by other factory operators. The EDS centers have a different take on what constitutes a good year 2000 fix.

"Expanding the date field is, without doubt, the most comprehensive way to do it," said Johnson of EDS. "It actually will fix the problem. Windowing is really an expedient solution, but it has to a large degree a limited life span and it has some risks. It may become more complex to maintain. You may have data that doesn't fall within that range. You have to spend a little more time thinking about the risks involved. We find a lot of systems already have some type of windowing in them. Not only do we have to look at putting in a window for year 2000, we have to find out why that old window is in there."

In his experience, Johnson said, companies in businesses like life insurance long ago crossed what he calls "the year 2000 boundary," as they had to set effective dates on policies 30 years out. Even in 1970, that would have meant that the input crew was typing "00" into the date field. At that time, a programmer probably installed some form of windowing so the policy was not processed as if it had expired in 1900.

"Windowing really delays dealing with the problem," Johnson said. "It's kind of continuing how we got in this mess. Everybody said we'll do it later. Windowing continues that because you put it off for 25, 30 or 50 years depending on the domain. So that will have to be addressed then."

Meanwhile, Bob Bemer says this whole year 2000 issue could have been avoided by using the Julian date format now in use in popular PC applications including IBM's Lotus 1-2-3.

The Julian formula numbers days beginning back in 4700 B.C. with day one, and takes only seven digits to represent any date in any century since, which is one digit less that is needed for a four-digit year MM/DD/YYYY format, and only one digit more than the standard MM/DD/YY format. Bemer said there are programs available to easily convert Julian into American, European and military date formats.

"If everybody had agreed to use the Julian day as the base early on," said the man who began his career in computer science in 1945, "we never would have had any of these problems."