Deep inside Siebel

For the past few days, I’ve been rummaging around in the innards of our Siebel system. Except for minor maintenance, I haven’t worked in this code for about two years–so part of the current effort is budgeted to re-learning stuff I’ve worked on no more than once or twice, 24 months later. The immediate project links a Microsoft Access database to the system. We’ll want to move the table into Siebel some day, but our current license arrangements don’t permit that. We have other, similar, connections already; since I designed and helped implement them, I’m not doing this totally blind. I told Mindy (same Mindy as in Second Action Team) that this effort would take two weeks, and I’m about on schedule. I’ll deliver the test version tomorrow.

There’s something wonderful about the Siebel architecture. I’m pretty sure I don’t like Tom Siebel, and I’m generally hostile about his sales staff, but the product he sells is a delightful place to go (yes, I think of programming environments that way). Siebel Tools is a marvelous construction, both complicated and obvious; remarkably well thought out and well laid out. While the design approach is unexpected and very complex, the execution of the design is simply sweet. The application’s several layers deep, and contains thousands of objects, but once you get oriented the organization is obvious and identifying/locating the piece you need is rarely difficult. It helps, though, to leave a bread-crumb trail, ’cause you can get lost in there.


I began with an analysis of the database we’re attaching. I can recognize a half-dozen programmer’s fingerprints, including mine, on what began as a dBase III application. I figured out what I thought we should do, got buy-offs from the interested parties, and started searching Siebel for the pieces I needed to copy, to modify, to keep my eye on. Since this specific connection will resemble one we built for the initial implementation, I copied about a dozen components, then began making appropriate modifications. This entire process took about six workdays.

Monday morning I dived into a black hole. I’d completed the new interface (what Siebel calls a View), but I’d not be able to display it until I connected it to the data source. Building that connection was Monday’s planned task. This isn’t hard stuff, but many pieces needed modifications and I’d not see the result of any mod until I completed the whole set. My first effort didn’t work, and the error message basically reported failure without any clue about the cause. Not a pretty sight, and not many leads for further work.

While much of Tuesday was devoted to another issue, by the end of the day I had a better error message. According to Siebel, “The external source for this BusComp does not support the field ‘ReturnedTo'”–utter nonsense, actually, but at least a clue about the problem. Spent yesterday trying to pin that down–looked in Siebel’s knowledge base, consulted IT ToolBox’s Siebel forum, and planted markers in the code. By day’s end I’d generated another irrelevant error message, and finally persuaded Siebel to draw the screen, albeit with bad data.

Began this morning by checking the data being passed within the app. I immediately found an error there, and repaired that. That led me on a trek through the database connection, where I found a major error: I’d built an ODBC connection to a different copy of the database than I recalled. Easily fixed, once I recognized the error. By noon I had a working app, and about two hours’ cleanup work to do. An afternoon meeting kept me from finishing that up, but it won’t take long to complete in the morning. I’ll pass a copy to Dale; assuming he likes it, the staff will get it Monday or Tuesday.

The connection mistake occurred mostly because I built it two weeks before I tried to use it, and had forgotten the details. These errors are pretty common, in my experience–when a programmer can’t solve something which looks to be simple, it’s usually because she made an equally simple mistake and haven’t recognized it yet. Fixed now; get on with it.


Tuesday’s issue deserves some comment. Every now and then we can predict a workload peak at our call center. We are implementing recent legislation which inflicted fairly substantial penalties on some Michigan residents. Those citizens received mail notifications over the weekend, which we expected to generate telephone calls. Mindy asked me to modify Siebel to facilitate tracking those calls. Dale (who works for Mindy) and I (I don’t work for Mindy) implemented this by adding a category to the standard list the center uses for classifying calls; although some slight changes were made to the VB code, it wasn’t complicated stuff. We made that change on Friday. On Monday, one of the supervisors pointed out the need for a similar change elsewhere in the system.

Friday’s change had an unintended side effect. Due to a misunderstanding with the network staff, we had lost the development base for the final system prepared by the implementation team. This forced us to build the new modification on a version saved about three weeks earlier. This version wasn’t very different from the final one, but the backtrack cost us about three weeks worth of design cleanup and interface tweaks. Naturally the staff noticed. Next week, I imagine, I’ll be repairing that damage….


One last comment. I’m a very good programmer, and enjoy doing occasional coding projects, but extended programming gigs make me a crazy person. The very focused persona I wear while writing and debugging code is self-centered and unfriendly, and I don’t much like that person. That’s why I stay with the business side of our enterprise, despite occasional invitations to move to IT.