Honeywell Aerospace: Decommissioning Process

1. Honeywell Aerospace: Decommissioning Process

2. Agenda • Introductions • Honeywell Overview • Decommission Process & Methodology • Mission & Benefits • Planning • Project Methodology • Project in Process: X67 Mainframe Decommission • Application Inventory & Interfaces • Process & Approach • Data Retention Policies • Data Strategy: Identification, Archival, Back-up & Reporting • Change Management • Vendor Management • Storage Management

3. Introductions • Lisa Nelson, IT Director • 15 years in the IT industry and 7 years with Honeywell • Focused career on managing Application Development and steady state Application support teams • Managed Operational Transformation team with goal to improve effectiveness and improve efficiencies through M&A, decom and strategic project work • Lori Graves, IT Program Manager • 40 years in the IT industry and 27 years with Honeywell • Primarily supported the Engines business by designing, developing, and implementing a host of new mainframe applications • Oversight responsibility for all system interfaces during the Y2K Mitigation effort • Provided IT support services to suppliers and internal organizations in decommissioning many legacy machines including large mainframes

4. Lisa Nelson, IT Director Honeywell Aerospace Run Application Support Honeywell overview

5. Honeywell’s Businesses • $39-39.5B in sales* • Approximately 132,000 employees, 1,300 sites, 70 countries • Morristown, NJ global corporate headquarters *2013 guidance

6. Aerospace Thousands of Honeywell Aerospace products and services are found on virtually every commercial, defense and space aircraft worldwide. The Aerospace business unit develops and integrates technologies that span air traffic modernization, flight and runway safety, engines, cockpit and cabin electronics, connectivity, logistics and more that deliver safe, efficient, productive and comfortable transportation-related experiences. Possibilities of Flight Made Easy

7. About Aerospace Aerospace Facts • Headquartered in Phoenix, Ariz. • Approximately 38,000 employees • Nearly 100 worldwide manufacturing and service sites • Revenue of $12 billion in 2012 STRENGTHS • Global leader in the aviation industry • Developing innovative safety products • Driving modernization of global air traffic management • Revolutionizing combat technology • Committed to improving operational efficiencies SALES $12.0 $11.5 2010 2011 2012 $10.7

8. 3 Customer Facing Organizations Single Point Of Contact For Customer Aligned With Market Verticals Integrated Product Roadmaps Owned By M&PM 84 Product Lines, 10 Product Families Proactive Cost Management Aggressive Indirect Cost Reduction Since 2010 Shared Support Structure Engineering Resources Shared Across Projects, Businesses Single Supply Chain Drives Sourcing And Mfg Efficiencies Centralized Back-Office Functions (Finance, IT, HR) Common Systems (SAP) Support Structure Aerospace Structure Aerospace Air Transport & Regional Business & General Aviation Defense & Space Marketing & ProductManagement Integrated Supply Chain (ISC) Engineering & Technology Customer & ProductSupport (C&PS) Law, Contracts & Export Mergers & Acquisitions (M&A) Human Resources & Communications Finance Information Technology (IT) Business Innovation Center

9. Lisa Nelson, IT Director Honeywell Aerospace Run Application Support Decommission Process overview

10. Decommission Overview • Mission: • To create an enterprise business application portfolio that enables execution of Honeywell Aerospace business strategy in a cost effective way. • Benefits Justification: • Cost Savings • CPU + Tape Mount (Mainframe) • Server Lease & Support • Business Resource Support • Depreciation • Fixed Fee Operation & Maintain Costs • IT Resource Support • Software License & Maintenance • Risk Mitigation • Aged and Incompliant Hardware • Unsupported Software (Application and Database) • Loss of Legacy Application “Tribal Knowledge”

11. Decommission Planning • Approach: • Work with business leaders to identify and prioritize decommission projects based on savings opportunity, SAP deployment schedules or risk exposure.

12. Decommission Project Methodology • Overview: • Application Archive and Decommission (AAD) projects address the unique needs of projects whose objectives are to archive historical data and then decommission the associated software and/or server hardware. • Project Methodology: • The AAD set of processes is based on the Waterfall project management methodology. • The process is broken into 7 key phases, each used on an as needed basis depending on the needs of the project. • Key Factors: • Data archival requirements • Access and reporting requirements • Data restrictions (ITAR, EC) • Records retention standards and guidelines

13. Decommission: Project Methodology

