IN THIS ISSUE:
- September Meeting of Members - Wednesday, September 25th
- Retiring Applications - article by Debbie Gallagher
- Stay Connected - Confirm your subscription to TUG Buzz
To kick off our 35th Year...
September 2019 Meeting of Members!
Date: Wednesday September 25, 2019
LOCATION: Monte Carlo Inn, Markham Downtown
7255 Warden Ave (at Denison Street)
Markham, Ontario L3R 1B4
** FREE Parking **
AGENDA for September 25th MoM
ADMISSION: Free for TUG members ($60 non-members)
Registration 4:30 pm
5:00 pm - Session 1:
Steve Will, Chief Architect - IBM i Operating System
"IBM i in 2019: It's Not Just AS/400"
IBM's Steve Will talks AS/400, POWER9, IBM i 7.4, cognitive systems, and everything in between! True or False: The IBM i operating system is just the AS/400 all over again...
6:00 pm - Intermission (Buffet Dinner & Networking)
7:00 pm - Session 2:
Barbara Morris, IBM Toronto Lab RPG Compiler Development
"Practicalities of IBM i Modernization"
Best Practices for Modern RPG - The features of ILE RPG that allow you to write "modern" code and...
Back to Top
[article] Retiring Applications
A frequently-neglected part of the plan for implementation of a new application is the retirement of the one that is being replaced.
However, there is good reason to do that work at the same time as your new project, as there are risks and costs related to keeping an old system running after it is no longer actively used.
The most obvious concern with maintaining applications that are no longer used is the cost of licensing and support agreements. There are also less obvious costs. For example, you may be running certain hardware or operating systems for the sole purpose of maintaining the legacy applications. You may also pay consultants with legacy expertise to maintain that legacy hardware and software. Perhaps it is no longer feasible to apply some types of security to older systems.
Here is an approach to consider and tailor to your own application and organization.
Although managed by IT, there must be a business owner who will participate in retirement planning and approve any decisions that are relevant to the business.
Unless the application being retired is fully home-grown, you likely have some contracts in place. For example, application licenses for users and administrators, and support agreements. The infrastructure or security support may also be covered by service contracts. Review all of the relevant contracts and determine what your rights and responsibilities are. E.g. if users are not maintaining any data, but are read-only, do you still have to pay? What is the notice period, and when is the deadline to give notice? Are your responsibilities truly clear in the contract, or do you need a lawyer to review it?
Continuing access to the data
Depending on the business use of the application, it may be necessary to keep the data for some period of time. Start by identifying the data that is kept in the system. Is it general ledger, purchase orders, energy usage? Also identify whether the application is the system of record for that data. If the application is just for reporting or transmitting, and the system of record is somewhere else, it may much easier to eliminate the application's data set.
If the application is the system of record, map the data sets in the system to the corporate data retention policy. This policy will have been developed in alignment with compliance, legal, and regulatory requirements. Then, discuss with the business owner what their business needs are for ongoing access to the data. This may be different from the corporate data retention policy.
While you're having that discussion with the business, find out what kind of access to the data is going to be needed. Do they still need to use the application to view the data, or will it be enough to be able to query the database?
Also ask the business owner how many users should have continuing access to the application. Perhaps you can reduce the number of users to just a few, either right away, or after a year or so.
If the application being retired is on some technology that you no longer use for any other applications, it may be tempting to copy the database to a technology that you support as a standard. However, this may not provide what the business needs. If the data structure is complex, you may no longer have an employee with the experience to query that structure and get the right answer. In addition, if there is a need to re-generate reports or documents, it may not be feasible to do so without the application.
Perhaps based on either the retention policy, or the business needs, you have learned that the application is still needed for inquiry and reporting for several years. There still may be steps you can take to reduce the effort of operating the application.
For example, since the data isn't changing, it may not be necessary to do daily backups or manage high availability. Perhaps the business would now be fine with a monthly backup, so you have fresh media. Maybe the business would agree with a longer recovery in the event of failure.
It's also likely that you could eliminate the development and testing environments for the retiring application.
Security and controls
You can also examine the security and controls for the retiring application. For example, discuss with the business whether they still require two-factor authentication.
It's also a good time to discuss whether the controls for the application and its supporting infrastructure should be tested any more as part of the audit. Some of the testing may no longer be needed, which could reduce the effort of internal or external auditors.
If you are generally moving applications to the cloud, or no longer wish to support the particular technology platform of the retiring application in your data centre, you may consider options to have someone else manage it for you. There are usually vendors who would agree to host the hardware and application in their own data centre. Note that this approach requires considerable planning, and you should engage the potential vendor early to discuss requirements.
When you implement a new system, planning for the retirement of the old one should be planned at the same time. It should be possible to manage costs and risks by appropriate planning and execution.
This article provided some high-level guidance on retirement planning to get you started. You can use it as a framework, and customize it to your own organization's needs.
Copyright 2019 - Debbie Gallagher
Debbie Gallagher is a project manager and business analyst. She can be reached by email at email@example.com. Previous project management articles are archived at http://debbiespmtales.blogspot.ca.
Back To Top
Stay Connected with TUG
The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful.
Canada's Anti-Spam Legislation (CAS) requires that we receive your permission to continue sending you emails.
You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.
Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.
Back To Top
The Toronto Users Group for Power Systems (TUG) is a user group/forum for the exchange of ideas, and specializes in providing affordable education relating to the IBM iSeries, AS/400, System i, and Power Systems platforms. TUG is in its 35th year of operation.
Articles & Downloads archives
TUG Buzz! archives