IBM i Shops Behind The Customized ERP Eight Ball
April 4, 2016 Dan Burger
|
We are not sheep. What we do with our ERP software is our own business and our widget business is not going to be run like all other widget businesses. And we don’t all jump when the ERP software vendor says jump. Most IBM midrange shops are running packaged ERP software and quite a few have customized them to get what they really want. Until it’s time to upgrade, that is. Software upgrades, even when the software is not customized, can be a pain in the patootie. Whether that’s a dull pain or a sharp pain is often related to the extent that the customizations vary from the vendor-supported base code and whether you have access to the source code or not. When the base code gets a patch or is upgraded, how much revision work have you created for yourself with your customizations? Having the source code relieves pain and eases the customization process, therefore the upgrade process, but ERP vendors, by and large, aren’t fond of sharing source code.
And it’s not just the software package itself. It’s everything else that the software touches. It’s a domino effect–an event that sets off a chain of events. It’s one of the top reasons that lead to upgrade procrastination. Risk is being weighed against benefit. Part of the risk assessment is simply estimating: Do we have the time that it takes? You hear a lot about aligning applications with business objectives and business processes. That’s exactly why customization takes place. What takes place during a software upgrade or an OS upgrade or both is not so precise. The best advice is to stay current with your software and OS releases. Covering those bases will take some time for planning and deployment, but the time savings realized at upgrade time will pay off. But advice is not always taken. People drive after having too much to drink and they buy boats that never leave the dock. Haphazard software customization and falling behind on software upgrade cycles are also costly decisions that could have been avoided. Yet it happens over and over. The most often told horror story is the one about the IT director unable to pull himself and his company from the V5R4 swamp. “We still have customers sitting on V5R4 who cannot escape from that because they have legacy code that cannot be upgraded,” says Wim Jongman, the managing director and CTO at Remain Software. “Typically those companies don’t have the source code that would allow them to recompile programs to the proper state. Without the source, it becomes difficult to do something about it.” The “stuck on V5R4” story is probably the worst case scenario of the upgrade dilemmas. It’s often told along with the warning of what happens when your guiding principle is the “If it ain’t broke, don’t fix it” philosophy. The mission critical software that’s the monkey wrench in the gears of progress can be a packaged application or it can be home grown. The common denominator is that it is out of date and no longer compatible with currently supported versions of the OS, Power Systems hardware, other programs that are essential to doing business, and new technology that increases efficiency in dozens of ways. But wait there’s more . . . As Jongman pointed out during a discussion with IT Jungle last week, difficulties with the upgrade process don’t disappear just because you are current (including one release behind the latest) on the OS and packaged software or your homegrown software is maintained and modernized. Jongman has helped companies through the customized software upgrade process many times. His company specializes in automating many of the manual processes that cast a huge shadow on these types of upgrades. The tools automate processes such as code analysis, versioning control, compare and merge, impact analysis, and deployment to remote systems. His advice is to break down the project into manageable pieces:
There’s a bit of a juggling act to be mastered in upgrading customized software. It involves keeping your eyes on three versions: the original version, the customized production version, and the new upgraded version. When done right changes between the original and new versions are accomplished without overwriting or breaking the customizations. Jongman places particular emphasis on testing. Confidence comes from testing and the process should prove that programs will merge and compile correctly, which leads to a smooth upgrade. “If you merge a program and it compiles correctly, that’s a good indication. But after compiling, it still needs to be tested to see if it functions according to the specifications,” he says. Implementing an upgrade can be time-consuming and cumbersome. (It’s the reason IBM i has Technology Refreshes and a longer time frame between major releases of the OS.) For software that is likely to be customized or integrated with software that is customized the time consumption factor grows longer and the cumbersome index climbs. But upgrade neglect adds risk to the upgrade when it eventually comes and the added cost associated with the increased complexity overwhelms the perceived savings associated with skipping upgrades. RELATED STORIES Change Management Plays Major Role In IBM i Modernization New RDi Ready For IBM i Developers Remain Software ALM Tool Gets CA Plex Interface Software Change Management Designed For Small IBM i Shops Remain Software Improves ALM Workflow, Readies Multi-Platform Capabilities
|
