Delta Air Lines

DART (Data Analysis and Reporting Tool) is a system which is used by the Revenue Management team to analyze and review the booking and forecast history data produced by other systems. Data from multiple sources is being collected, merged and loaded into a dimensional model designed for ease of extraction and analysis. It processes approximately 17 million rows of data per day and the final system contains around 50 billion rows.

I was the Senior Developer on the system and was responsible for the initial setup and data loads and the development of the database and stored procedures and have been working directly with representatives from both Microsoft and HP. I also work directly with our Senior Architect and am responsible for the direction and training of two other developers.

The system was developed on a SQL Server 2005 platform using Visual Studio 2005. Most of the system was created using SSIS (SQL Server Integration Services) with some processing tasks being done in VB.Net. User access to the system is through cubes built under SSAS (SQL Server Analysis Services) and a custom interface built using C# using web services.

AirMax Audit Trails and Data Validation Delta recently implemented the AirMax O&D Yield Management system. As part of the acceptance requirements of the system, it was necessary to validate the contents of the system and the results produced by it. Validation involved taking the AirMax outputs and data extracted from the AirMax database and comparing it to data taken from other systems within the company. Corresponding data fields were compared and discrepancies identified. Reports showing the differences were created and sent to the user groups for analysis.

Also, as part of the operation of the AirMax Yield Management system, forecasts and user adjustments are saved and compared to the actual outcome. This data is provided by the system but needs to be archived for later analysis.

Status of the system is reported to the users through a web-based Dashboard.

I was the developer responsible for the validation and audit systems I worked with the system users to determine the necessary comparisons and with various other groups within the company to determine sources of comparison data, such as our Reservations and Data Management groups, and with our Data Warehouse DBAs.

The system was developed and run under UNIX on an HP-UX platform. The system was primarily created using Perl and PL/SQL against an Oracle database.

The Bookings Queue was used by the revenue management system to receive booking information from the reservation system as bookings occurred. These messages had to be interpreted and reformatted before being sent to the revenue management system. A system was created which received the booking messages from the Reservation system and converted them into a standard format before placing them on a queue to be processed by the revenue management system.

I was one of several developers on the system. My portion of the system involved receiving the raw data on an input queue and interpreting it to create a standard booking object. This object was then placed on an output queue that was then read by the system itself. I worked closely with the other developers and the Reservations group to insure that all messages were interpreted correctly and passed in the correct formats.

The system was developed in Java under UNIX on an HP-UX system and used MQ-Series queues. Later, substantially the same system was used to pass scheduling information as well.

Schedule Match: A flight becomes eligible for bookings about a year prior to its departure and we track booking information for that flight through its history. During that time, the identification of that flight (its Flight Number and Departure Time) can and do often change. However, we do not get notification of this. Instead, we simply get the current schedule of all flights each day.

The Schedule Match process compares the previous day’s schedule with the current schedule and determines a mapping between the two. It assigns a unique identifier to each flight that remains constant throughout the life of the flight and makes this identifier available to the downstream systems.

I was the developer for the schedule match system. I worked with the users to come up with the algorithm used to match up the flights as well as the structure of a weighting table the users can use to affect the matching. I also worked with the project DBAs and other developers to ensure consistent use of the unique flight identifier.

The Schedule Match system was initially developed in C++ under Visual Studio then ported to run under UNIX on HP-UX. The system was later rewritten in Java but maintained the same functionality.

Booking Valuation is the system used by Delta to determine the expected revenue from an individual passenger booking based upon multiple factors, including the source of the booking and routing. The system was used to help optimize the number of seats available in the various fare classes.

I was the lead developer on the system. I worked closely with the users to come up with the requirements and the algorithms for the optimization model and with the developers for our reservations system to develop the interface for transferring the results to that system.

Booking Valuation was written in COBOL and ran on both IBM VM/CMS and MVS/XA environments.

ENABLS (the Enhanced Airline Booking Limits System) was an earlier Yield Management system used by Delta. The system was used to forecast passenger demand and booking patterns up to 11 months in advance of the flight departure date as well as the show-up and cancellation rates for those passengers. This was done by tracking historical booking patterns and trends as well as seasonal and market variations. The system used this information to optimize the mix of fares available on all flights in the Delta network and was considered to have an average annual impact on revenue of $600 million.

I was the lead analyst for the ENABLS project. I performed a rewrite of the system that converted it from using individual fare classes for its optimization to one that used the actual revenue contribution of the individual passengers. Once the new system was implemented I remained on the project to oversee maintenance and upgrades. I was responsible for meeting with the users to coordinate upgrades and change requests and to modify the system to respond to changes in market conditions. I also was responsible for directing the activities of up to five other analysts.

ENABLS was written in a mix of FORTRAN, COBOL and Rexx and ran on both IBM VM/CMS and MVS/XA environments.

Southern Company Services

The Outage Analysis Database was a system designed for tracking outages across the transmission network to aid in the allocation of resources for maintenance and system expansion. It collected data from the various operating companies and presented it in a single system to the Transmission Planning group.

I was one of two developers on the system. I worked with the Transmission Planning engineers to determine the requirements of the system and with the engineers at the operating companies to determine data sources and history. I also worked with the DBA group to design and optimize the database used for the analysis.

The initial system was written using the Information database system running on Prime computers. The system was later substantially rewritten and upgraded to run on an IBM RS6000 system against an Oracle database. The system was primarily written in SQL and PL/SQL.

The Wheeling Rates (WRATES) system was used to calculate the costs incurred by the transmission network when transferring power through the Southern Company network between two external utilities. It was used to determine pricing for the service and to support those pricing decisions to the Public Service Commission.

The system was written in Fortran and ran on a Prime computer system.

The Transmission Pricing Database was designed to help track transmission costs throughout the network and was used by the Transmission Planning group to support network optimization and expansion plans.

I was one of three analysts on the project and worked with the users in determining requirements.

The system was written using Dbase IV and ran in the PC environment under DOS.

I also provided maintenance and upgrades to a system used for managing loads and stability of the transmission network.

Energy Management Associates

Energy Management Associates developed, maintained and distributed a system known as Promod (Production Model) which was a modeling and simulation system used by electrical utilities for demand forecasting and modeling. It was the primary system used by utilities both in the US and elsewhere for planning and for supporting those plans to the Public Service Commissions.

I performed multiple roles in support of Promod. I was the primary technical support contact for the installation and execution of the product and was expected to be able to provide assistance to our clients whenever necessary. I was responsible for the configuration and installation of customized software packages on multiple client sites both nationally and internationally.

I also performed maintenance and upgrades on multiple portions of the system, including the forecasting and reliability models. Later, I was part of a smaller team which created an interactive front end for the system.

Promod and its support systems were primarily written in Fortran and Cobol. The system ran under IBM VM/CMS, IBM MVS/XA, Prime, Vax, Unix, IBM PC and Macintosh systems.