In the 90's, we heard a lot about the knowledge worker. Personal Information Managers, self-help books and motivational speakers - it was all about optimizing the individual. Make ourselves more efficient, more organized and, hopefully, a lot richer. What was the result? Well, I can't remember the last time I've run into some one that was organized and not suffering from information overload. In that era, we were taking a microscopic, inside-out view at solving whatever issues we were having.
Today, the hype is all around social software, new more fluid approaches to workflow, and collaboration. Making ourselves as groups and organizations more efficient. The information workers, as we call them now, are not islands. They are linked with each other in vast human communication networks. How are we doing it? By simplifying the interfaces we have with each other to increase the number and effectiveness of our links.
Blogging and Wikis are a good example. What has made these tools so successful? Not a complex feature-rich user interface for publishing to our websites. No, a simple, usually crude, interface with little features. The simpler the better. The less features the better. And its working - I'm learning more from people and about people than I could ever have imagined through these simple interfaces.
I see some similarities between this approach to human collaboration and the approach we should take toward web services and SOA. The simpler the better.
Over at Brain.Save, Steve Maine writes about his macroscopic approach to SOA:
I take a more macroscopic approach to SOA...I look at SOA in the larger terms of systems integration. I’m more interesting in layering a service façade over existing functionality and exposing it to the outside world so it can participate in larger systems instead of the single application for which it was originally designed. Personally, I don’t think the use case for SOA inside a single application is that compelling.
I agree with Steve. I think of Web Service as a facade around existing applications. A boundary where I try to limit the interaction with other applications to the simplest possible set of methods. I realize all scenarios may not fit into such a limitation, but I think the more complex you make a set of Web Services, the less effective they are to a greater number of potential integrations.
InfoPath is a good example. InfoPath is like a human interface into an SOA. An information worker could pick up InfoPath and with a little book or classroom training, can attach to a web service and submit structured data into an XML information bus, potentially touching a dozen systems across the enterprise before the document completes its path.
The key to making that scenario happen, is clean simple web service interfaces, especially the one that the InfoPath form designer uses. If its complex, all of a sudden the things you have to do in InfoPath to make the integration work, become too advanced. A complex web service also increases the chances of getting it wrong or messing something up.
Keep it simple. Less features. I find that some of the greatest ideas and elegant solutions come out of such restrictions. I was very excited at the PDC to see how limited the interfaces were for Indigo. I think developers are going to do some incredible things with Indigo, even though it seemly has less options than the plethora of knickknacks in COM+.
Updates
01/18/2004 jdzions writes how you can use Interix, included with Services for Unix to wrap a Web Service around a Unix application.