Tools & Y2K: Where tools rush in

When computers were still in their infancy, your average IT manager, confronted with building programs that took forever and a day to code, would have pounced on any supplier able to provide a decent suite of application development tools. But there was little to pounce on.

Later, a convoy of development tools suddenly appeared on the scene, reflecting the new era of client/server architecture and the need to build or tweak another raft of applications, preferably in the shortest time possible.

It might not be long before busy IT managers find themselves stuck in the wilderness again. This time, however, it will be because the software houses that have hitherto provided development tools have themselves hit rough patches ? they are victims of the millennium fiasco that has resulted in customers switching funds from long-term development projects to matters more pressing.

Analyst Robin Bloor estimates that as much as 40% of corporate IT spend is currently being diverted into fixing year 2000 bugs or just maintaining existing systems.

He warns: ?If tool vendors don?t have a Y2K angle to their products, they won?t be able to compensate for this sudden loss of custom.

?But there is another thing that suppliers could do ? namely, promise customers that their products will provide a return on investment (ROI) within nine months to a year. There are a number of fast ROI software opportunities out there, unfortunately none of them related to software development yet. They?re for putting in network computers or Windows terminals and getting rid of PCs, sorting out intranets if you haven?t got them, or giving yourself some sort of workflow capability.?

Worse things could be looming, according to Bloor. ?There?s also the likelihood that the year 2000 problem will cause an economic recession,? he predicts. ?People have already cancelled projects, and if there?s a recession they won?t bring them back again at the speed they would otherwise have done. The people who are going to suffer are the big tool companies such as Dynasty and Forti. They are probably not making many new sales, and they are also likely to be hit by Java.?

He adds: ?When one of the tool companies has a bad quarter, do you say it?s a Y2K thing, or is it that it?s just not the centre of the universe any more??

If Bloor is right, the demise of the large tool companies could have ramifications for IT departments, especially those whose development programs are closely locked into a particular set of products.

Whatever the tool companies do about Y2K, the big revenue opportunities have gone. With less cash, they will be able to make less noise about the excellence of their products, Bloor contends.

?NAT Systems has some compelling component technology which allows really fast development. It would have been great if the company had got it to market a year ago, when it could have made sales on the basis of doing really big redevelopment.

?Now, they can only point at doing relatively small redevelopments. They?re not going to be able to make a big splash about the products. Because they?re not going to make big revenues, they are not going to invest big marketing bucks. They ? and others ? will just have to concentrate on selling to existing sites.?

Not everyone follows Bloor?s line. Other analysts such as Ovum, give a far less gloomy prognosis for the tool companies.

?We?re predicting continued growth overall in the tools sector,? says Gary Barnett, author of a recent Ovum report on client/server development tools. ?But certain tools will be affected, particularly those aimed at IT departments which you could expect to have fairly big Y2K issues, for instance, those with shed-loads of Cobol.?

Suppliers such as Forti, which recently turned in poor financial results, have cited Y2K as one of the contributing factors to a sales slowdown.

?They also cite the difficulty of getting the right staff to support deployed users, rather than drive sales,? Barnett points out.

He adds that large corporate customers can take a year or more to choose a suite of tools. In that time, IT managers and resources can easily be diverted to Y2K projects.

Willie Kirkpatrick, Forti UK managing director, similarly cites a shortage of IT skills needed by customers to implement projects.

But he also points out that some customers are being forced to invest in new developments in order to stay competitive. ?Fortunately, they are mainly large projects that result in reasonable revenues for us,? he maintains.

Kirkpatrick, unsurprisingly, is optimistic about the long-term prospects for tool providers. He points out that during the time when it was still possible to undertake full system redevelopments for the millennium, Forti and its rivals picked up acres of business.

But he adds: ?It?s too late for that now, and I acknowledge that there has been an impact on the market as a whole. We have a prospective customer that has been through the entire process of educating itself on Forti and identifying projects, but still hasn?t purchased. That?s the downside. Our market is being squeezed ? not just our, in fact, but everybody?s.?

