PHP Forges Ahead; Consultant Propels Multiple Projects

Published: February 23, 2009

by Dan Burger

PHP has had a place at the IBM System i table for the past three years and somewhere close to 12,000 System i application developers have sat down to taste the popular Web-enablement language. Some are eating it up. Last week, I spoke with Larry Nies, president of NSC, a company with a System i focus and a flair for PHP application development that depends on the Zend Framework.

Dan Burger: How did PHP come onto your radar?

Larry Nies: We were working on a customer site. We work with a number of foundries in the United States. In this case, it was in Wisconsin. We were hired to do an analysis on their IT systems. In 2006, we began looking for an alternative to Net.Data, RPG CGIDEV, Java, and development environments that we had been using to provide data to the foundry's end users, or vendors. The foundry was going into a lean manufacturing mode. Part of that involved improving their on-time delivery.

One of the alternatives was PHP. So we downloaded Zend Core to the foundry's iSeries Model 520, and we began working with the purchasing and materials manager to develop a supplier portal. That's where it started.

DB: So what made PHP the wise choice in this instance?

LN: When we took a look at the PHP, we noticed a significant improvement in performance on providing data to the end users via browser. This was after doing some tests and comparisons with the RPG CGIDEV, Net.Data, and other languages that had been used.

In addition to performance gains, there was the return on investment that the foundry realized. After the first year of using the supply portal created in PHP, the return on investment was $750,000. Now in the second year, the foundry is realizing over $1 million in savings. In large part this is because they have gone from a 50 percent on-time delivery (from their vendors) to between 93 and 95 percent. During this time, they have gone from 160 vendors to 60 prime vendors. The foundry put the system in place, established the rules for the vendors, and that's how some of the suppliers were weeded out.

Because the foundry could better track information and have a direct interface with the vendors, it met a lean manufacturing goal, which was to reduce the number of vendors and improve the communication and relationships between the remaining vendors. That goal was reached with the product portal that was written in PHP.

We provided a tool to the end users (the suppliers) so they controlled their own destiny. The suppliers were asked to provide more savings and better on-time delivery. It helped the foundry weed-out vendors that did not match the criteria. Before the product portal was created, the foundry did not have a vehicle to gain greater control over its suppliers.

The fact that PHP is cross-platform played a part as well. Now we have a Linux server running in this environment and we have a number of Windows SQL Servers along with the iSeries. We put the Apache sever with PHP on the iSeries and now we can access just about anywhere we want.

We have an application running in an RPG environment and we initiate a PHP request to pull data from a SQL Server. We are merging daily operations. There's information coming from the i5 with shop information coming in off the floor. And this is all done in real time. PHP is the interface platform.

DB: Are these entirely new applications or are they refaced green-screen applications or a combination of both?

LN: The RPG applications are a combination. The majority of them interface with the existing legacy solution, and we have replaced some of the green screens with the newer versions of the applications. We could have written the supplier portal in green screen, but we believed it was better for presentation purposes and some of the things we could do.

Other applications are brand new. Some are ISO 9000 quality management forms. There is a PC application that manages all the quality forms and specifications so that vendors can come in and look at specifications online.

DB: Does application modernization always go along with PHP?

LN: Yes. You take an existing app and most of the time the driving force is to make it better. And if you can make it better, you might as well use one of the newer tools. PHP offers opportunities to create applications that were not available before because of access to SQL, for one example.

DB: I see the driving force for using PHP as a need to develop apps to relieve particular pain points. There doesn't seem to a desire to build an entirely new enterprise architecture like SOA, for instance.

LN: Companies want a return on investment. That's a critical part of it. PHP is one of the vehicles to do that. The second part is that executives are thinking differently. Once one pain point is relieved with an application, another pain point moves to the top of the list. The executive sees the results and likes what he sees.

They are seeing how the applications help the organization. They see alternatives to the ways things have always been done. But the best-bang-for-the-buck factor is what moves projects forward. The question being asked is: Can we improve what we have without having to go out and buy the whole package once again? The answer is: Yes.

And not only can we show them the methodology with PHP, we can show them the performance.

DB: Will PHP be the development language that always provides the performance gain? Is it the right thing to use in every circumstance?

LN: Generally speaking, we noticed that when we went away from some of the traditional ways we built apps--with RPG CGIDEV, and even in Java--there was a performance improvement right away using PHP. What helped even more was that the customer put in Zend Platform Optimizer. That improved it even more. The engine that they are using for their PHP provided significant performance response. That is what happens generally across the board.

We have a number of locations where we have done PHP work with Zend Core and we see these performance gains in pretty much every location. In most cases, we are linking into a legacy solution and presenting information. We are doing updates, doing SQL-ing, and a variety of things. We always are pleased with the response times we are getting. We compared it to the other ways that were being done before.

DB: At the one foundry that you've been using as your main example, who is doing the application development?

LN: Our company is doing it. There are four of us that program in PHP and we also programmed in other languages prior to this. The majority of the applications have been done by the staff at NSC. The foundry has a network person, but it doesn't have a programming staff. They have outsourced that to us.

DB: Where does this project stand now?

LN: We just finished a segment that added full-control ASN (advanced shipping notice) for the vendors. Now the vendor can go in and pull all the data it needs and download it directly. We provided an import version that allows them to import the info into their own systems.

We are in the process of doing a quoting system. Currently it's in a green screen. We are looking at using a combination of the 5250 Bridge from Zend and the standard Web-based PHP browser to accomplish this.

DB: With the group of companies you work with on PHP projects, are most of their existing applications written in older versions of RPG?

LN: Of the 12 foundries we work with, there's one that runs COBOL on the iSeries, which doesn't matter to us, but the majority of the applications are written in ILE RPG. Some are written in older RPG.

The director of finance at a new location where we are working told us, "We need to get some of these things in place because the younger people coming through today are the driving force to do some of these new applications, and they want a GUI-type environment. Ten years ago, the green-screen environment was fine. The younger generation sees PHP as a fit for what they want while still using the legacy solution that provides all the costing and everything else."

DB: So is NSC doing the application development work with all your clients?

LN: We have helped clients install Zend Core and then coached them on their PHP project. In these cases, they have staff available and the staff skill set is primarily RPG. In one case, there's a person who has RPG skills, but also has skills in RPG CGIDEV. She understands how HTML, Java script, and the Web works. By understanding that, it helps.

As far as programming goes, we have RPG programmers that pick up PHP quickly. They are writing programs in two weeks. These are the types of applications that keep track of documents so they can add, change, and delete from a database, and do a search. These are typical green-screen applications.

DB: How easy is it for RPG programmers to make this transition?

LN: The reality is that there is a mix of people who can make this transition. You'll get people with a real interest in learning this. Their learning curve drops significantly. Some take the view that learning something new is a burden.

You will have some procedural RPGers who can't pick up PHP. The applications they will build will range from not too complex to fairly complex. Other RPGers will pick up PHP and not only will they be able to do simple applications, but they will move to the object-oriented side.

If the developers have some experience in something like Net.Data, Java, or RPG CGIDEV, then PHP is just another tool for them. They have seen this type of thing before. Those that have spent a long time green-screening and don't really use the Internet, they are not going to be as good at this.

RELATED STORIES

Zend's PHP to be Preloaded Onto IBM i OS

Zend Framework 1.7 Includes DB2/400 Adapter

Zend Builds Closer DB2/400 Ties into PHP Platform

PHP and the Zend Framework

Zend's PHP Offering Expands Options for iSeries Developers

                     Post this story to del.icio.us
               Post this story to Digg
    Post this story to Slashdot