Siebel CRM: technical and process

Siebel CRM: technical and process

A. Technical:

1. ActiveX, instead of Ajax: Siebel CRM (8.0) is web based. It does not use Ajax, instead, it uses two modes, one is "high interactive" mode, which uses ActiveX; another one is for non-IE clients, uses "standard mode", which uses pre-ajax stuff. It is said that it used java applet before activeX (that is why those ActiveXs are still called "applet" in Siebel), then, because java was too slow, so, java was replaced by ActiveX. Obviously, it is a wrong decision that ajax is not used.

2. Siebel UI is a little bit less intuitive than ordinary web or window applications. However, by doing this, it enables its UIs to be generic enough to handle complex situations systematically.
(i) For example, it uses command menus, instead of command buttons.
(ii) Also, it uses a pattern: select a node on the left-side-tree-view, to get the right-side-list-view, then, select a row on the right-side-list, then, select a child node on the left-side-tree (usually, this step should happen on the right-side, by a child list), then, the right-side will have a child list to show the content of the child node.
(iii) Another example is that all UIs are always made of two "applets" (that is, in addition to the tree): "list" (i.e., grid), "form" (many label+text boxes/drop down menus) , plus some tabs or links (category tabs, view tabs, and screen tabs) -- you can put the list "applet" on top, then, this is the "aggregate view" style (users are familiar with this view; because they are used in all ordinary web sites); you can also put the form "applet" on top, then, it is the "detailed view" -- however, in this situation, this view is counter-intuitive, because most users expect to see a three-tier view: the grand-parent at the top, then, the parent, then, the grand-children.
(iv) Also, in the "high interactive" mode, it uses in-place editing, and uses in-place editing-like style to do searching. In ordinary web application, editing uses the form "applet"; further, searching also uses the form "applet".

Those things are not intuitive, further, some are not necessary -- not using them can make Siebel UIs more intuitive and still be generic -- however, as a whole, they are good enough, and they make the following "mapping" possible:

"applet" -- entity objects (in Siebel, entities are called "business components")
"view" -- facade objects (in Siebel, facades are called "business objects")

3. Siebel facades are in a proprietary application server. Actually, its UIs are also in the app server. The generic "web server" is still used though, mostly for load balancing. As a result, for integration, web service is used to get data from those facades.

4. Another surprise about Siebel is that its database does not even enforce FKs. FK are enforced in its facades and entities.


Some thoughts:

On the one hand, after understanding the details of Siebel, I appreciate more about the statement that in the world of lightweight (i.e., no entity bean, but OR mapping) java and .net, Siebel is too expensive for its value. As long as you have an experienced team lead (or architect) so that you know how to say no to unreasonable non-essential UI features and know how to use OR mapping, systematic Ajax with databinding, centralized security and logging (and transaction and networking), and validation, then, the difference between creating your own application and configuring Siebel is not that big.

On the other hand, I do see the value of saying no to unreasonable non-essential UI features, and OR mapping, systematic Ajax with databinding, centralized security and logging (and transaction and networking), and validation. If you can do those things right and fast, then, it is worth millions!


B. Process:

Siebel 's success also points out that it is important to have a working prototype. This is the major advantage of on-shelf software. For an enterprise level application that usually will take two or three years, you can demo a prototype immediately, and then put it to user's hands within a few weeks or a few months.

However, it is amazing to hear that you need produce large amount of documents before implementing Siebel. I do not believe it. I believe it is crap. The key of using Siebel is to do some preliminary research (and "requirement gathering) to decide to use Siebel, then, use a few weeks to set it up and use it. Then, fine tune it, configure it, and even customized it. Of course, we need to document along the process; however, heavy weight upfront documentation without letting users try Siebel out is simply wrong.