14. Lori Graves, Program Manager Honeywell Aerospace Application Portfolio Management Tempe X67 Mainframe

15. Application Inventory & Interfaces • Overview & Approach: • Reviewed old inventories (15 years). • Scanned old libraries to pull high-level qualifiers based on naming standards. • Went into Programs to identify relationship to data • Setup an Access database to track/document all research • Program, Screen, Database names, cross-references between components • Contacted prior project resources for data on in scope apps & documentation • Watched waterline projects for applications not included in inventory • Challenges: • Old applications (40-50 years old) • Lack of knowledgeable resources within both the Business and IT • Expired or unsupported software and hardware, and lack of monitoring • Best Practice: • Establish a repository to track data elements for application inventory collection • Do shutdown by LPAR to reduce concerns about interfaces between apps • Shift primary focus slightly from applications to databases (i.e., master files)

16. Data Strategy: Data Retention Policies • Overview & Approach: • Identify all retention policies • Corporate / site / department level policies didn’t always align • eDiscovery - Work with Legal to identify legal holds for legacy data • Challenges: • Identify all applicable retention policies & combine into one plan (adhere to most stringent) • Understand the impact of legal hold on timeline • Get requested data provided so legal hold can be lifted • Best Practice: • Centralize retention requirements across the organization • Have a thorough process to address legal hold requirements • Confirm/update retention time frames based on audit requests

17. Data Strategy: Identification • Issues: • Massive inventory of applications (600+ across all LPARs) • Close to ONE MILLION files • Assumptions: • Assumed data storage was cheaper than people • Focused analysis effort on file identification and took everything • Assumed all data on the mainframe machine was export controlled • Allowed us to eliminate significant amount of analysis and data selection • Assumed master data was kept in databases rather than flat files • Allowed us to focus on archiving databases only

18. Data Strategy: Identification • Overview & Approach: • Determine business critical databases • Challenges: • Mapping databases to applications on the application portfolio (inventory) • Identification of application owner for approvals (especially retired applications) • Multiple levels of predecessor applications and orphan data • Best Practice: • Identified databases converted to SAP or other strategic solutions (PDM, TeamCenter, etc) • Identified databases requested by users • Checked billing report to determine heavy screen usage and mapped that back to the databases behind the screen

19. Data Strategy: Archival • Overview & Approach: • Built archival environments early (decoupled from enabling project timelines) • Designed the archival environments based on the old application • Took all data from the database with no data parsing or filtering • Performed initial data load prior to cutover & refreshed data at cutover • Challenges: • Availability of business owners to determine required data • Obtaining enough space to store data • Best Practice: • People are more expensive than storage; opted to take more data than needed

20. Data Strategy: Archival Process & Approach • Overview & Approach: • Approach based on contract to target interim savings • Initially CPU based to eliminate processing time and reduce usage • Contract later shifted to be component based, driving changes in the Decom approach • Challenges: • Changing contract and unclear landscape • Shifting dates for enabling projects • Best Practice: • Good project tracking and awareness • Decouple the decom project from the enabling project • Complete builds ahead of the enabling projects

21. Data Strategy: Archival Process & Approach Stage 1 DisableSystems Archive Critical Data Create Fail-Safe Backups Shut Down Legacy • Batch jobs are turned off • Online screens are moved to view-only mode

22. Data Strategy: Archival Process & Approach • STAGE 1 STAGE 2STAGE 3STAGE 4 Disable Systems Archive Critical Data Shut Down Legacy • Meet with users and identify key data to be archived • Key data is extracted from legacy and archived to Oracle databases • All archived data includes full databases (ie. all record types, all years, all fields)

23. Data Strategy: Archival Process & Approach • STAGE 1 STAGE 2STAGE 3 Disable Systems Archive Critical Data Create Fail-Safe Backups Two levels of backups are provided in order to protect the company from the risk associated with loss of data: Tier-2 = Selected data backed up on server for long-term protection Tier-3 = All data from early archives backed up on mainframe tape for added short-term protection (discontinued for 2014 archives)

24. Data Strategy: Archival Process & Approach • STAGE 1 STAGE 2 STAGE 3 STAGE 4 Disable Systems Archive Critical Data Create Fail-Safe Backups Shut Down Legacy • Obtain user signoff on data archival and authorization to Decom • legacy environment • Shut down applications if possible; if not, monitor for rogue access • Once all applications on an LPAR are archived and disabled: • Get approval from Champions & Legal to shut down LPAR & purge • Tapes ejected, data purged & LPAR taken down • Tapes put into pipeline for physical destruction

