Interest in WDSc Indicates Small but Steady Change in App Dev

One of the reasons applications, such as those developed in RPG and COBOL, are branded as legacy is because most are constructed with non graphical server-side tools that are clunky and slow compared to modern, client-side tools with graphical interfaces and major productivity and functionality advantages. Alternatives to the trustworthy SEU/PDU tools exist. IBM and a long list of its business partners offer these alternatives. And I think it is fair to say momentum is building when it comes to developing modern applications, but it would be an exaggeration to call it anything approaching a groundswell.

Ask anyone in the tools business and they’ll tell you the interest in application modernization is growing. They would be crazy to say otherwise, but interest is still a long way from implementation. The truth of the matter is that this is a heavy load to lift for most companies. Despite the “ease of implementation” message that is widely marketed, the reality is that if modernization was so damn easy everyone would be doing it.

As I said, there are many paths that will go down this road–many vendors with solutions that yield excellent results. Any of the vendors can give you a list of satisfied customers. That alone tells you that application modernization is alive and well. Many of the choices can be sorted and a better fit determined, depending on an organization’s skill set, budget, and goals (short and long term). Probably the most important thing going into an application modernization project is to realize this is not a sprint. It’s more like a marathon. Expecting too much too quickly is likely to lead to disappointment. Understanding what is achievable in a realistic timeframe will yield much more satisfying results. I think that’s what is better understood today compared to a year or two ago and that’s why there is less reluctance to take on application modernization.

Within the past three weeks, I’ve talked with two of IBM’s technical gurus for the WebSphere Development Studio Client (WDSc). This is IBM’s first choice for the tool kit it would like its AS/400, iSeries, and System i customers to use. WDSc is designed to many things, but is most often used to convert existing 5250 interfaces to Web interfaces with minimal changes to the server application by using the IBM WebFacing Tool. From IBM’s software offerings, this is the quickest and easiest way to put a graphical user interface and a Web front end on existing applications. A lot of people are still learning what can be accomplished without great complexity and buckets of money. This is one of the options, but it adds little in the way of functionality or features that does not exist in the 5250 application.

For those willing to take the next step, WDSc does other important things as well, such as creating new Web applications that access iSeries data and applications; building new e-business applications with Java, RPG, COBOL, XML, Web services and Web tools; and porting e-business applications from other platforms. These options will take considerably more time and money.

You may like IBM’s recommendation or you may want to consider alternatives from the independent software vendors (ISVs). That’s up to you. I’m going to use WDSc only as an indicator on what the market wants to do and what it seems to be ready to do.

Don Yantzi is one of the WDSc gurus I talked with. He works on WDSc development at the Toronto Labs and is often called on to present training sessions on the topic, whether it be at customer sites, conferences like COMMON or the IBM Tech Conference, or road shows like the four-city tour he was recently on, which was co-sponsored by IBM and SoftLanding Systems, the change management software vendor.

According to Yantzi, who has been at this for several years, the interest in application modernization is on the uptake and the greatest interest from his IBM-centric point of view surrounds the Remote System Explorer (RSE) component of WDSc. RSE provides the framework, user interface, editing capability, and performable actions on iSeries files, commands, and jobs.

“In terms of actual adoption,” Yantzi says, “we have between 20 and 30 percent of our [System i] customers using the RSE full time for development. Another 15 to 20 percent that use it part time in conjunction with SEU/PDM.”

Based on survey data collected by SoftLanding from those who planned to attend the seminars in Toronto, Boston, Chicago, and Dallas, 58 percent of the attendees were using WDSc for RPG development and 42 percent were using it for Web development. During the Fall COMMON Conference, two WDSc sessions were in the top 10 most heavily attended classes. Yantzi says the majority of people he deals with are interested in programming in RPG with more modern tools than SEU/PDM.

When I talked with Claus Weiss, another of the WDSc tech guys from the Toronto Labs, he described the reasoning behind visual application development tools. “This is about evolving from a 5250 tool and application environment to an environment we think you need to be competitive in the future. No one else is working with green-screen tools for app development.” The primary reason to move from the green-screen environment is productivity.

“When you make the change from SEU/PDM to WDSc,” Weiss points out, “programmers will not be as productive at first. Give it time. If you don’t, you will end up going back to the old way. Based on feedback I have from those who use the tools, it takes approximately two months to become proficient with workstation tools. Then productivity will increase.”

Another reason for moving from the green-screen application development environment is that young developers that are added to the staff understand visual tools. They have no understanding of SEU/PDM.

“Most of us recognize that the iSeries platform has applications running on it that were written a very long time ago,” says SoftLanding’s president, Steve Gapp. “We need tooling that enables us to modernize those applications.”

Gapp’s perspective is closely tied to IBM’s WebSphere Development Studio (WDS) and it could be said that whatever is good for WDS is good for SoftLanding. Its change management software offers advantages to the more complex application development environment that goes with controlling multiple development themes and multiple developers.

“There is more activity in the market in terms to people moving forward with modernization strategy,” Gapp says. “For a long time a lot of people were treading water, not sure which direction to take. Now WDSc has become more prominent. It gives people a way to move forward with a strategy for meeting business goals with the modernization of the applications. I sense there is more confidence that this is the technology to use to perform modernization. WDSc is maturing. It provides additional tooling for getting to the Web quickly.”

Cognizant of the many alternatives to IBM software when it comes to application modernization, SoftLanding also has business partnership agreements with other popular application tool companies such as BCD and LANSA. However, to plow the most acres you hitch up to the biggest horse in the barn.

For companies that do a fair amount of application development, there seems to be a growing awareness that increased productivity means ditching green-screen application development. It’s being understood that the productivity increase does not come with the flip of a switch; there are learning curves to be dealt with, but the advantages will come. I know you’ve heard the “get onboard” cries before. That message has come repeatedly from IBM and all of its tool vendors. But I believe more people are, in fact, getting onboard before the train leaves the station.

I don’t get the feeling that IBM pushes WebFacing over WDSc. They push the tooling overall and then the choices are the customers’ to make based on short-term and long-term requirements. It goes back to the skill sets in individual shops. Some will adopt WebFacing because it’s appropriate to the skills. Others may bring Java developers onboard to re-enable the applications from a Web perspective or e-business perspective. It’s a combined set of tooling and the objective is to give choices.

The fact that WebFacing is being used in a lot of instances has more to do with customer choices than the fact that IBM is pushing to make WebFacing the choice.

How does WebFacing move development forward? Get it to the next step? It’s not a progression like from A to B to C. It takes you from A to B, but to get to C you have to go back to A again.