Building mashed-up applications means taking a step from self-developed functionality towards re-usage of existing functionality. This is not a completely new approach as we were living this with component oriented development and way before while I was too young to switch on a computer.

One of the differences with service oriented architecture now is, that instead of reusing libraries that you copy and bundle with your solution, you now use services that are developed, maintained and operated by someone you might not even know. You don’t use a copy of functionality but a (remotely) running, lifecycle managed service. Needless to say that now you might want to have some assurance that the service remains stable, available, is occasionally enhanced with new features without breaking the existing ones and that you as a service customer are notified of any changes. Those service level agreements become more important the more services you consume.

For business applications, every application owner (do we now call them solution manager?) should be smart enough to insist on the service quality of each and every service he consumes. Not doing so, he would risk the quality of his own service and the business value he offers in the company. To some extend he could save himself by not offering a service or for that service not assuring any quality her couldn’t possibly adhere to. This dilemma is most probably one of the biggest challenges with getting Service Oriented Architecture running in a larger company.

What about the web? One of the things I observed the last months was, that with “Web 2.0″, the above issues didn’t seam to bother. Is it because the downtime of an amateur web page doesn’t cost too much money like in a business environment? Or are web masters not aware of the issues? Yahoo with flickr, Google with GoogleMaps, Spreadsheet, …you name it… all these companies offer well described APIs which other can use and it seams that the community is sucking-up every new service to create some new mashed-up web site.

I don’t exclude myself from this community since I’m eager to form (my existing) smaller information crumbs into something more powerful. But last week, I fell into a trap. Extending my flickr-based gallery with Google Maps, I search my photos for a certain area on the map via flickr.photos.search passing along some arguments. This was working fine until some day last week my unchanged test application only displayed 19 instead of 7xx photos on the map. It took me quite some time to drill down to the point I was able exclude everything except flickr itself.

What happened? Besides the parameters for authenticating the call, my test application passed the arguments bbox, accuracy and user id to flickr. Due to some glitch, my call didn’t forward the accuracy which I didn’t notice because everything went through perfectly. Some day last week flickr must have changed their search internally, making the accuracy “kind of” mandatory.

Concluding, it now comes to the ethics of service orientation:

• -Do not change behaviour of a service!
• -Consider changing the interface to make visible that the service doesn’t return the same result as before!
• -Describe your service in detail. This includes not just the overall functionality but the impact of every single argument.
• -Always have your customers in mind. Although they might not be paying, they rely on your service.
• -Lifecycle Management is key! This includes proper versioning… Did you ever think about what happens with people that use your service while you start offering a next version of your service?

To be continued…

I remember that one of the urban legends managers in the IT always believe in is that everything will be manageable via drag’n'drop and easy configuration one day (opposed to thoroughly elaborated approaches). History tells us a different story, and we have to admit that where configuration and drag’n'drop would help to cover complex circumstances, the circumstances are too complex to be just configured.

Surprise, surprise.

Everything webmasters were dreaming of is now coming true. Forget about your hosting provider’s homepage kit - the serious companies now offer gadgets you can easily configure to be used in your homepage! So does Google with their Google Universal Gadgets. Opposed to Yahoo Widgets (Konfabulator) and Apple Dashbord Widgets that were bound to the desktop, Google Universal Gadgets now run with HTML and JavaScript and can therewith be integrated in every homepage easily.

They are continuing and extending the pattern: When blogging became popular, hosted blogs were popping up everywhere using the same stylesheet (you know this roundish semi-transparent look everyone adapted). On Blogger, you were even able to step through the blogs that were all looking the same. Doesn’t personality - and design which reflects the same - count any more?

Now, webmasters, you can start building your uniform homepage with the great weather gadget, traffic service gadget, hangman gadget, calculator gadget, currency converter gadget, U.S. citizens need the terror alert gadget… You get the point (and I forgot the sudoku gadget).

By the way: For Google, this is an approach far easier for earning money than placing the advertisement directly on your homepage which looks ugly. And gadgets don’t, because they are funny.

Folks: Tell me, what gadgets you like most (would be a good place for a poll gadget)!