1 / 2

How IBMi Witnessed Operational Evolution from Traditional to Modern

While businesses and processes across the globe have transformed drastically over the years, the IT industry has not kept its pace.<br><br>With the wide use of IBMi and AS400 systems, the notion of outdated legacy systems has not yet hit the minds of IT professionals.<br><br>

8415
Download Presentation

How IBMi Witnessed Operational Evolution from Traditional to Modern

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. How IBMi Witnessed Operational Evolution from Traditional to Modern? Thirty years ago, the root cause of unplanned downtime in IT processes was human error. Even today, around 60% of respondents to an ITIC survey believe that human error is the leading cause of unprecedented downtime. While businesses and processes across the globe have transformed drastically over the years, the IT industry has not kept its pace. With the wide use of IBMi and AS400 systems, the notion of outdated legacy systems has not yet hit the minds of IT professionals.

  2. But, why? You may argue that human error encompasses several things, yet the critical business aspects should not be included. To truly understand this, we must look closely at how IT processes used to run 30 years ago. This will help us understand how and why legacy systems are still responsible for downtime in the current day. For an average developer, such a code may be a head-scratcher. He may have to grasp the context of the code before cracking its meaning. Yet, this method is not free of challenges. Hiring a clever coder may pose the following dangers: •The talent may not be up to mark. •The testing process may falter. You cannot wholly rely on clever coders. The biggest issue is that they are here one day and go on the other. The developer who devised your code may have changed their positions, left the company, or retired. While such coding may have benefitted you before, the IT team cannot devote time to coding for application dependencies without prompting unresponsiveness in another place. Not just that, they can also not take the risk of changing the older code. Since only one coder understands the whole thing, this option is not very practical in the long run and may lead to more complexities. When it comes to testing, a whole new set of issues arise. There could be oblivion concerning testing the changes, running complete night processing, and re-running a single part of night processing. If your IT team takes too much time making these decisions and attending to them, they are likely not responsive enough to the user community for a new report. Thirty years ago, the idea of using homegrown scripts might have been a good one, but today’s developers work on solving business issues instead of investing time in reinventing things. Read More: https://www.integrativesystems.com/ibmi-evolution/

More Related