| About My Work | 1 | 2 | 3 | 4 | 5 | 6 |
In the "old days" (read: up until now), in order to install Oracle Applications, you had to install each and every one of the pieces of the technology stack one at a time. Then you had to create a database and populate it with all the underlying financial data. If you were upgrading, the program had to go through each and every one of the thousands of tables in your database and migrate the data from the old data model (format) to the new one. This upgrade process could require several days to run, and the entire process from start to finish often took many weeks — even months, if you include the time necessary to migrate the vast amounts of "customized" code each customer has, since every company has its own unique ways of operating.
I started in Technical Support answering questions on the installation and configuration of the software. Although it sounds like a peon job, it required us to know initimate details about all of the products that were part of our technology stack, and about all of the operating systems we supported. In less than a year, I learned the unique difference among dozens of UNIX operating systems, how to install and use more than half a dozen Oracle products, and how to administer UNIX machines. We weren't supposed to be system administrators, but our product was so large and complex, the main data center was unequipped to maintain environments for us to test problems in, so we did it ourselves. By doing it all ourselves, it certainly made it a little easier for us to solve many of the customer's complex problems.
I can't imagine any job that would have taught me more about database and operating system installation, tuning, and configuration in so short a time. Fortunately, my experience as a Teaching Assistant in college made me an ideal candidate to help pass on a lot of that learning through organized training classes, which I did quite a bit of in my second year. (After a year or two, answering phones — even in an environment as challenging as this — can get very old.) As I was doing this, I became more involved in versions of our product before they were released (so I could train people in advance), and while experimenting with those releases, I tended to find a lot of major issues that non-customer-facing developers would often overlook. In time, my boss worked with me to start up a pre-release testing group called the Systems Assurance Group to catch these types of problems ahead of time. We performed sanity tests on the installation and upgrade of our product just before release, and would send it back if any were found. One of the only good moves ever done by senior management at Oracle was to empower our division to even delay the release if we really had to due to critical problems. (We did once. It was kind of a nice power boost. :-) )