Friday, March 6, 2009

Free Facebook Platform Application - Personal Expenses

We are releasing our first Facebook Platform Application - Personal Expenses today. Exciting! We are going to tap into the most popular social network as part of our ecosystem now.

This is a very simple application, keep tracking of your personal expenses, but it can be very useful in this trouble time. It can be used as the tool for the "China's young opt for 100 yuan a week budgets", where I got the idea from when we started building this first Facebook Platform Application.

The Facebook widget was developed in PHP using iframe approach interacting with the Personal Expenses application in Ubikwiti. As Ubikwiti is SOA compliant, the interaction is in standard web service approach. In Ubikwiti, the Personal Expenses application is 100% definition-based like other Ubikwiti applications that we developed in the past.

The Facebook widget merely just an add-on user interface to the standard Ubikwiti application. Means, user can create and use the same Personal Expenses application in Ubikwiti without touching the Facebook widget at all.

To make the platform more flexible and expandable, we created a common gateway in PHP to consolidate all Facebook widget service requests/responds and channel to Ubikwiti in SOAP/web service. This will allow us to build widget for other platforms such as MySpace, Google Open Social, WebEx Connect much easier. Another extend of loosely-couple design.

The project proven again how powerful our Definition-based Dynamic Engine (DDE) is. Let me try to illustrate it here with the use case of Facebook user record an expense transaction,
  1. Facebook widget AJAX the PHP gateway with user entered data
  2. PHP gateway converts the user data to a XML, and SOAP to Ubikwiti web service
  3. DDE instantiates the Record Expenses business component from definition file (XML)
  4. DDE converts the XML to DTO (Data Transfer Object) and pass to the Record Expenses object
  5. Record Expenses object execute the business process defined in the definition file
  6. DDE responds to PHP gateway in turn to the Facebook widget on the result
  7. Facebook widget uses the same channel to get the "My latest 3 records" and "My balance"
If you can see what I tried to illustrate and followed my previous postings, you should be able to realize that the Facebook user can sign-in to Ubikwiti and change the business rules/processes using the DIY-GUI tool as all the business components are just definition file. Also the user can add more components to the application from the U-KwikShop if needed.

Isn't this brilliant?

Monday, February 23, 2009

Coghead R.I.P - Sad but expected

Sad to read the news from InformationWeek about

SAP Buys Cloud Computing Startup Coghead

"Coghead's service continues through April, but SAP will shut customer obligations and relationships down after that. "

One of the high profile players in the dynamic business application platform is quitting soon. Even though this is a unfortunate case, but I think this is hard to avoid for Coghead base on my comments to our Strategy Committee in middle of last year below,

Coghead has very high profile, but very lousy result I would say. They spent 5 years (since May 2003) with big support to reach this stage which is still far to what the CEO is saying, "tech-savvy business people who have never before had access to an easy-to-use, do-it-yourself solution to their application needs. ", as compare to what we have achieved in less than 6 months time with such a limited resources.

I tried to create a simple checkbook application from scratch. The user experience was lousy. The tool looks good in demo, but when put my hands on it, it is not as shown.

The Form Editor tool was not easy to use, even simple task like resize the fields and reposition them as I want using mouse. You cannot use mouse to resize, but have to manually type in the width in a field hide behind the Widget tab. After changed the width, I tried to reposition 2 fields side by side, but the system rejected it and reverted the field size that I have changed to original size. After few tries, still cannot put my Account Type and Account Number fields side-by-side.

They use BPEL for the Action and process flow, which is a good thing, but the tool again is not easy to use. I can't figure out how to do a simple business rule like negative value check. When I made mistake, it just prompted me the system error and didn't suggest me what's wrong with my Action. I don't think business user can use this tool.

Finally, save the Action, and tried to create a new record to save, and I got this message.



At the end, I can't even complete a Bank account setup screen.

In short, they are not ready or even close to develop software or application development tool for business user.

Wednesday, February 18, 2009

We developed and released 4 applications in 1 week time

How fast can a team of 7 develop 4 real world business applications? With Ubikwiti, the answer is one week. We developed around 17 new business components (mostly customized from existing components for different industry or usage) and configured them into 4 different applications (we call them as templates, on top of the Product & Services that we released as an alternative to QuickBooks Online Basic),



  • Accounting for Professional Consultant

  • Simple Cash Management for small business

  • Personal Cash Management

  • <name not disclosed due to marketing reason>


What development processes have we covered in this one week time? We have done,



  • Create business scenario

  • Define business processes

  • Define related new components

  • Configure new applications from the components

  • Unit testing

  • Overall User Testing

  • Publish to live server in Amazon.com

  • End user simulation testing


The declarative application development concept, Definition-based Dynamic Engine (DDE), and our business components store (U-KwikShop) is really working! By the way, the team of 7 I mentioned here were 5 business modelers and 2 application designers. No software engineer got involved.




Tuesday, February 10, 2009

QuickBooks Online on iPhone - my impression


