Enron Energy Services
Lead Analyst/Developer, Sales Force Automation/Application Security –
Mar ‘98 to Mar ‘99
Leveraging the street cred I received during the early nineties from developing one of the world’s first collaborative Sales Force Automation systems utilizing distributed database technology for Minet Insurance Services, I landed at Enron Energy Services in the late nineties doing guess what?
Yep, I was developing a Sales Force Automation system utilizing distributed database technology. Someone had built a prototype before I got there. I was brought in to make it a world class, secure enterprise application.
The first order of business was to figure out how to move data back and forth between the distributed collaboration database I was building and the more traditional corporate SQL relational database systems. This is the application type commonly called middleware in an n-tiered system. In the middleware spot is software that knows how to take data from one source and put it in another.
There are middleware tools available to simplify a programmer’s life but sometimes you have to roll your own middleware since the tools can be quite expensive. Fortunately Enron was awah in money and I was able to evaluate several tools and write a report and Enron bought a tool.
Once we had the middleware all figured out, a security matrix had to be developed so the software would actually be suitable for a production environment. Can’t have a detailed breakdown of a company’s best sales prospects just willy-nilly open to anyone with a computer.
The previous consultant who built the prototype failed to take security considerations into account. Do you know how hard it is to implement a comprehensive security structure into a huge database with existing data? The problem is that whatever the final security design turns out to be, it has to be retrofitted to reams of data that have no security whatsoever.
Lot’s of programming, which is good for me, right? You’ll just have to take my word for it–retrofitting complex security into an existing database system is no cakewalk. Security should be an integral part of the initial design.
After smoothing out all the infrastructure issues, I went to work on the software. I think we went through about three development cycles in the time I was at EES. First was the major upgrade to the prototype to make it suitable for an enterprise production environment. Along with the security and middleware all the pent up wants and needs from all the users corporate wide were included.
The 2nd and 3rd development cycles were targeted toward providing better reporting, refining metrics, workflow enhancements and such.
Here is what I did:
- Extensive analysis of data migration tools for connectivity with Notes and SQL Server. Performance measurements were taken from each product working with a very large data set, using a variety of test types.
- Designed and implemented advanced security model into existing, enterprise Sales Force Automation application
- Developed middleware scripts (Notrix Composer) to move Notes data between SQL Server and other ODBC data stores
- Wrote a change request database for the data security officer. The application featured technical reviewers and department approvals based on request type.
- Performed design modifications and fixes for several existing Notes database applications
