What is the business issue?

Every time a modification is received from a software vendor, companies that run third-party software packages face a critical business issue: how to determine the exact impact of installing the new version of the software on their System i or AS/400 production system. IT teams spend an enormous amount of time trying to understand this impact with no guarantee that the inspection that they run is thorough. Impact analysis becomes even more complicated when the IT system is based on a combination of standard software packages and modified applications that access the same database. What will happen if the new version of the software received from the third-party vendor modifies the size or structure of a field?

There are four critical steps to implementing a new version of a software package:

Step 1: Reception. It is imperative to check integrity of delivered elements to ensure that the delivered code is bug-free, and that it will not generate regression in production.

Step 2: Integration. All new deliveries may require integration tasks. Any modification to a system’s program or files will require identification of impacted peripheral components, and a project plan to integrate the delivery with the rest of the system.

Step 3: Functional tests. Once modifications are made, the next step is to perform tests to validate that changes have not generated functional regressions. These recurring tests are often neglected because they are costly and painstaking. However, they are essential to production security and reliability.

Step 4: Documentation. Often neglected, documentation extends the value of an information system. Combined with rigorous organization and architecture, it is essential to meeting requirements of internal and external audits that a bank, for example, may be required to perform. It is also a response to operational risk-related needs described in Basel 2 regulations and other international standards.