After I have setup my Quickbooks Online, I tried to access it via my iPhone (https://accounting.quickbooks.com/m) as stated in the System Requirement from my previous post. 

My initial impression of the iPhone web app was good and with high expectation, but end up with disappointment as this is only a very basic read-only app. In my mind that this is a iPhone web app, not a native app, which means you must be online to access this app, and also means that you are accessing the live database at that time. I can't add or modify any of the master (bank, customer, vendor, employee), and transaction records (Who Owes Me, Who I Owe). I can understand the synchronization issues of the native app, but I cannot understand why these basic features are missing from the web app.

At least one thing meet my expectation, i.e. when tap on the customer phone number, it prompted whether I want to make a call to the number or not.

Looking forward to a more usable version of QuickBooks Online for iPhone.

Monday, February 9, 2009

QuickBooks Online - only support Windows platform with Internet Explorer


I saw that Intuit has just released a free edition of QuickBooks Online, i.e. QuickBooks Online Free. When I tried to sign up using Safari in my lovely MacBook, I got this. 

Obviously, the QuickBooks Online is tied to Microsoft technology, i.e. ActiveX. Fortunately, I have VMware Fusion with Windows XP and IE7 installed and I managed to sign up.

I can't stop to think about why Intuit decided to tied with Microsoft technology to limit their market penetration, especially the IE market share has dropped to 67% and still dropping. Will other web browsers going to support ActiveX in the future? I don't think so. 

Since this didn't make any logical sense to me, I think the technology used in QuickBooks Online is an art.

Wednesday, February 4, 2009

App Store for Composite Business Application

I like to see iPhone as the application container with some basic modules/functions (the embedded apps like MobileMail, MobileSafari), and apps in the iTunes App Store are like additional modules/functions that can be added to the application container to form a composite application that is tailor-made for that particular user.

The Ubikwiti and U-KwikShop were developed based on the same principle, i.e. the 
Ubikwiti is the application container running within the Definition-based Dynamic Engine (DDE) framework, and the additional business components (modules/functions) can be added to the application from the U-KwikShop (App Store) any time to tailor make the business application for that particular user or business. 

Similar to iPhone, each of the components are independent from each other, but as Ubikwiti is a platform for business application, we have built in a set of common business objects such as Account, Party, Contact, Document, Journal, etc as the building blocks (like LEGO blocks) to 'snap' the components together. For example, a customer record created in Customer component can be used in the Invoice component as both using the same Party business object.

This gives the user the real power to build his/her own composite business application, or the real on-demand application. Anyone can start with some basic components to build a personal finance management application, and grow it to an order-to-cash financial application, or even to a fully function accounting system, just by adding more components from the U-KwikShop.

Another benefits of this approach is on the update of the components. It is similar to apps in iPhone, user can update the components individually, or even skip some updates if they are not relevant. User makes the decision.

I can see that the power of Ubikwiti application can be enormous once the U-KwikShop starts to have a lot of business components that link up with 3rd party web services such as online collaboration services, banking, payment, tracking, and so on.



Sunday, January 11, 2009

How far can you go with loosely-coupled?

When we were building the Definition-based Dynamic Engine (DDE) with EJB on IBM platform, I wanted to have a multi-layer loosely-coupling on data model, i.e. persistent data layer, processing layer, and presentation layer. Which means the data schema in the persistent data layer is independent from data container structure in processing layer, and display fields in the presentation layer.

Why is this multi-layer loosely-coupling data model important to DDE? As the Ubikwiti's dynamic business applications running on DDE are constructed from many business components which are developed ("defined") in XML files that consists of the GUI definition, business rules, business processes, business objects relationship and data format, we can't fix in design time where to store the persistent data and its schema, what information and business rules to be processed by each business component, and what to display on the screens or reports. Without this level of loosely-coupling, the business components (the LEGO blocks of Ubikwiti application) will be very rigid and limited in terms of customization and extension.

In EJB, we first tried Entity Bean, but it was only okay for persistent data management but not flexible enough to be used for process layer, and not possible for presentation layer. We then tried Service Data Object (SDO), the latest SOA related technology at that time. The concept was very promising. We first started with SDO comes with WebSphere Application Server (WAS), but changed to Tuscany SDO due to IBM SDO didn't come with good XML Data Mediators Service (DMS). 

We thought the Tuscany SDO can help us to achieve the multi-layer loosely-coupling already, but unfortunately, the data graph created from SDO is tightly-coupled with the persistent data schema. Either we were expected too much from SDO or it didn't deliver as promised.

At the end, we achieved the multi-layer loosely-coupled data model by creating our own Data Transfer Object (DTO), which became the only data container for GUI, Service Object Manager, Business Object Manager and Business Object. The Business Object is still using the Tuscany SDO for persistent data management. Each DTO is initiated in runtime and constructed the data graph(s) in it from a XSD file that defines the schema and restriction. A mapping XML file is being defined if DTO data graph transformation is required from a layer to another layer. We also serialize/de-serialize the DTO for passing the DTO between the client tier and application server tier. 

If you can understand what I explained above, you should be able to see how powerful and flexible this multi-layer loosely-coupled data model is, and how much potential the Ubikwiti Platform can be. If I didn't explain well enough and you have interest to know more, please drop me a comment.

So, how far can you go with loosely-coupled?