The reverse angle of "Siebel and spring.net" and the steps of using Siebel

The reverse angle of "Siebel and spring.net" and the steps of using Siebel


When I say "Siebel and spring.net", I mostly mean to use spring.net to mimic Siebel. Here, Siebel is the "big brother", the "role model".

However, it is not that simple. I do not want to lose my C# or Java or VB skills.

In a sense, it is similar as I keep refreshing my C/C++ skills, periodically.

However, it is also very different, quantitative difference: C#, java, VB are still extremely useful for application development, while C/C++ are less useful for direct applications nowadays; however, they are useful, for understanding OS, and systems like Siebel (you may say an application level OS).

Without spring level of C# or java understanding, or directly C/C++ level -- they call it engineering level -- of understanding of Siebel itself, you will never really understand Siebel.

This is not just a theoretical bias: Siebel will be merged with/into Fusion -- without knowing Fusion or spring.net-like frameworks, you simply cannot understand new versions of Siebel easily and quickly.

Conclusion: you need to know spring.net (or spring itself, and OR mapping, and Ajax), in order to understand Siebel quickly and thoroughly.

It is important to note that plain C#/Java/VB simply does not cut it. You must know frameworks, OR mappings, AOP, databinding, Ajax. etc.

Hence, "Siebel and Spring.net", two sides, both are crucial.

A conclusion for practice: to use Siebel, there are three steps:
(i) immediately set up a usable system, using out-of-box features;

(ii) while (power) users are experimenting the system, you must do some second round of "requirement discovery and design". Because you need to find the features within Siebel, so, when use Siebel, at this stage, the key is NOT talking to users, it is letting users to experiment with Siebel, and you experiment it also, and read all documents, and and try to create a small (a few screens) but "deep" configured module. "Deep" does not mean heavy scripting, it means it includes all key powerful features (including scripting, but again, it does not need to be scripting heavy; but it should include using export to copy/paste some work!) . Again, the key is to get a small but "deeply configured" model done, while users are experimenting.

(iii) users are asking for some features that can be easily done; users also ask for some features that need "deep configuration". Negotiate a little (because Siebel must have a reason not doing that way! Perhaps the business process that Siebel suggests is a better way!). Then, prioritize, and use the deeply configured one as an example, implement more modules.

Obviously, step (ii) is crucial; and to do it right and quick, you need to know spring.net ;-)