Wednesday, July 25, 2007

ICSOC 2007


I will be attending the International Conference on Service-Oriented Computing (ICSOC 2007) in Vienna, Austria on the week of September 17th.

Not only is ICSOC a top notch academic conference (with ~20% acceptance rate) but the location is not too shabby either. Vienna a city with a rich culture, history, and far reaching political influences over the years. It is located in the middle of Europe and borders eight other European nations.

Some of my planned activities include:

  1. Tutorial entitled Web APIs and Services Mashups using Ruby and RoR. See also my tutorials page for slides and code samples. Though keep in mind that they will likely be updated for September

  2. Mashups'07 workshop. See also this blog entry

  3. Presentation and demo for paper entitled A Domain-Specific Language for Web APIs and Services Mashups


If you plan to be there then definitely drop me an email so we meet.

Thursday, July 12, 2007

On the nature of work... or what's the relationship between Mozart, Parkinson, and agility?

Does more time lead to better work?
"I need an extension to submit my paper" Jane asks. "OK, but I can only give you one more day" Peter replies. "Well, if I had one more week, the quality of the paper will be significantly better..."
How many times have you heard similar conversations or have been part (on either side of the fence) in some similar debate. Not just for writing but any types of creative works. In today's continuous work environment and Web time, does more time lead to better work?

A positive answer to this question would seem to imply simply that one would spend more time on the tasks at hand, revising, researching, and improving it, now that one has more time... interesting. In Software Engineering there is a principle called (interestingly enough) Parkinson's law or principle that says (paraphrase) that total work tends to grow to fill the time allotted. This phenomenon, known for decades, and observed in many contexts and certainly in software, helps explain a lot of why software tends to be late, along with other human tasks... The rational for why the Parkinson's law applies so broadly has to do with human nature and also to the dynamics of human tasks and their non-linearlity. In particular the non-linearity of human inspirations (important). I believe that this principle is universal to any type of creative works.

Now this may not be your case. However, for me, any deadline extensions means that I end up pushing some of the work later and address other top priority items now. Naturally, sometimes it could also mean that I spend more time on a given item and improve it's quality. However, in almost 90% of my tasks I am starting to be like (unfair comparison though more like an aspiration) Amadeus and deliver my tasks (papers, code, presentation, and so on) without much revisions---basically as they came to me.

Again, not to compare one with the genius of Mozart, aspiring to be like him though maybe a cool thing. We are all stretched thin and under pressure, so learning how to get things done the first time and also done well is a skill that can pay really big, though clearly also incurs a certain amount of risks that could cost dearly.

The agile software development movement solve this problem in a similar fashion while reducing the risks with delivering tasks without revisions and by reducing wastes. Essentially, in agile methodologies, iterations are an integral part of all tasks while early-and-often delivery is also a primary activity. Agile teams deliver their tasks quickly and revise them often while focusing on what is more important at the time by allowing the stakeholders to drive (i.e., direct the priorities) which help reduce efforts that are not important or potentially wasteful.

Can this approach be successfully applied to other human tasks? Is this a good thing? Are there alternatives that also allow one to remain competitive?

Friday, July 6, 2007

Thoughts on enterprise mashups...

Are mashups good for enterprise integration? Do enterprises need mashups?

There is a real danger in thinking of mashups as just another tool in the enterprise IT integration mess. What I mean is that Web services have loss a great deal of their simplicity as they moved quickly to help solve enterprisey issues (read as mainly non-functional attributes), e.g., SLAs, reliability, scalable data and event sharing, transactions, some aspects of security, and so on... Entered, the so-called WS-* set of standards.

So far (as far as I know) very few enterprises actually use WS-* to re-engineer or implement their enterprise IT systems. The complexity of the "standards" is one of the main factors to this lack of success. Instead, I believe that enterprises still rely on tried and true and proven technologies such as relational DBs, message queuing systems, and so on, and expose simpler Web services or Web APIs at the edges for integration. For instance, Atom or RSS data services and REST services when business processes need to be exposed.

I fear that the same complexity tar pit will engulf mashups if we rush and attempt to try to make them the next "silver bullet" for enterprise integration...

Mashups have a place in the enterprise but in my view it's rather limited and is related to the more social and community aspects of enterprises (internally and with external companies and events). Stefan Tai's (IBM T.J. Watson) service community research project was the first to hint at this trend.

Mashups can be a great edge integration technology for enterprise services, whereby most of the complexity-prone non-functional attributes (other than security) are not directly addressed by mashups and instead provided by and relied on by the lower-level enterprise software stack, which have (slowly) addressed these non-functional issues over time.

Finally, on a grander scale this edge integration thought is happening *now* for small-to-medium enterprises and also is becoming more relevant as back-end enterprise systems are hosted by large services in the cloud, a la SalesForce.com and Amazon Web services. When these hosted services become mainstream then mashups and associated technologies may become the glue for software innovations at companies small, medium, or large.

Let us resist the dark side and not let mashups and associated technologies become the next WS-death *

Thursday, July 5, 2007

Mashups'07 Workshop at ICSOC 2007 in Vienna, Austria


Stefan Tai, of IBM T.J. Watson Research Center, Dave Nielsen of StrikeIron, Inc., and I are organizing Mashups'07 Workshop at ICSOC 2007 in Vienna, Austria on September 17, 2007. The Call for Papers and Demo is posted and the dealine is July 15th.

We have a great varied Program Committee composed of industry leaders (e.g., Google, Yahoo!, Adobe, and so on) as well as Academia (e.g., NC State, Stanford, and UC Berkeley) from both computing and business schools.

Finally, we are experimenting using a content mashup tool called Highlightr during this meeting for discussion, sharing, and mashing content.

Highlightr is an example application built using our Web 2.0 (situational applications) and Web APIs mashups research project at IBM Almaden called Swashup (built in Ruby and RoR). We also have a paper and demo of this project that we will present at ICSOC 2007 in September 2007 in Vienna.