Top five problems in IT business: Rational VP

We talked to Hayden Lindsay, IBM Rational's vice president of enterprise tools and compilers about enterprise modernisation. He identified five key factors that are inhibiting business responsiveness.

Lindsay is an IBM distinguished engineer, having held positions at the software giant for over 20 years. He's worked variously as product manager for VisualAge Generator, co-leader of the Eclipse platform development team and director of WebSphere studio and Rational modelling tools departments. He is also a developer and researcher, contributing 14 patents to IBM's portfolio. He told Builder AU that when it comes to managing responsiveness in IT, there are five key factors you need to examine.

1. Asset Management

The problem is in knowing everything that a business owns, in terms of software resources. Code sitting on a mainframe is not like products sitting in a warehouse. According to Lindsay, many businesses claim to have trouble keeping track of all of their software once it's deployed.

"Most businesses suffer from a lack of inventory of existing code. You've got millions of lines of COBOL code and you don't know anything about it. The same problem is occurring now with Java code, everyone's got legacy Java code that they don't know what to do with," Lindsay said.

2. Architecture

If you don't design your software with the goal of being maintainable and reusable then it cannot be any surprise when it becomes difficult to maintain and reuse it, he said. The solution is in designing your systems and interfaces with an eye to the future. "You don't have the flexibility of repurposing code if it's very brittle, or it's poorly architected, with ill defined or even not defined interfaces and the like," he said.

3. Skills Modernisation

Lindsay says that IBM has worked with thousands of COBOL developers to help them develop for more modern platforms, such as J2EE with Java. The dream for Rational and IBM is to remove the barriers of platform and middleware as to where developers can work.

"We want to move to a position where if you have 500 developers, instead of having 200 COBOL, 100 PL/1 and 200 Java, you end up with 500 general purpose business developers that can be applied to projects independent of deployment platform," he said. "You need to focus on better design and architecture of your systems, but at the end of the day people are the ones who are doing that, you need to focus on your staff."

The solution, according to Lindsay, is in retraining developers to higher level languages, which are agnostic to the issues of architecture. IBM Rational's answer to this is the Enterprise Generation Language, which can be compiled to run on CICS in COBOL, J2EE in Java, or as a native Linux, Windows or Solaris application. It also targets IBM platforms such as Websphere and Weblogic.

This is not a new phenomenon. IBM themselves have been working at the problem for two decades, and other languages also support multiple platform targets. Other languages also support this pattern: high level language Python can deploy on .NET with IronPython, or Java with Jython. In fact, this one language, many platforms approach is the other side of the coin to the many languages, one platform approach favoured by .NET.

The approach best for the business depends on what is easier to retrain: language syntax and semantics or the specifics of your middleware platform. IBM Rational is well and truly a proponent of the first. "There are a lot of people who have tried to retrain COBOL developers to Java. The failure rate is huge, it's in general not a winning proposition to try to do it. EGL is a higher level language and so you have less to know about. Learning the Java syntax would be rather straight forward for a COBOL developer, that's not the issue. The issue is learning about the concepts of OO, learning about the various J2EE extensions. I'm not telling you it's impossible, I'm just telling you what customers have told me: that they've tried it and in general it's not a path that most of them choose to go down again."

4. Team Infrastructure

Too long has a divide existed between mainframe and distributed infrastructure, Lindsay says. "I'm sure if you talk to many enterprise customers a lot of them have duplicate infrastructures. They have something for the mainframe or the enterprise system, and something totally different and disconnected for the distributed side. This came about because of the digital pilot projects they did in the early client/server days, it grew up and grew even more with Web investments."

The problem this causes is that it creates barriers that prevent a business from efficiently using their personnel and tools, he said. "You have this duplicate infrastructure and this limits your ability to move people around, because they're using totally different sets of tools, totally different processes. Of course it's more costly, our assertion here is that you need to move back to a consolidated team environment. You need to take advantage of all the tools that have come about in the distributed areas and apply them to mainframe development as well."

5. Budgetary Inflexibility

Lastly, it all comes down to money. Lindsay explains that "This is really simply the phenomenon that 70 to 80 percent of most companies IT budget is spent on maintenance, and you need to figure out ways to freeing up some of that money, so you have more than 20 to 25 percent to spend on the backlog. This is something to help mitigate the fact that there isn't this vast number of people you can bring into IT, at least get a better use out of the ones that you have."