eCIO PPT Sunsetting strategy v 3 general distribution

DEVELOPING AN APPLICATION RETIREMENT AND DECOMMISSIONING STRATEGY FOR A LARGE-SCALE

PROJECT

PRIMER OVERVIEW AND FRAMEWORK PAPER

(DOC #: PROJECT-ARD.001 V 0.3 DRAFT FOR DISCUSSION PURPOSESCONFIDENTIALLY: GENERAL RELEASE

IT 2700-XX V 0.1PRESENTATION

IT Project Control Office (PCO)As of Date: <date>

Prepared for: • Project IT OCI’s• Those interested in understanding the Application Retirement/

Decommissioning process

Prepared By: David Niles; Program Manager: Systems Integration

Tuesday, May 2, 2023ECIO EXECUTIVE WORKBENCH Page: 1

Tuesday, May 2, 2023

VALUE PROPOSITION/PROBLEM STATEMENT/ TAKEAWAYS

• What is a successful plan of action (POA) to decommissioning an application?• What are the various committee structures to be put in place for this type of

project?• What type of documentation is typically delivered in support of a application

retirement?• Can we illustrate how a large scale systems integration and applications retirement

efforts can work hand-in-hand?• What requirements need to be addressed with an applications retirement

process?

ECIO EXECUTIVE WORKBENCH Page: 2

OVERVIEW

1. Objectives and topics to be covered in this framework paper.2. Introduction & Purpose3. Overview & Approach

– Applications scheduled for applications retirement4. Assumptions and Constraints5. Tasks and Deliverables

• Appendices & Supporting Profiles– Overviews of Artifacts & Deliverables– Detail Timelines & Schedules

Intended Audience: – Project Team– OCI Committee membership

Contributors:


OVERVIEW OBJECTIVES

The objectives of this overview, cover two main focuses, to:1. Understanding the background and efforts surrounding application retirement2. Illustrate the steps for retirement of the relevant applications for Project

Topics we will cover.– What is the approach and methodology to accomplish applications retirement

for Project– What are the expected deliverables?– What roles are required?– What is the timeline and schedule?


INTRODUCTION

• This overview outlines the approach we are planning to undertake for sun setting the applications scheduled for decommissioning under a project.

• The systems decommissioning phase of the Systems Development Life Cycle (SDLC) is initiated through the deployment of the SAP application “Tax & Revenue Management (TRM) system (includes the PSCD component)”. This has resulted in a consolidation of several vertical applications with varying degrees of automation and architectures that are not longer required or supported.

• Systems decommissioning requires a strict adherence to mandates and regulations related to contract terminations, disposition of assets, coordination's with various OGD’s, records managements (including retention), transitions of fiscal management duties and the placements of staff.

• To begin the process, a series of meetings will be scheduled to set the foundations of the detail work activities for each of the applications. Irrespective of the final decommissioning dates, the strategy and activities should remain the same, and getting an early start on this should be beneficial. To assist others in subsequent efforts, we will produce a System Decommissioning guidebook as an initial step.


• At the end of systems decommissioning, a phase review is conducted and lessons learned for subsequent considerations of the other applications.

• The next pages present explanations and background on the various model’s, processes and deliverables.

• Next, is a short descriptions from Wikipedia that explains the philosophy behind applications sun setting.


SUN SETTING DEFINITION

• “Application retirement, also called application decommissioning and application sun setting, is the practice of shutting down redundant or obsolete business applications while retaining access to the historical data. Legacy applications are often maintained solely to provide infrequent or sporadic access to the data within the application database for regulatory or business purposes. With organizations spending upwards of 75% of their application software budgets on ongoing maintenance, application retirement can deliver significant cost savings.

• The act of application retirement usually involves relocating data from the legacy application database to another data repository or archive store that can be accessed independently using industry standard reporting or business intelligence tools. Application retirement allows IT departments within companies to reduce the software, hardware and resources required to manage legacy data.”– Wikipedia (2013)


APPROACH & METHODOLOGY

• Our approach will follow a typical project life cycle dealing with applications decommissioning and utilize standard projects artifacts in support of those decommissioning efforts.

• For each release of the functionality delivered by Project we will have a “wave” of applications scheduled for decommissioning. For each “wave”, we will undergo a set of activities for each of the applications, but coordinated by each set of wave. For those activities that cross applications suites e.g. contracts, infrastructure, we should be able to maximize our efforts. Each effort should begin no later than 6 months prior to the Project release. This will ensure we have enough time to make adjustments for staff, contracts et al.– Series of meeting for discovery per individual application– This effort will be replicated by applications scheduled for decommissioning– Execution– Checklists– Approach from the “Office of Systems Integration” as some other government

agencies have done.


APPLICATION RETIREMENT TOUCH POINTS:CONTEXT DIAGRAM


EARLY REQUIREMENTS COLLECTION

• Some of the early requirements as suggested include:– Decommissioning documentation must be easily assessable to all staff involved in the

activities.– Standard format and content guides will be developed. – Individual application level schedules and an overall schedule of activities will be developed.– Activities and documentation must cover:

• Internal Audit Requirements• Application Component Retention Requirements

– Programs [On-line, batch, RJE]; Job Streams; Security Files [sub-X, system controller]; Documentation [directories, program folders, production instructions]; Training Material

– Determine Data Retention Requirements (DSS, Back-ups, Archives, Production Files, Test Files)

– Identify locations of all data (production, training, quality assurance, developer, end user)

– Identify Data Archiving Alternatives


COLLECTION (CONTINUED)

– Determine disposition of all legacy application data. (Should include data plans from Enterprise Reporting.)• Determine Final Production and Existing Report Retention (Paper, GcDocs,

Fiche)– Plan for Final Production Runs Including:

• Interface Requirements• Conversion Requirements• Business Cycle Requirements

– Determine all system level software that can be retired as a result of the decommissioning

– Application Access Requirements beyond Project Implementation dates– Data Access Requirements beyond Project Implementation dates


APPLICATIONS SCHEDULED FOR DECOMMISSIONING

The following slides outline the applications scheduled for decommissioning. This is still very much of a work-in-progress, and the final IT roadmap remains to be determined.

The business roadmap illustrates 4 components as follows:– Component 1: Accounts Receivable Ledger (Project)– Component 2: Client Identification– Component 3: Assessment and Reassessment– Component 4: Trade Modernization

Within each of these components, the tentative dates of each application set scheduled for decommissioning, as of the date of this overview, are:

– Wave 1 - March YYYY– Wave 2 – September YYYY– Wave 3 – September YYYY– Wave 4 – March YYYY– Wave 5 – September YYYY


APPLICATIONS BY FUNCTION


1ST – 5TH WAVE SET OF APPLICATIONS DECOMMISSIONED

1st WaveThe functionality expected to be delivered prior to these applications being decommissioned include:

• Project PSCD Implemented which includes the functionality of:– <functionality>

– By delivering this functionality, the applications that can be scheduled for decommissioning are:• <Systems/Applications>• To be determined (not shown on the bz roadmap)

– <Systems/Applications>– Additional application background information, interfaces under consideration and

points-of-contact are located in the appendices.• 2nd Wave … (Concepts TB Duplicated from above)• 3rd Wave …• 4th Wave …• 5th Wave …


HIGH LEVEL SCHEDULE


PROJECT BACKGROUND & LOGISTICS

The following slides outline some of the assumptions, caveats and scope implications for this project. It also outlines, some aspects of progress reporting and tracking.


SCOPE, ASSUMPTIONS AND CONSTRAINTS

• Out of Scope of this decommissioning strategy– This addresses only the sun setting of applications.. The ongoing process of

releases prior to sun setting, is covered under systems Integration plan of action.– Performance and capacity planning will be addressed in the operational

applications standards activity list.– HR and staff plan of actions for transition is handled under systems integrations

or the projects/functional managers.

• The critical success/failure factors (CSF’s/ CFF’s) factor for this include:– Communications, communications, communications– …

• The KPI’s KGI’s are:– <KPI’s>


ASSUMPTIONS:

• The following are some of the assumptions– Individuals from client areas, EA, ITI, IA and Project will be available for decommissioning

activities.– Decommissioning activities/tasks can only be identified and carried out by knowledgeable

existing employees.– Decommissioning activities will continue beyond the Project implementation date for the

corresponding functionality.– Decommissioning plans will be developed by Project release by application (or application

set). Decommissioning will also be coordinated across all applications by Project release.– Decommissioning activities must be coordinated with Project implementation activities.– Some applications may require partial or staged decommissioning. – All data feeds in and out of the application have ceased.– Business functionality has been replaced or eliminated.– Data has been converted, archived in an application-neutral format, or destroyed.– Data required for continuing analysis is available to users.– Audit trails exist to ensure any data transformations can be identified so as to recreate the

original data values.


CONSTRAINTS:

• The implementation schedule (Applications decommissioning) will be managed in the same fashion and principles as the general schedules.

• Hardware, software and data storage available to support access to historic data• Resource availability


APPLICATION RETIREMENT PROJECT WEB SITE


COMMUNICATIONS REQUEST PROCESS


PLANNING MILESTONES

The planning milestones within each “retirement wave” are:– PROJECT CHARTER– PROJECT GOVERNANCE AND COMMUNICATION PLAN (PGCP)– DEPARTMENTAL STAFFING PLAN (DSP)– FISCAL TRANSITION PLAN FTP– APPLICATION MAINTENANCE PRIORITIZATION PLAN AMPP– PROJECT PROCESSES MANAGEMENT PLAN PPMP– INTERFACE MANAGEMENT PLAN IMP– APPLICATION COMPONENT DECOMMISSIONING PLAN ACDP– ASSET MANAGEMENT PLAN AMP– CONTRACTS MANAGEMENT PLAN CMP– RECORDS MANAGEMENT PLAN RMP– MAINFRAME DECOMMISSIONING PLAN MDP– OPERATIONS SHUTDOWN PLAN OSP– COMMUNICATIONS PROCESS PLAN CPP


HIGH LEVEL PROCESS DIAGRAM


KEY TASKS

• There are 5 key management stages associated with the sun setting of applications. They are:– Initiation and Planning– Execution– Migration– Monitor and Control– Closure

• Within the management stages, the major discussions threads include:– Application Decommission– Asset Management– Contract Management– Interface Management– Fiscal Transition– Operations Shutdown– Staffing, and,– Records Management.

• These are outlined in detail later


SYSTEMS DECOMMISSIONING ARTIFACTS

The following will be produced to assist in the overall logistics of the decommissioning efforts.

– SYSTEMS DECOMMISSIONING GUIDEBOOK– SYSTEMS DECOMMISSIONING SCOPE AND GOVERNANCE PLAN OVERVIEW– GOVERNANCE AND COMMUNICATIONS PLAN FOR SYSTEMS

DECOMMISSIONING– CUTOVER ACTIVITIES CHECKLIST REFERENCE GUIDE– SYSTEM DECOMMISSION RECORDS MANAGEMENT OVERVIEW AND

TRANSITION DOCUMENT

• In addition to the above project overview deliverables, the deliverable's for each phase of the decommissioning efforts are illustrated on the following slides.


INITIATION & PLANNING DELIVERABLES

The deliverables for the “Initiation and Planning” activity include the following:– PROJECT CHARTER– INTRODUCTION TO SYSTEMS DECOMMISSIONING WORK PLAN– SYSTEMS DECOMMISSION WORK PLAN SHELL– INTRODUCTORY LETTER TO USER GROUPS– GOVERNANCE AND COMMUNICATIONS PLAN– PLANNING SESSION GROUND RULES– SCOPE AND GOVERNANCE PLAN OVERVIEW– WORKGROUP SCOPE AND PLAN OVERVIEW – SYSTEMS DECOMMISSIONING PLANNING GUIDE.

The templates for each are located on the Systems Integrations retirement web site.


EXECUTION DELIVERABLES

• The following are the deliverables from the “execution” phase.– FUNCTIONAL; AREAS RESOURCE SUPPORT THROUGH SYSTEMS

DECOMMISSIONING– ‘NO LONGER SYSTEMS OF RECORD (SOR)” NOTICE TO CONSTIUITIENTS– “NO LONGER SOR” NOTICE TO INTERFACE PARTNERS– 60 DAY DEACTIVATIONS NOTICE TO INTERFACE PARTNERS– ACQUISITIONS DOCUMENTS ACKNOWLEDGEMENT LETTER– BUDGET DOCUMENTS ACKNOWLEDGEMENT LETTER– CONSULTING SERVICES CONTRACT TERMINATIONS LETTER– MAINTENANCE CONTRACTS TERMINATIONS LETTER– CONTRACT MANAGEMENT MATRIX


MIGRATION DELIVERABLES

• The following lists the the deliverables from the Migration phase:


MONITOR & CONTROL DELIVERABLES

• The following are the deliverables from the Monitor and Control activity:– SYSTEMS DECOMMISSIONING – PERIODIC INTERNAL STATUS REPORT


CLOSURE DELIVERABLES

• The following are the deliverables from the “closing” activity:– RECORDS MANAGEMENT EVALUATIONS AND RECOMMENDATIONS (RMER)– RECORDS MANAGEMENT OVERVIEW AND TRANSITIONS– SYSTEMS DECOMMISSIONING CLOSE-OUT REPORT– OPERATIONS SHUTDOWN PLAN.


ROLES & RESPONSIBILITIES

• The following outlines, the concepts behind each of the roles and responsibilities surrounding applications retirement. In some cases, individuals can wear several hats in the fulfillment of the functions.


WORKING GROUPS TO BE ESTABLISHED

Working Groups that are recommended to be created to support each “wave” include:– Business Administration– Migration (if applicable)– Applications Services– Technical Services– Communications– Contract/Fiscal management– Asset Management– Records Management

• The following chart explains the structure


WORK GROUP DETAILS


SYSTEMS DECOMMISSIONING ORGANIZATIONALCHART (E.G.)


SYSTEMS DECOMMISSIONING PLANNING GUIDE: TABLE OF CONTENTS


RISK AND ISSUES

• The risk and issues will follow the overall approach as outlined by the Project PCO, and specifically the Risk Manager. For more information, please refer to that process (separate Presentation).

• Some of the typical risks and issues associated with initiates of this type include:– Legislative compliance, labour laws, contacts cancellations– Availability of staff currently assigned to legacy financial and human resource

applications for training and new assignments– How to handle security in the interim– Support for systems during the interim


NEXT STEPS & ACTIVITIES

The next steps following general acceptance of this Plan of Action include:– Continue to update “migrations strategy”

• identify interfaces (Current & Future state)• Diagram “waves” and roll-out strategy• Establish CI Dictionary• …

– Validate approach with all constituents– Development of the Systems Integrations Guidebook– Setup templates of all activity deliverables.– Produce, confirm and approval of the Project Charter– Begin preliminary schedule of meetings with the constituents of Wave 1


TIE-IN TO SYSTEMS INTEGRATION

• Stewart & governance• Functions• Requirements• For more information, please review the presentations on SI.


<SYSTEM/APPLICATION> INTERFACES & RELATED APPLICATIONS


DELIVERABLES & ARTIFACTSDETAIL SCHEDULES


Application Component Decommissioning Plan (ACDP)• Identify application components that need to be decommissioned such as: production, testing and

training Regions, business applications, application and system user ID’s, file transmissions, ad-hoc processes, and batch processes. The workgroup will identify decommissioning timeline, the validation criteria and which workgroup or individual is responsible for the activity.

Asset Management Plan (AMP)• Identify all hardware, software, network devices, and non-IT equipment regardless of location or

ownership. Activities include: development and population of an asset management database, inventory and validation of assets, development and implementation of policies and procedures; and disposition of assets (including the decommissioning process).

Application Maintenance Prioritization Plan (AMPP)• The AMPP will assist the Project in determining which requests for changes to the application will

be accepted and which will be rejected during project closure. The plan will include all work efforts (major work orders, minor changes, and small production fixes). The plan will govern all applications. The plan will include additional activities such as software upgrades, existing support end dates, communication outputs and exception criteria.


Contract Management Plan (CMP)• Identify all written agreements with any non- entity for products and/or services (e.g. Unisys,

Oracle, and UPS). Activities include: identification of all contract terms and conditions; understand termination and/or amendment; fiscal impacts, opportunities for ramp-down of services products and licensing; and assess final disposition of contract.

Communications Process Plan (CPP)• Communications development and dissemination includes the creation of the

Communication Plan for gathering and facilitating the information share in a readily accessible and timely fashion. Activities include the definition of the role as single point of contact, process, procedures and development of the format and templates.

Fiscal Transition Plan (FTP)• Identify fiscal and budget components that need to be transitioned / decommissioned

including all expenditure tracking and interface applications. Activities include management and transition of all budgetary actions currently prepared and validated by staff (encumbrance, validation, payment and interface).


Interface Management Plan (IMP)• The Interface Management Plan will include all interfaces, test regions and

decommissioning timeline. Activities will include data retention requirements and internal/external stakeholder communication activities.

Mainframe Decommissioning Plan (MDP)• The Mainframe Decommissioning Plan identifies tasks and responsibilities associated

with the formal shutdown and decommission of the federal-owned mainframe(s) and peripherals currently operating at the corporate Data Center.

Operations Shutdown Plan (OSP)• The Operations Shutdown Plan identifies the tasks and responsibilities associated with

the formal shutdown and decommission of the server infrastructure at corporate facilities and Project Management Office (PMO) computing and network environment. These services include production control operations, servers, network connections and technical processes.


Project Processes Management Plan (PPMP)• Activities will include the evaluation of current processes outlined in the application maintenance,

deliverables management, quality management, and other project policy and procedures to identify changes or tailoring that will be required due to system decommission.

Records Management Plan (RMP)• Identify and disposition all business data and information stored in all forms of media. Activities

include: identification of federal and state regulations regarding retention and disposition; development of plan, policies and procedures; and identification and disposition of data and information. All Intellectual property rights must be reviewed and the proper disposition determined.

Departmental Staffing Plan (DSP)• A collaborative effort coordinated with corporate Human Resources of an approved administrative

plan to address the “roll off” of Departmental employees due to system decommission. Activities will focus on the identification of Office of Systems Integration (OSI)/Departmental Personnel Board (DPB) HR policies and procedures which guide and facilitate the transition of departmental employees and the development of the appropriate communications.


DECOMMISSIONING CHECKLIST (EXAMPLE)


MILESTONES CHART


SCHEDULE


Tuesday, May 2, 2023ECIO EXECUTIVE WORKBENCH

PRESENTERS BACKGROUND

• David Niles ([email protected])– Director, Systems Development

• USA Federal Government Health Care, Washington DC– Director Enterprise Infrastructure

• Sanmina-SCI Contract Manufacturing, San Jose CA, Huntsville AL• Largest Oracle ERP instance in the world… HSV Z series, Superdomes

– Director, Project Control And Service Management• Sanmina-SCI, Chennai India Guadalajara MX• Mergers and Acquisitions, DRP, SOX, GSC, PMO

– Sr. Director Support Services• Burlington Coat Factory, Philadelphia PA • Change Control, GSC, Asset Management, Field Services, Technical Services,

PMO– Program Director, Day 2 Wipro– Special advisor, CIO/COO Macmillan Publishing NYC

Page: 48

mailto:[email protected]

APPENDICES & SUPPORTING INFORMATION


SUPPORTING INFORMATION & CONTRIBUTORS

• IBM Literature• …


TO DO’S FOR FUTURE ADDITIONS

• To do/Action Items– Include RACI chart for overview– Move web site to confluence


PROJECT & <SYSTEM/APPLICATION> TOUCH POINTS


INTERFACES UNDER CONSIDERATION INCLUDE:

• The interfaces to be reviewed for inclusion in the new system are:– <interface touch points>

• The principle contacts and representative ownership is:– IT– Bz identified



TOOLKITS USED IN THE ASSISTANCE FOR COLLECTION OF INFORMATION

• Mindmap• eCIO Executive Workbench

– Toolkit and examples for all facets of the workplace for managers, executives and the individuals contributor

– Leave your card and I’ll get you a copy

Page: 54ECIO EXECUTIVE WORKBENCH


Icons used in this presentation;

As you review this presentations, you will see icons that are designed to call your attention to specific pieces of information. Here they are with descriptions:

When you see this icon, you know you’re about to get helpful tips and practical advice to help

The text next to this icon typically contains important information that helps you stay on track

I use this icon as a red flag. It draws your attention to items that could sidetrack your progress.

This icon highlights technical material, which you can use for further investigation

END OF PRESENTATION

Page: 55ECIO EXECUTIVE WORKBENCH

…

Date post:	11-Apr-2017
Category:	Documents
Upload:	david-niles
View:	1,084 times
Download:	3 times

eCIO PPT Sunsetting strategy v 3 general distribution

Documents