09/16/07 :: [SOA] Mash IT up [permalink]
I created my first mashup in 1999 and it was love at first sight. I knew for sure back then that it would be a crime to leave the presentation layer out of SOA. 99ers would tell you that it was the golden days of procurement and everyone was talking about about catalog aggregation, assembling all kinds of feeds into one majestic catalog. This was incredibly complicated. PhDs were debating on taxonomies and overlaping codes, when, well, huh... how about mashing them up? Ah yes, small detail, how do you deal with a shopping cart in that case? Mash it up too ! I had built a solution using XML fragments embedded behind catalog elements that people could drag an drop into a shopping cart. Not only the UX was wonderful, but the solution was incredibly more efficient. All the components were running where it was most efficient to run them. Suppliers had complete control over their catalogs. We could sell a unified procurement solutions for our clients. We could even pass back some of the XML the suppliers had given us in the cart in case they wanted to track back some promotions.
Cost of all this? a few weeks of work. Management? completely distributed. Is this service oriented architecture? hum... well you have a bunch of catalog services on one side, you have a procurement service on the other, composed of a shopping cart service and some ordering service. Ah... the user is in the loop. So ? I meant SO? you are telling me the user is the orchestrator of all this, how can it be SO? who said SO couldn't be mediated by a user? Ok, if I have not lost you, yes, this is a well-formed service oriented solution that nowadays people call mashups.
IT is in great need of mashups. There are three levels of mash ups (maybe more) that are relevant for IT: presentation, process and information. If most people love mash ups these days it is because they are a gold mine of productivity. You can take any user activity in your organization and do a mash up analysis. How many systems does this user need? What other pieces of information could we provide him or her to do his or her job better? If the answer is more than one system, this is a great candidate for mash ups. ROI is easy to calculate, prove and get back.
But don't stop here, look at your processes, and check where additional service invocations (internal or external) could improve the quality and performance of the process. You can mash information up too. EII is starting to become mainstream and nobody says that all mashups have to be done at the presentation layer. You can preemptively send or consume the data that makes the presentation layer easier to build.
Not convinced? I have built a little mashup to help my children learn how to read (flashreader.org). The principle is easy, let them type in some flashcards and then look at what you can do with a word on the web:
- dictionary & thesaurus
- translate in French, Italian or Spanish
- get some information from wikipedia
- sound it out
- get a picture that represents the word (that my child has chosen from many)
- build a spelling sheet
- build little word games
- ...
endless. Now if I had to go to each of these web site for every word and have to type it in each time, not to mention having to navigate through several pages... well I would not do it, let alone my children who would pass on tons of experience around a single word. Don't try that at home. It would take years to recreate the same app that I wrote in 3 weeks on my spare time.
So mash IT up ! today !