From CMS and Siebel to AppWiki

Francis said: One of the reply is really interesting to us (referring to this article on TSS):

There's a huge number of Java Portal/CMS systems but relatively few good portlets. Once again, Java people turn out to be masters of infrastructure code but generally hate creating applications on top of it. The portlet spec should in theory have lead to a broad choice of pluggable services. So far, it has not.

This is a very interesting discussion. I have been thinking about the PHP phenomenum. It is indeed better in many ways than Java but worse in others. Personally I don't quite like the language. But the huge popularity tells us:

1. There is a need for scripting, the easy to learn and use alternative to Java.
2. People just want to get things done quickly with adequate performance. Java turns out to be too complicated in most cases (both the language and deployment).

After two weeks of Siebel training (I have one more to go), I have realized more and more why we are led to learn Siebel. Here is why:

1. Siebel has great technology. We are pretty much looking at one possibility of how Cornestone can turn out to be after years of maturing. We have the lower level abstractions such as actions, services, beans, factories, etc., which are a great first step. But there is a long way to go to move up the abstraction pyramid. Siebel has a lot more such abstractions in the higher levels. Siebel is a system live and kicking that shows us what works well and what not.
2. Siebel UI uses ActiveX and is not cross browser yet. They are working on an AJAX version. It is a great testimony of how AJAX improves usability for a sophisticated enterpriese application.
   
3. Siebel is implemented in C++. Customization can be done in JavaScript. But what they recommend is configuration only, which doesn't even involve scripting. This is possible most of the time. So Siebel is already a real life example of providing different levels of customizability using different languages.
   
4. Siebel has problems, not unique to itself but common among all Enterprise application software providers: they have a closed system. If you want to extend it, you have to extend within the Siebel universe, which I believe has a cost model of high charge per seat.

What do all of these have to do with us? I think we probably need to do the following:

1. Find a set of low level abstractions in Cornerstone (such as actions, services, templates, beans, factories, etc.) and provide Eclipse plugins to help build higher level abstractions (such as portlets, views, business rules, jobs, etc.).
2. Find a set of higher level abstractions which can be built, customized, composed using either Java or JavaScript (or maybe other scripting languages).
3. Provide support for building applications using the runtime UI itself (as opposed to using Eclipse at build-time). Most of the time this process should only involve configuration. The rest of the time this can involve scripting. Experienced developer can still use Java to provide fundamental enhancements.

To summarize, our direction is the same. Siebel provides many data points for making good decisions. We want to build a scaleable application platform. It can scale from a simple Wiki type of content site all the way to sophisticated enterprise applications. We probably want to focus on the middle where most of the users and developers are: the long tail of small to medium sized custom applications done by not so professional developers.