|Home • Patterns • Ramblings • Articles • Talks • Download • Links • Books • Contact|
Enterprise Mashup Summit
October 1, 2007
I attended the Enterprise Mashup Summit last Friday. It was a small-ish event, with about 50 people attending. We saw about 10 presentations, mostly by vendors plus an open forum. None of the presentations were too sales-ey, which gave the event a nice workshop feel. Given the limited size, it would have been nice to have more time for interaction. Here is a quick rundown of my impressions.
The word of the event was certainly situational application. I like the word and it even has a Wikipedia entry already: A situational application is software created for a small group of users with specific needs. The application typically has a short life span, and is often created within the group where it is used, sometimes by the users themselves. The best part about it is that you no longer have to say that you hacked something together quickly. Rather, you built a situation application.
Creativity with Control
This IBM slogan highlights the dilemma corporate IT faces. Enabling end users to build situational applications takes a lot of load off IT. On the other hand, without any kind of governance a growing repertoire of these applications can become unmanageable.
Dave Nielsen, StrikeIron
Strikeiron acts as a marketplace for high-value web services, i.e. the ones a business would want to pay for, such as sales tax computation, address correction, etc. StrikeIron acts as a middleman between service provider and consumer, providing security, metering, monetization, reporting, etc.
Dave summarized his view of Web 2.0 in three bullet points: more users, more savvy, more willing. When the bubble burst, the valuable users did not go away, they just became more savvy, meaning they wanted more sophisticated applications than a lot of the dot-coms offered. As we have all seen, users are also much more willing to contribute personal information etc. This underlines the view that mashups are more of a social phenomenon, as opposed SOA being technical phenomenon. Dave illustrated his point by comparing pre-bust matchmaker.com, which provided simple multiple-choice profiles to match.com, which allowed freeform text and image sharing, to YouTube, which hosts more embarrassing videos than we'd like to imagine.
When asked about governance, Dave mentioned that he does not see many issues. Mashups based on StrikeIron tend to be in departmental, not business critical applications. In his view, the full fledged SaaS applications (SalesForce and friends) are leading the way there by providing SLA etc. StrikeIron alleviates privacy concerns by assuring customers that they do not store data. In general, they try to see to the business directly as the IT sales cycle can be 6 months or longer.
Stefan Andreasen, Kapow
Stefan talked to his product suite, which can help scrape data off Web sites and make it available as a feed or service. In this realm he distinguishes between horizontal data, which is easily available to everyone and vertical data, which is more personalized and more difficult to get at. He compared housingmaps.com (horizontal) to a more targeted application that might provide school rating for families with kids or bars for single people.
Kapow currently sells their software into the enterprise as investment towards future mashups. Sample applications include reputation management (e.g., checking blogs for mentions of your company) or competitive intelligence (e.g., check competitors' prices or monitor retailers' "out of stock" situations to estimate how well an item is selling). The obvious questions for Stefan were the robustness of the scraping approach and the quality of the data. In his view, the business value of data is higher than the cost of having to rewrite your application every once in a while, making it viable to work with a solution that is a little brittle. Inside the enterprise application changes can be managed more easily, making the scraping approach more viable.
The second major question relates to legality and end user agreements. In my view, sites who like to share their data typically provide web services and / or feeds already, while sites who do not share their data as a feed typically issue end user agreements that prohibit users from scraping and repurposing the data. Stefan has obviously heard this question before. One response is the "guns don't kill people" attitude, even though we learned from the Digital Millennium Act that in the eyes of the government "Software, not people, cracks code." Taking another point of view, these tools simply automate tasks that companies already execute manually, e.g. by having someone copy and paste competitor's prices off their sites. The most convincing scenario is probably company internal use, where such concerns do not arise.
Patrick Chanezon, Google
Patrick gave a nice overview of Google's offerings for the enterprise market. Google is becoming an increasingly important platform player, Google Apps being the most visible offering. Apps is complemented by a set of APIs, some of which are available specifically to enterprise customers, such as Google Maps for Enterprise. Patrick also pointed out it's easier to use effectively more recent products, such as Google Gears, inside an enterprise, where a consistent software image can be deployed to all users. In true Web 2.0 spirit, Patrick shared his slides and demo material on del.icio.us.
Oren Michels, Mashery
Oren spoke from a vendor who actually makes money in the mashup space. Mashery markets primarily to companies who own high value data but have relatively little traffic to their Web site. Mashery proposition is to make it fast and safe to expose offerings as public web services. For example, domaintools.com's API traffic is a multiple of the site traffic. Oren mentioned a photo web site that does not currently offer an API and apparently receives 100 requests a day (!) to provide one. Mashery runs its servers on Amazon's EC2.
Sriram Padmanabhan, Lauren Cooney, IBM
Sriram and Lauren shared IBM's Info 2.0 vision: discover, transform, feeds, mashup. They underlined the fact that enterprise applications and situational applications complement each other. IBM play in the space consists of three elements: Mashup Hub for discovery, DAMIA for data processing, and QED Wiki to assemble mashups. More at Lauren's blog.
Deepak Alur, JackBe
Deepak demo'd the JackBe mashup platform. The Presto Wires mashup composer offers a composition model similar to Yahoo! Pipes or IBM's DAMIA. Alur sees mahsups as a new layer in the layered software model, resulting in Presentation, Mashup, Business, and Integration layers. As co-author of the well-know "Core J2EE Patterns", Deepak is interested in documenting common mashup patterns. He listed the following patterns: invoke service, filter, sort, join, merge data, transformation, annotation, for-each, web clipping, scripting.
At the core of JackBe's mashup server is an XML scripting language, which allows developers to define "services". These services can be composed into larger services through micro-orchestrations.
The event completed with a panel, which was more of an open discussion. This part was very interesting -- I wish we had more time for this type of interaction. I wish I had taken better notes. For now I have only the questions:
The buzz around Web 2.0 can be heard quite clearly in the Bay Area. This weekend we have the Community Next event, followed next week by the The Business of APIs event and the Web 2.0 Summit. It's become difficult to keep track of all the events in the area. Luckily, Web 2.0 application like Upcoming or Facebook help us manage.
MORE RAMBLINGS SUBSCRIBE TO GREGOR'S RAMBLINGS
Gregor is the Chief IT Architect of Allianz SE. He is a frequent speaker on asynchronous
messaging and service-oriented architectures and co-authored Enterprise Integration Patterns (Addison-Wesley). His mission is to make integration and distributed system development
easier by harvesting common patterns and best practices from many different technologies.
|© 2014 • All rights reserved.|