Change Siebel Tools

Alexander Hansal covered a recent enhancement to the Siebel Tools - the code editor can display the line numbers and make code blocks collapsible. Though anyone saying he loves coding in Siebel deserves to be shot and drowned, I do welcome any *change* to the status quo that can improve the life of Siebel developers.

In response Oli siebel-tech.com makes some excellent points on how he would like to see improvements in Siebel Tools . Oli does some straight-talking about where Tools does not live up to expectation, and wants more features -

• Improve workflow editor
• Improve debugger
• Make tools the ONE IDE that we can all refer to and use

All really good points, and points that long time Siebel developers would love to see. But, I for one disagree with the concept of Siebel Tools as it stands today.

Siebel technology is proven but old. As with other such technologies Tools was designed to enable developers create stuff, and also played a secondary (albeit important) role to “compile” those changes. For an application like Siebel that does not find any implementation without customization, the company could afford to charge a premium for Tools licenses. For someone who prides on business enablement and results, it was strange to see a hefty premium charged for Tools, and for the rights to use the end application.

The idea of Siebel Tools and what it should do should change.

It should start with the most bothersome “feature” for Siebel deployment - SRF. With technologies available today the need to compile should be eliminated. Whatever can be done for a CRM application (and beyond) can be easily done using some or the other web technology. Of course you can do that even with Tools, but it is easier for maintenance when you piggy back on a a browser.

Next comes the embracing of open standards.

Take an example of the Groovy usage in Oracle Sales Cloud . Just to get the Groovy editor to show color coding took more than 7 major releases. While everyone agrees that priority to enable capabilities for business comes first, developers need not suffer while a behemoth like Oracle tries to prioritize things. It is easier to use an existing technology framework to enable development capabilities. We have seen this in the way force.com IDE uses Eclipse (although nowhere being near to being powerful).

The idea is to make things easier to understand and transparent to developers. force.com, for one, makes the metadata structure using XML. You can use whatever rocks your boat to develop those XMLs (no one typically does that, but the idea will take off as the application become more complex).

The development tools can enable development of each and every component used by Siebel, but should have the flexibility to allow developers to plugin stuff using external tools. I would like to see the following a renewed focus for following in Siebel Tools -

• Easier development of all components
• Ability to debug *any* component, and faster debugging enablers
• Easy and reliable deployment of all components

Which pretty much covers everything any tool should be doing. Easier said, than done.

And oh, the obligatory statement for any old Siebel developer - workflow development was a breeze before it moved to Tools 🙂