Calculating the Risks on All Sides of the App Modernization Issue

March 21, 2011 Dan Burger

Risky business. Is there really any other kind of business? Show me someone who eliminates risk, and I’ll show you smoke and mirrors. Executives are supposed to run their firms by minimizing risk. Those with their hand on the throttle of IT development, particularly in the IBM i environments you know so well, sometimes back off on application modernization projects because they are not sure how to manage risk. Ask Paul Conte if he agrees with this knee-jerk reaction.

Conte is a consultant, a one-man shop. He’s been around the IBM midrange long enough to remember the debut of the AS/400. He’s been a programmer, a product developer, and the owner of a software business. And he’s learned some lessons along the way. One of the most important is that risk management is pivotal in terms of project management. His focus is on helping IT staffs focus.

“Very few IT decisions are technological decisions,” he said last week on the phone from his Eugene, Oregon, home. “I don’t mean to diminish technology, but thinking strategically about how to approach a project is what makes the difference. In the companies I work with, I’m there to improve their policies, their agility, their productivity, and to reduce their liabilities.”

Conte is the author of books and magazine articles pertaining to project management, enterprise application architecture, and how risk management applies. He recently finished an ebook project titled Transforming IBM i Applications: Your Journey Beyond ‘Modernization. The book was commissioned by the application development software company LANSA. It’s available as a free download here. (LANSA and Conte have teamed up in the past on white papers, which you can find on the LANSA Web site.)

The ebook project was designed to help companies think through the software development process. Conte says the target readers are either in a very early stage of a modernization plan or they have started into a modernization project and have hit a wall, but it is also good reading for those who don’t have an immediate modernization requirement looming over them.

“The most common barrier to application modernization projects that I’ve experienced is that the company management knows it wants an improved interface and improved functionality, but it’s not a live-or-die situation,” Conte says. “So they sit pat. It’s not viewed as a major unrealized opportunity or major threat from a competitor. They don’t see a big risk in doing nothing.”

Where companies do see a risk is getting onboard with a technology that doesn’t have staying power. They don’t want to invest time, money, and staffing on technology that could be abandoned or on vendors that could go out of business or be purchased by companies with a different technological point of view.

Conte advises companies to get a foundation based on what’s driving this strategy now and what’s going to be driving it in the future. “Companies need to identify the real risks, how to manage the risk, and make a plan for where you want to go,” he says. “Obviously, cost is a factor too, but not the highest priority. Figure out what you need without being exposed to extreme risk.”

An example of how this might play out in the real world is a company that has depended on a print catalog and a sales channel to generate orders. The company finds that customers prefer viewing products online and making their purchases via the Web. The problem is not having applications suitable for those customers. It’s not just a browser interface issue. It’s a whole new approach to dealing with customers. And doing nothing is putting business at risk.

Some companies explore screen scraping and compare that to developing a new front end using a language capable of multi-platform interoperability.

Conte’s advice is choosing a comprehensive way to fit the pieces together. Avoid hacking together more code and instead develop a framework for the future.

“People don’t wake up one day and say, ‘We’ve got to modernize our applications,'” says LANSA’s president and chief executive officer, Steve Gapp. “They wake up one day and say, ‘We’ve acquired this new division. Our business processes don’t work. How do we solve that problem?'”

In other words, few companies are in a race to quickly out-modernize their competition. Gapp’s insights and instincts tell him most projects are driven by business shifts, which cause enough pain to evoke change. And once those projects take shape, they involve some degree of user interface re-engineering, take into consideration integration needs, and incorporate business process improvements.

“In cases of mergers and acquisitions or combining divisions, it’s difficult to introduce a green-screen application to those who aren’t familiar with that interface,” Gapp says. “Management expects a modern-looking application with workflow capabilities that make cross-platform integration quick and easy.”

Gapp says the biggest risk involving companies dependent on green-screen applications is the aging and retiring RPG workforce, which is diminishing. He makes note of the large amount of RPG code that has been maintained for many years. “As those guys retire and take with them a lot of knowledge that is locked up in their heads, that becomes a bigger business risk.”

Who is replacing the RPG knowledge?

“People coming out of universities have been trained in object-oriented architecture and understand modern development environments,” Gapp says. “RPG is a very specific language tied to a very specific platform. Fewer colleges are teaching it and fewer youngsters are coming onboard accepting that as a mainstream language.”

Everyone likes to read about the bold adventurers who fearlessly went where no person had gone before, but most companies, and the people who run them, don’t want to take a lot of risk. One of the best ways to mitigate risk is taking big projects and slicing them into incremental projects. Conte calls the incremental approach to project management “the silver bullet” that lowers risk.

Take an application modernization project with an estimated completion time of one year as an example. Conte’s advice is to divide it into increments so it becomes more sensible.

“There will be some zigging and zagging even in an incremental approach,” Conte says as if to deflect inclinations that incremental approaches are without flaws. “Each increment will not be 100 percent on the mark and corrections will have to be made. It could be a technology correction or a staffing correction.”

Something almost always goes wrong, Conte admits. It could be you don’t have enough knowledge to perfectly complete the increment or maybe the environment unexpectedly changes. “What you don’t know you don’t know kills you,” is one of Conte’s favorite warnings. So in the end, it’s important to prioritize the most important increments and get them done in the time allotted. “The incremental approach allows you to stop and discover what you previously didn’t know,” he says. And it allows the opportunity to adjust for it.”

Another obstacle that Conte identifies is always trying for the highest quality and the most function. It almost always leads to problems because projects run overtime and over budget. It’s better to hit 80 percent of the functionality and remain on time and on budget. As long as the right things get done.

Remembering his own programming days, Conte observes it’s hard to persuade programmers to do things with the idea that it will not be perfect, but it’s better to complete each project and make the most of the most important stuff.