25. Data Strategy: Back-Up • Overview & Approach: • 3 tiered data back-up approach (detail on next slide) • Challenges: • Issues with data conversion may not be discovered until Mainframe is retired • Conversion of bad characters from mainframe to server format requires manual intervention • Misidentification of a critical database • Best Practice: • Ensure all databases are backed up • Back-up the program and source libraries • Back-up the data in original Mainframe format for duration of project on databases archived early in the project. (This approach discontinued in January of 2014 due to optimization of conversion programs and estimated time remaining until shutdown.)

26. Data Strategy: Back-Up Tier-1 – Critical data needed for historical inquiry. Loaded to Oracle tables and accessed thru Business Objects reports or ad-hoc queries. Oracle Databases Archived • Tier-2 – Non critical data backed up to server • storage as a fail-safe measure. • Long-term record retention • Longer recovery time; convert if needed • Includes DBs not archived to Oracle Fail-Safe Back-Up (FSBU) Text file format on server • Tier-3– All Tier-1 & Tier-2 data backed up • to MF tape; fast retrieval • during remaining life of MF • Short-term protection • Faster recovery time if needed • (discontinued for 2014 archives) Tier-3 Mainframe Backup Lives until record retention expiration or mainframe lights-out

27. Data Strategy: Reporting • Overview & Approach: • Limited requirements gathering with users (provided screen/report samples) • Used billing files to identify heavy usage reports, screens and end users • Built the reports to mimic legacy screens and reports • Rolled out production reports with production data in training sessions combining UAT and Training • Provided hands-on/unlimited training to ensure end users were comfortable • Challenges: • Reverse-engineering the report samples and screen shots • Competition with enabling projects for resources to provide report samples/screen shots and attend UAT/training • Best Practice: • Minimize end user involvement by: • Building requirements from screen prints and report examples • Combining UAT and Training

28. Change Management • Overview & Approach: • Early shutdown of low-risk legacy applications allowed technical team to constrain “size” of mainframe machine • Decom approach was based on contract terms to maximize interim savings • Initial approach CPU based to eliminate processing time and reduce usage • New component-based contract forced mid-stream correction to focus on LPAR and data storage elimination. • Challenges: • Changing contract and unclear landscape • Shifting dates for enabling projects • Large under-used machine driving huge software licensing renewal fees • Best Practice: • Good project tracking and awareness • Decouple Decom from enabling project by completing builds ahead of cutover • Use lack of technical resource availability as leverage to negotiate more favorable shutdown process and billing reductions • Constrain “size” of machine to reduce software licensing fees

29. Vendor Management • Overview & Approach: • Provided vendor with a separate bucket of money to manage non-contractual activities in support of mainframe decom; requires constant oversight • Challenges: • Limited technical resource expertise and availability on old hardware • Failing hardware requires frequent disk replacement to keep machine operating • Lack of future business makes vendor less motivated to compromise • Mid-stream move to break up vendor contract and bid out components created confusion over who does what and reduced original vendor’s motivation to compromise • Best Practice: • Constant review of contract terms to ensure vendor responsibilities are not misstated • Monthly review of vendor invoicing to ensure savings are reflected in billing • Negotiating with vendor to optimize interim disk upgrade solution

30. Storage Management • Overview & Approach: • Identify tapes, files, volumes for each LPAR before shutdown • Take LPAR offline but leave disk & virtual data in place until machine shutdown • Destroy physical tapes at shutdown to maximize cost savings • Challenges: • Massive amounts of very old data, some > 40 years old • Multiple storage mediums/locations (disk/tape, virtual/physical, on-site/Iron Mtn) • Limited technical expertise with wiping components such as virtual tapes • Lack of availability of IBM storage management resources • Cost of utilizing IBM resources to perform cleanup activities • Best Practice: • Negotiate process with IBM to minimize use of human resources: • Soft LPAR shut-down to reduce risk but allow support cost reduction • Leave disk/virtual data in place but inaccessible until machine is shut down • Recall all Iron Mountain tapes at LPAR shutdown & submit for destruction • Destroy all physical tapes (on-site) at LPAR shutdown

31. Thank you! Q&A