Despite the prevailing opinion that it?s too late to redevelop systems for the millennium, vendors of rapid application development (RAD) tools promise that you can fix your non-compliant code and add functionality to take the business forward at the same time.

?As the millennium approaches, IT managers are in a position where it?s now too late to make all their systems Y2K compliant. So people are going to have to focus on which of their systems must be or should be converted, rather than their ?wouldn?t-it-be-nice? applications,? argues Graham Young, UK marketing manager at Magic Software.

?To take that approach, people need to use the dynamic systems development method (DSDM) approach. I see the sales of RAD tools increasing, while the sales of SAD tools (slow application development) will decrease rapidly in the run-up to the millennium and the following two years. There will be a lot of pent-up demand to meet all the business needs that haven?t been addressed because people have been too busy working on the Y2K problem,? says Young.

?The RAD/redevelop approach means people can actually change the systems to meet new business needs as well as the Y2K needs,? he adds.

According to Young, Y2K projects are not adding business value, so IT departments should also be trying to add new business functionality. ?On DSDM projects, resources and time are fixed, and you vary the functionality you can deliver. Organisations that are not well advanced in their Y2K work by now have got to apply that principle. It?s a classic DSDM project in that you?ve got a very fixed timescale, the ultimate in time- boxing. But business isn?t going to stand still for two years. It should be done with the business ? it?s not just an IT issue.?

Young suggests that IT managers and their boards take the bull by the horns now, and decide quickly which systems really have to work ? and with what level of functionality.

?When it comes to the problems of Y2K, you can safely ignore some applications. Ask yourself, does it really matter if a program prints out 00 on a report?? he questions.

Tools that provide capability for developing new systems but don?t have integration with legacy data are only good for the big bang approach ? total system replacement ? which is too risky for business-critical applications, Young says. ?The combination of RAD and access to legacy files provides a real alternative approach.

?It?s still not too late. RAD projects take six to eight months at the most, so there?s still time for a number of major projects, with teams of four or five developers. It needs a lot of analysis to find out what is essential, but if people haven?t started that, they?ve got problems.?

However, most DSDM users seem to be keeping new functionality and Y2K work separate.

Nick Gill, director of the DSDM Consortium, reveals: ?People using DSDM are those undertaking redevelopment projects. Some will have some Y2K implications, but most people I?m aware of are making changes to their systems in a traditional way to make them Y2K-compliant. About a year ago, I gave a talk at a Y2K conference. The majority of people there were intending to maintain and evolve their legacy systems rather than re-develop them. DSDM is not really appropriate for that. They were interested in DSDM ? but for new systems.?

Nevertheless, new systems work is going ahead, Gill says. ?Because business life goes on, there?s as great or an even greater demand to develop systems. People can?t stop their business while they?re doing Y2K work.?

Gill is also director of solutions integration at Wang Global. ?We get involved in a lot of compliance work for the finance industry. Banks are getting contractors and external companies in to help with Y2K, so it?s not having a huge impact on their own staff.

?Besides, if they don?t continue developing their own systems in the financial services arena, they will die. They?re still devoting most of their internal resources ? the people who know the business ? to these development projects. So they?re having to spend a lot more money. Budgets are ballooning, albeit in the short term. That will come down with the year 2000, then increase with EMU.?

Either way, Bloor is not alone in anticipating casualties among the vendors, certainly in the short term. ?It?s difficult to predict which, because each of these vendors has a slightly different revenue model. We?re going to see a lot of the old 4GL vendors that have just staggered along, who can?t sell any more. You might see some of the larger companies do very well by eating the client bases of the smaller companies ? Computer Associates, for instance,? Bloor says.

Customers could also benefit from a round of acquisitions, he adds. Contrary to expectations, for instance, support for the database and toolset Ingres improved when CA took it over.

