Customer Innovation Team offers a worldwide jStart program for "jump-starting" the acceptance and implementation of emerging Web 2.0 technologies. The jStart Program is delivered by a pool of Engagement Managers and Solution Architects backed by IBM-certified software laboratories around the world.

Google getting into competition with Wikipedia

Using Mashup tools to break down corporate boundaries

This is a scenario I came across at an insurance company in Australia. Spreadsheets of branch addresses, company brands and the company legal structure was held in spreadsheets by individuals in various business units. Because of recent acquisitions, there was no single source of information showing all the brands and where they sat within the organisation. Using IBM Mashup Starter Kit we turned the spreadsheets into ATOM feeds that were published in a Mashup Hub server in the corporate Intranet. Now the data is available to anyone with access to the server via the corporate Intranet. Users of the Mashup Hub can now access the data via an ATOM feed and rate and tag the data and the data providers can quickly see how useful the data is.

Using the QEDWiki mashup maker component, business users could access the feeds to create a mashup that showed company brands, brand branches on a Google map and legal entity information for the brand. Legal entity information was annotated with information from the Australian Business Registry via a web service.

This business scenario was used to show how data maintained on an employees workstation could be exposed to the rest of the company and used in a mashup.

Designing for “ease of assembly” verses “widget reusability”

One of the things I have discovered in many of my early customer engagements with QEDWiki is the tradeoff the widget developer must make between reusability of widgets and the simplicity in which pages can be assembled.  If widgets are developed at a low level of granularity, they typically can be resused in lots of other pages.   On the other hand, when widgets are created at a very granular level, the page assembler’s task is much more difficult in that they end up working with a large number of widgets and need to perform a lot more widget to widget wiring.

Here’s a simple scenario that illustrates this.  Let’s say, a piece of my situational application has a requirement to provide the total dollar value all of a customers accounts at a financial institution.  The financial institution has recently merged with another bank, whose systems have not yet been integrated, and many bank customers have accounts in both banks.  Here are two ways I can develop the widget(s) that are needed to fulfill this requirements:

1. Granular approach maximizing reuse.  The four widgets developed are:

<!--[if !supportLists]-->·        <!--[endif]-->ParentBankAccountSearch widget- invokes an appropriate API(database query, web service, CICS transaction, etc) to get a list of bank accounts and their values for the customer (customer identifier provided by another widget).  The list of accounts and some details of the accounts is published for other widgets to consume.

<!--[if !supportLists]-->·        <!--[endif]-->AcquiredBankAccountSearch widget- invokes an appropriate API(database query, web service, CICS transaction, etc) to get a list of bank accounts and their values for the customer (customer identifier provided by another widget). The list of accounts and some details of the accounts is published for other widgets to consume.

<!--[if !supportLists]-->·        <!--[endif]-->SingleCustomerAccountView widget – consolidates account information from multiple sources.  Here both of two above widgets would be wired to this one.  The consolidated, single view of the customer’s accounts is published for other widgets to consume.

<!--[if !supportLists]-->·        <!--[endif]-->TotalAccountValue widget – takes the list of accounts published by the SingleCustomerAccountView widget, extracts and sums the account values.  This sum of total account value is then published to meet the original requirement.

2. A coarser approach, maximizing the ease of assembly.  Here two widgets are developed:

<!--[if !supportLists]-->·        <!--[endif]-->SingleCustomerAccountView widget – consolidates account information from multiple sources.  This widget would invoke internal bank APIs on all of the systems that the financial institution uses to house account information. The consolidated, single view of the customer’s accounts is published for other widgets to consume.

<!--[if !supportLists]-->·        <!--[endif]-->TotalAccountValue widget – takes the list of accounts published by the SingleCustomerAccountView widget, extracts and sums the account values.  This sum of total value is then published to meet the original requirement

And of course, there’s even a 3rd option – just a single TotalAccountValue widget that does all the work.  From our situational application assembler’s point of view, clearly option is the simplest.  One widget does all the work and only a couple of wiring operations are needed for the widget’s input and output.  There’s also less work for the widget developer in that only one widget is needed to be developed and one “data available” event needs to be defined.

Tradeoff’s like these have been made for years in software development, especially when looking at the reusability of objects that were to be developed, but the introduction of the assembler role in the situational application ecosystem changes the game a little bit.  I still remember an early engagement we did with a client where we had a QED page with about 20 very granularly developed widgets on it that needed to be assembled and wired.  After about 10 minutes, you could feel the client getting very impatient as he started to think about the viability of QEDWiki being able to meet the “5 minute application” objective.

QEDWiki helps address this issue with the concept of composite widgets whereby a widget can bundle in other widgets that are prewired.  You can see an example of this in the QEDWiki Feed widget which includes a ShowData that is prewired to the output of the feed’s data available event.  This helps in meeting the “assembler simplicity” goal , but still has the result of instantiating a lot of individual widgets on the page and causes a lot of data events to be fired and consumed, impacting the overall performance of the situational application.

I’d be interested in getting comments on what else QEDWiki should be looking to do to address this problem and on how other widget developers are dealing with this issue of “ease of assembly” verses “widget reusability”.

Money play around Google's OpenSocial?

Advertising on Facebook

On 6 November Facebook announced new tools for advertisers on their site to reach a wider audience using your friends network. We're putting a lot of information in social networking sites and Facebook is looking for better ways to make use of it. Better for you? Better for Facebook? Better for marketers?

See also this article from PCWeek.

Iwan Winoto - IBM jStart, Emerging Internet Technologies

How to make your business application available to mobile device users?

Java EE vs. Web 2.0

Google Mobile API

Google releases OpenSocial API's