When trouble means trouble

Here I go again, this is my second blog entry but this time I am blogging via James’s BottomFeeder which supposedly guarantees safe passage, we shall see.

Hurricane Frances was of special concern to me since I have family in both Miami and Ft. Lauderdale and know first hand from Hurricane Andrew how destructive these things can be. Additionally, it was of interest to me because Florida Power and Light is my alma mater. It was in those halls that I was introduced to Smalltalk. I imagine that every utility company in the country must have a trouble management system but I think that we can all agree that when FPL prepares for trouble that they are living at an entirely different level than most other utilities. Trouble management usually entails at least two systems. A call center customer service system and a specific trouble management system. Both of these systems were partially to entirely written in Smalltalk. The Call Center systems was a modernization of a “green’ screen system. It was interesting because it was generic framework that provided for CICS output to be streamed out to the client where it was marshalled into objects. It provided value because data associated with the respective screens was aggregated reducing user navigation, etc. I was one of the principal developers of the Smalltalk client piece. The trouble management system was largely written in Smalltalk and it employed Gemstone as its database. Gemstone for those not familiar with it is , a cross between an app server and an OODMS. Rather, it basically does both.

This past May, a colleague from my FPL days stopped by to visit me on his way to his cousin’s wedding. I was pleased to know that the call center systems I had helped build were still standing and so was the trouble call management system among others. I am glad that so far those systems have weathered the Java marketing hype hurricane