I am sure that after reading my previous blog post on manufacturing legacy systems many readers saw me as just another soldier of AS/400 system’s army of opponents and probably would not expect any future pro-System i/AS/400 publications. This is definitely not the case—I am not a legacy system opponent. The message I’ve been trying to deliver in my blog posts is that a well-thought out, balanced, and systematically formed business software portfolio is important even though the platform of the system isn’t necessarily the principal criteria for system replacement.
There are thousands of examples of successfully running enterprise resource planning (ERP) systems and other packages based on old AS/400 technology but it does not mean that the companies using this technology need to immediately replace them just because they are not as cutting-edge as the latest technological development. Here are some reasons why changes may be required to a particular ERP system:
• Hampers users productivity.
• Some of the system’s functionality become non-relevant to the business practice.
• The existing technologies do not provide certain technical capabilities and therefore limit the business’ performance.
On the other hand, none of, for example, metal product manufacturers would expect their metal working machines’ outside appearance provided by one of the top-world Italian design studios. Because it is not really that important to have nice looking machines. Those machines must be able to bring an added value to the products and to the company and it does not really matter how stylish their design is.
By analogy with manufacturing ERP systems, it is not a necessity that the IT industry’s latest bells and whistles have to be immediately implemented in your business unless there are real gaps that must be filled. And very often it makes no difference on how good-looking the ERP system’s interface is at your factory and what color the screens are, the only purpose of it is to provide required functionality at a minimal cost. Everything else is non-essential and, to my understanding, cannot be a key reason to replace the entire ERP system. Furthermore, from real practice we know that replacing with a third-party application does not always provide the promised level of effectiveness compared to old applications, and immerses the company into a messy, costly, and lengthy implementation process. Therefore, a very serious and multidimensional analysis is required before deciding what can be done with a legacy system or its components.
Here are the three major ways to upgrade an existing System i - AS/400 system:
• Legacy system rejuvenation (refacing): upgrading the user interface, minor add-ons, and light enhancements
• Legacy system full scale modernization: source code redevelopment and business processes redefining
• Legacy system complete replacement: replacing with another ERP package.
The first variant seems to be the least expensive because it doesn’t affect the structure of the software, rather just the graphical user interface (GUI). At the same time, it is the least effective and the least helpful—as it mostly results in a new “look” for the system or filling missing functionality gaps. As for full scale modernization, depending on the requirements defined, it does make sense to combine an existing technical foundation with newer service-oriented architecture (SOA) approaches—making it possible to tie up with another platforms and technologies.
At the other end of the spectrum there is a third-party ERP system implementation, which is a long and challenging process that carries a whole bunch of accompanying risks.
Lansa, a Chicago-based company brought—among many other things—their development environment for legacy ERP modernization projects. Not long ago, I had a meeting with Bob Gleisner, Director of Professional Services, and David Brault, Product Marketing Manager, who kindly introduced me the Lansa’s Rapid Application Modernization Process (RAMP). In a nutshell, RAMP is the software development framework that allows selecting and capturing AS/400 / System i applications, modules, or certain business processes inside the RAMP framework, combining them into graphical development environment, and then replacing legacy software elements with newly redesigned pieces. Basically, this approach merges the first two above-mentioned typical AS/400 upgrade methods (refacing and rewriting), and ultimately delivers an entirely renewed system that even experienced users would have difficulty recognizing.
This procedure opens up opportunities for businesses using legacy systems because it gives them a handy tool to quickly restructure and redesign their ERP systems as a whole, separate parts, or distinct business processes in a way, level, and speed they require. At the same time, it enriches the system with new technologies, such as a Windows-like familiar user interface, XML, SOA, Web services, and plenty of graphical capabilities. By using RAMP, there is no need to change the logic and structure of an existing System i – AS/400 platform because the application is still running on the same server hardware.
This product seems to be really unique and standing aside dozens of other legacy system modernization offers on the market. I believe it absolutely deserves to be brought to the IT executives’ and decision-makers close attention. Lansa offers an elegant and truly wise alternative to standard approaches.
Interesting observations. But I generally hear about a different reason for moving away from the AS/400: experience. Many of these legacy systems have been maintained for 20+ years by the same group of administrators. And these administrators are retiring. The younger generation of IT professionals lack RPG skills and are far more keen on newer application stacks. This situation is particularly acute in municipal/county governments. A declining tax-base is forcing the early retirement of those people who have the skills to keep the legacy systems running. When CIOs start to worry about their internal ability to care-and-feed an ERP system, it’s only a matter of time until they migrate! The problem may be at the programming or application layer, but the AS/400 takes the fall.
I want to get more information about AS/400 & the letest verssion.
I think the biggest reason why folks move away from robust AS/400 environments is due to a lack of understanding and commitment by corporate management. The analogy would be like a ships captain who has the best ship in the sea but never takes a second look at it, never trains his crew and never invests further in it. These unique qualities of ignorance are only achievable on an AS/400 ship due to it’s high reliability and inherent builtin security and great performance.
The AS/400 server (ship) self-heals, it’s crew keeps working with it smoothly and management hardly ever hears about this magical ‘black-box’. Therefore the AS/400 captain lifts up his binoculars and focuses on a Windows ship nearby with all the lights flashing on it, the smoke coming out of it appears quite normal. The Windows crew shouts to their management all the time for updates, memory, CPU, viruses, network, virtualization, applications, database DBMS, Worms etc. So the windows captain never gets time to use his binoculars to see the calm and robust AS/400 ship with the confused captain looking at them.
Perhaps this 3-part series on IBM iSeries from 2005 would still be of interest and relevance here: http://bit.ly/9oiHvK
433289 966615I saw however one more thing concerning this on one more weblog. Youve naturally spent some time on this. Effectively done! 502692