With EDS' move from American Express to Business Travel International, America; EDS' customized version of PDQ from American Express needed to be replaced. I led the initial needs analysis, design and implementation of this replacement system. In the end, due to short comings discovered in the American Express PDQ system (that were resolved in the new system), EDS was able to do more reporting that they could not do before.
The environment consisted of: FoxPro and 'C' on Lanyon.

With Bear Stearns' switch to USTravel, they wanted to replace and improve their current Travel Department Automated support system. I led the initial needs analysis, design and implementation of the required enhancements to USTravel's Maestro system to replace Bear Stearns' stand-alone system. The resulting system was more reliable, faster, and included more features than the replaced system.
The environment consisted of: PRE-AC (see below) on Lanyon.

I was asked to contribute to the design of a system that would provide a CRS interface, not just a common communication API (Application Programming Interface), but a system with commonly structured content and commands.
The environment consisted of: Novus.

As part of the data center consolidation project (moving from four accounting centers to one), I led the design, implementation, and operations of the On-Line (CRS) data conversion; both PNRs (Passenger Name Records) and Profiles/STARs (CRS based database used to store information, usually to help build PNRs initially).
The environment consisted of: FoxPro and 'C' on Lanyon.

I Supported the conversion of 22 DATAS (CRS owned by Delta Airlines) offices to WorldSpan (CRS owned by Delta, TWA, & Northwest) by designing, implementing, and operating the conversion and transfer of all the Profiles.
The environment consisted of: 'C' on Lanyon.

With 150 offices, approximately 250,000 profiles and 250,000 PNR's; manual conversion was not a reasonable possibility. I led the design and implementation of the On-Line (CRS) data transfer from Apollo (CRS owned primarily by United) to SABRE (CRS owned by American).
The environment consisted of: 'C' on Lanyon.

With the need to Publish certain databases to five CRSs, and the need to do both small and large systematic changes to large numbers of client profiles/STARs, I was called upon to propose (and subsequently design and implement) a new process with a major automation supported component.
The environment consisted of: FoxPro and 'C' on Lanyon.

The challenge presented was to replace the five CRTs (Cathode Ray Tube - generic for Computer Screen) on each agents desk with a single CRT, and provide common interface and functionality: Keyboard mapping, Screen look, and Scripts (simple automated CRS interaction sequences). In addition the manual record keeping and hand-off for billing was to be replaced with an automated process. I proposed, designed, and implemented a solution.
The environment consisted of: PRE-AC (see below) on Lanyon.

Given that USTravel was forced (at the time) to use both native SABRE APIs and Lanyon APIs (for the other 4 CRSs), this in turn forced all applications to be written for two APIs. The solution I proposed (and designed and managed thru implementation) was to create a new "middle-layer" to present a common API. As part of the project, we also solved three other problems/needs: common "user" interface, dial-in support for all CRSs (for remote users/trade shows/demos), and a CRS dialog recorder and playback engine (to facilitate stand-alone demos and regression testing).
The environment consisted of: 'C' on Lanyon and SABRE APIs.

Working closely with marketing, designed and project managed the creation of a pre-trip customer reporting system. This system was completely integrated into the Maestro system (see below), thereby requiring no additional CRS resources.
The environment consisted of: FoxPro, 'C', and PRE-AC (see below) on Lanyon.

When Maestro (see below) was first created (processing only a few hundred PNRs a day), monitoring and managing it was relatively straight forward. As it grew and was processing thousands and thousands of PNRs a day, monitoring and managing it became very difficult. In addition, at these volumes, certain CRS idiosyncrasies manifested themselves as serious problems. I was asked to come up with a solution. The proposed (and subsequently designed, developed and implemented) solution presented the complete status of the system on one (quickly evaluated) screen. This system also implemented an internal (off CRS) queue system which automatically eliminated all duplicates, and fully prioritized the work.
The environment consisted of: 'C'.

With the AQUA (Automated Quality User Assurance) system sweeping the US Travel Industry, USTravel brought me in to design and implement their competitive response. The result was Maestro, an automated system to quality control PNR's and provide additional services to travelers. Some of the functionality included was: quality control , data collection, lower rate search, seat verification and correction, wait list clearance, automatic frequent flier upgrading, and file finishing. The resulting design consisted of 96% common code across four CRS's, and eventually was processing about 50,000 PNRs a day.
The environment consisted of: PRE-AC (see below) on Lanyon, using distributed cheap PC technology, spread over two physical locations for continuous operation even thru a local natural disaster.

When USTravel decided to create a competitive product to AQUA, and decided that it must be built with Automator Control Language (AC), discussions ensued regarding optimizing the tool kit for the development process. I proposed an approach that required certain features not (at that time) supported by AC. Upon agreement from the USTravel MIS manager, I designed and implemented extensions to AC. These extensions were implemented as a Pre-Compiler to AC (hence PRE-AC).
The environment consisted of: 'C'.