Lawson Unveils "Landmark" Project to Bring Apps to J2EE

by Alex Woodie

Lawson Software's iSeries customers had reason to be happy and, perhaps, not so happy at the company's annual CUE user conference in San Diego last week. First, the company revealed that, after years of lagging the Unix and Windows releases, the OS/400 version of the company's ERP software is finally at parity with its brethren. But the joy for some may have been short-lived, as Lawson unveiled its ambitious "Landmark" project to standardize development on J2EE, which means no more RPG.

For years, Lawson's OS/400 customers have griped and moaned about their ERP vendor's lack of support for their server platform of choice. It would often take the St. Paul, Minnesota, company several years to introduce the ILE RPG version of new ERP releases, which always shipped first for Unix and Windows platforms. Some users questioned Lawson's devotion to its iSeries customers, which comprise about 20 percent of the company's total installed base of more than 2,200 companies.

Three years ago, Lawson affirmed its commitment to the iSeries and pledged to narrow the gap. More recently, it's been very vocal in its support for the eServer i5 and IBM's iSeries Initiative for Innovation--particularly in the wake of Oracle's acquisition of the J.D. Edwards ERP products and the questions about the future of those products, which Lawson competes directly against. Lawson, no doubt, sees an opportunity to bring J.D. Edwards' OS/400-based users over to Lawson, but only if it seems dedicated to its own iSeries customers.

By the time you are reading this, Lawson was expected to have announced the pending availability of Lawson 8.1 on the iSeries, which will bring a new portal self-service application, business process flow and modeling, and other enhancements. Lawson 8.1 for Unix and Windows shipped some time ago, so the OS/400 version will now be current with those platforms, something that hasn't been the case for a long time. Lawson was also expected to announce a new "skip upgrade" program that will allow about 400 of Lawson's OS/400 customers on older releases (mostly version 7.2) to upgrade directly to version 8.1, and therefore bypass upgrading to version 8.03.

The coming parity between OS/400 and open-systems versions was met with excitement by iSeries users at CUE 2005, says Kevin Patterson, IBM's worldwide iSeries sales director. "It's an emotional issue," Patterson says. "It's not that version 8.1 is here, they're going to jump right to it." But Lawson's iSeries customers are more comfortable knowing the software is there and they can make the move when they're ready, he says.

A Landmark Event

In a few years, the issue of parity between Lawson's OS/400 and open-system products will be moot, because there will be only one Java-based version of the software that runs across all platforms. Lawson has been talking about a wholesale move to Java for several years, and last week it finally gave this project a name and a timeline: Landmark.

Landmark should bring advantages to both Lawson and its customers when the first applications based on the new development framework start to roll-out next year. Eventually, Lawson's developers will do all their programming in the Landmark development environment and the associated Lawson Pattern Language (LPL), which, when combined with IBM's Eclipse tooling, will generate Enterprise JavaBeans (EJBs). Lawson customers doing customization and maintenance work will also work with LPL instead of the various 3GL languages, such as RPG and COBOL, that are generated with the proprietary 4GL used by Lawson today.

The advantages of Landmark are similar for Lawson and its customers. Instead of 30,000 lines of RPG or COBOL code for a given application, the Landmark version of the code will be only 2,000 lines of LPL, because it will reuse various patterns. Lawson sees a consistent 15-to-20x reduction in the sheer volume of code required under Landmark and LPL, says Richard Patton, a senior Lawson research fellow and project leader. This equates with 93 to 95 percent fewer lines of code.

And anytime you can reduce the amount of coding, you can expect to reduce the error rate by a similar amount. For example, instead of writing an allocations application five times, and perhaps doing it five different ways for the various components and versions of Lawson's ERP suite, Landmark's pattern-based development will allow Lawson to write the allocations logic just once, and then reuse as needed, says Mike Roth, Lawson's director of product strategy. At runtime, when one of any number of ERP components needs to do allocations, it calls that single piece of code. This will boost the consistency of Lawson code, and enable faster upgrades, better versioning and patching, and other lifecycle benefits.

Nobody in her right mind comes out against cleaner and more consistent code. But will Lawson's current customers--some of whom have been running Lawson software on the IBM midrange server for 25 years--be able to move to Landmark and learn the new LPL language without undergoing a major ERP rewrite and throwing away everything they've built and their knowledge of RPG? You betcha, Lawson says.

"Unlike competitor's current projects, Landmark is not a platform only for assimilating disparate acquired systems with a goal of simply creating consistencies at the high price of a radical migration," Patton says. "Instead we've created a far-reaching evolution that sets a new standard for software quality, productivity, and ease-of-use while protecting clients' current investments in Lawson software."

Terry Plath, Lawson's director of ERP market development, says Lawson will provide its iSeries customers with tools and a metadata layer for bringing their RPG code into the Landmark IDE. "It will be very quick," Plath says, describing the move to Landmark as more like an upgrade than migration.

Time to IPL Your Lawson Skills

RPG programmers won't have to learn Java to work on Landmark applications, but they will have to learn LPL, a Domain Specific Language (DSL) that will be very declarative and feature an easy-to-learn syntax, Patton says. Patton characterizes DSLs such as LPL as the fifth generation languages (5GLs) of the world, in that they enable developers to modify specific computer programs (Lawson business applications, in this case), while working at a very high level and writing very dense code. Other examples of DSLs include RosettaNet, tools Bell Labs developed for modifying telecom switches, and even Microsoft Excel. DSLs are the future of business application development, Patton says.

But language won't be the real issue with Landmark, Patton says. Anybody who understands a company's business processes will be valuable to an organization deploying Landmark applications. At many OS/400 shops, these are RPG programmers who have kept the applications up-to-date and running for 15 or 20 years. At other companies, they may be business analysts. Some programmers--at Lawson and Lawson shops--will lose their jobs if they don't adapt to change and accept LPL, Patton says.

In terms of the EJB generation, Patton acknowledged that Java applications typically require more hardware, including faster processors and--in particular--more memory, than applications written in other popular languages. (This is particularly true on the iSeries, where RPG is optimized for very efficient database access, and where WebSphere usually requires a hardware upgrade.) But Lawson would not have made the commitment to Java and WebSphere if it harbored any doubts about the efficiency of Java, he says. "By the time we put it [Landmark] out in product, Java will be there, the chips will be there," Patton says.

Perhaps by 2008, when the whole world is running multi-core processors with oogles of on-chip memory, and all applications are multi-threaded and 64-bit, Java will have made tremendous performance gains. Perhaps the gains will arrive in the form of special Java appliances, like the one from Azul Networks. Or maybe the performance gains will come from the sheer reduction in lines of code, and the greater cleanliness of the code.

In any event, there will be no "big bang" migration to Landmark, and Lawson plans to make the transition gradually, over the next few years. The first Landmark application--a sourcing application for government procurement offices--is due out in 2006. Just the same, Lawson is not waiting around to start writing in Landmark. The Java ball is rolling at Lawson, and change is assured.

This article has been corrected since it was first published. A reduction in lines of code by a factor of 15 to 20, when expressed as a percent, corresponds with a 93 to 95 percent reduction, not 80 to 85 percent, as first reported. IT Jungle regrets the error. [Correction made 5/16/05.]