Y2K tool vendors have no long-term reason to be smug either, Bloor says. ?That revenue will stop dead in the year 2000. They might be able to do a year or so?s trading on EMU, but the good vendors of these products will have thought of ways to extend into other people?s markets. Most of them will be based upon code transformation, repositories, control of environment ? all the things you need to do as the date changes. But they?ll have to throw a lot of money into marketing.?

Such vendors may find new business in what Bloor calls application mining. ?It?s about getting value out of your existing stuff. People have got much better at rescuing code. Using the code that you have, rather than building new, may well become a dominant trend. It?s a marriage of wrapping things in an object-oriented way and restructuring what?s there. Vendors are providing help with things like rescuing or transforming code,? says Bloor.

?What does it matter if it?s written in Java, Visual Basic, Cobol or Assembler? The main thing is that it works, is maintainable ? and doesn?t cost you a lot.?

Ware and tear: The pressure on developers

There are many pressures on application tool vendors. They include the dominance of Microsoft, the adoption of packaged applications, HTML, ActiveX and Java on the client, and the increasing role of middleware. ?Not to mention year 2000 problems that are draining resources and funds from new application development projects,? says a recent Ovum report. The use of UML (unified modelling language) is likely to reduce product differentiation, and lead to quicker acquisitions and mergers as tools suppliers struggle to reach critical mass. ?Rational, in particular, is trying to dominate, with the backing of Microsoft,? Ovum finds. ?The structured tool market is shrinking rapidly in departmental IS, and more slowly in enterprise IS. Tool vendors will have to adapt if they are to survive.? High-end tools for enterprise applications are still peripheral to the tools market because of their complexity and high price. ?Despite their shortcomings, tools such as Visual Basic, Delphi and Powerbuilder will continue to be much more successful,? Ovum predicts. ?The rise of the network-centric architecture will shift application development tools from a focus on process (design and construction) to components and middleware.? Ovum predicts that the global application development market will grow at a compound rate of 13% until 2001. In 1997, it grew 12% to $7.7 billion.

The good and the RAD: Menzies

?We?re approaching Y2K a bit like rock climbing,? says Frank Coyle, IT director of John Menzies? wholesale division. ?We want three limbs firmly on the rockface before we move the fourth.? Menzies has a number of new systems written in Magic and Oracle, plus ?an enormous pile? of Cobol, which drives the business. It considered simply fixing the Cobol, but felt this would provide no business benefit. Menzies has between 500 and 700 batch programmes and roughly the same number of interactive programs. Critical systems such as major end-of-day runs, housekeeping and invoicing are being kept in Cobol and converted, while obsolete code is being removed. Coyle says: ?We analysed all our transactions on volume of use over three months, including the Christmas period. We found 80% was covered by 50 of those programs. Some transactions were used 300,000 times, some 11 times. Some are only used once a year but are very important when they are used.? Menzies was already committed to Magic as a RAD tool. ?We had been using it to create an up-to-date look and feel for interactive Cobol systems. Magic is able to access Cobol flat files and Oracle relational structures simultaneously, so we realised we could create systems capable of accessing both new and legacy data. Instead of rewriting Cobol with the same interfaces, flat files and timescales for amendments, we are working through from the most to least used transactions, rewriting them in Magic. All will have the same look and feel. Because it?s easier for the user, it saves time and is a business benefit.? Menzies is one of only three major newspaper distributors in the UK, and there were no suitable packages on the market. Customising was not an option. ?There?s always a danger of things getting out of control, and we don?t believe this is a time to take that sort of risk,? says Coyle. For the same reason, a complete rewrite was ruled out. ?By the time you?ve finished, the business requirements will have changed. So you rewrite areas of your systems, linking them in. We?re doing that using Magic.? The company aims to finish its Y2K compliance work this year. ?The applications we haven?t finished will be the least used, and we?ll throw in a team and convert them into Cobol in order to be compliant. But we expect to find further things while testing, and will have 1999 to fix them. Any further changes to these transactions will be carried out much more quickly using RAD.?