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.

Atlassian's Low Price Model

Mike Cannon-Brooks explains Atlassian's pricing model, which makes a good sense to me.

The Future of Spreadsheet

The spreadsheet was a significant innovation of its time. Its popularity is the undisputed testimony of its success. However, we techies know it brings us unspeakable pain when we help people scale a spreadsheet beyond its limitations using a database.

I have been thinking about how to solve this problem. Today there is a post discussing this exact topic. Patrick Logan's comment is what I agree with 100%:

There is a spectrum of choices between a traditional spreadsheet and a traditional database. Perhaps a more usable system in this space would allow someone to begin working more like a spreadsheet and allow shapes to emerge and be supported more like a database, but not expose that support in traditional database terms. The support for those shapes should be more identifiable by the end user programmer without a 20th century software education.

In Concourse, I believe we will support two most important data types in blogs: paragraphs and tables. As you can guess, paragraphs are for Word users and tables for Excel. Certainly you can mix and match them freely. Users should be able to start from a simple table and scale up to a complex data model complete with relationships, foreign keys, indexes, etc. and yet they should not be forced to learn RDBMS terms. If we can do this, I think we have a killer already.

Siebel Training, Day 2

Just completed Day 2 of Siebel Essentials. The more I learn it, the more I think Siebel has figured out a great way to break down the user facing complexity of typical Enterprise applications. The few UI constructs that users see, screen, view, applet, control, etc., cover all the user interface. It is a little boring but a great reduction of complexity on the other hand. I like their UI very much because of its effectiveness: I can get my jobs done very easily and quickly. There are almost no surprise as to how things actually work. I learned a lot from them.

What does Siebel have to do with us?

1. It's a great test bed of what UI features work well.
2. It validates our framework. If our framework can implement Siebel features in a straightforward manner, we've got scaleability (in terms of implementing complexity) nailed. Indeed, I already found some of the Siebel concepts correspond directly to the concept of implementation variant in Cornerstone. But ours is simpler and more powerful. So Siebel is on the high end to validate how far we can go with Cornerstone. On the opposite end, we want to make it dead simple for people to maintain, for example, a table (spreadsheet) of data. In the middle is the sweet spot, the thousands of components and modules that can be easily composed together to build a customer application, like the Siebel (or any other) apps broken down and built by millions of people on the web. This is the vision of world-wide composition, also known as the vision of AppWiki.
   

Why does this make sense? One angle is this: the entry barrier for Siebel type of applications is sky-high. No SMEs (small or medium sized enterprise) can get on their bandwagon easily. They don't need all the features either. Also it's very hard for them to switch later on or mix and match. The AppWiki vision says, don't implement the whole thing, but start from maintaining a list of contacts and grow that into an SFA application.

Can this be done? My belief is, it's possible if we start low and scale up gradually: We make people gravitate towards Confluence, and then better Confluence, and ever better Confluence. The users are not only users, but many of them will become developers because it's so easy to add new features and compose new services from other people's existing services. Before long this thing grows organically and there is no stopping of it. Just like how del.icio.us grew, how Flickr grew, how Technorati grew. We want to get into the business of rolling a snow ball that can sustain itself.

Dream off.