Reading Zack Rosen’s assertion that building applications inside Drupal-the-framework makes more sense than loose integration of complementary applications triggered some thinking that’s been rattling around in my head for a while.
I think that the next few years are going to bring tremendous challenges for applications that do not easily communicate with other applications that are “outside their platform” i.e are written using a different language/framework, run on a different server, etc.
I think the most powerful path forward over the long haul is internet-based integration between great applications that were designed from the ground up to allow for it.Â
In other words, web services APIs are going to become increasingly more important, and the particular application frameworks less so. This the “small pieces, loosely joined” model, to echo the phrase that others have appropriated from Dave Weinberger’s influential book.
There are some great communities and significant resources behind very cool projects that provide great functionality that I really want to be able to tap. I don’t want to have either persuade them all to develop in a single platform (it’s just not going to happen) or try to duplicate all of their functions in whatever platform I’m most comfortable in. (Which, truth be told, is “none of them.”)
My colleagues here at ONE/Northwest and I would much rather focus on integrating best-of-breed applications that have strong web services APIs and are designed around the assumption that external applications are first-class citizens of their ecosystems. (Damn, that’s a lot of buzzwords.)
At the end of the day, why should I have to care if an application is based on Python, Zope, PHP, Rails, Django, or some technology I’ve never heard of? Why should I have to run all my applications off a single server? That’s not scalable. We now have a whole set of standards and technologies to let applications communicate with each other over the internet.
“Web services” is one of those complex, slippery terms that means lots of different things to lots of different people. To me, in this context, it means applications that share data with other applications over the internet. The more of your application’s guts it can expose to the outside world, the more powerful your web services API.
Some applications that I think are really moving in the right direction with web services support are:
- Democracy In Action — powerful API, alas, not yet well documented. Little known fact: the smart guys at Enfold Systems have releaesd a Python wrapper for the Democracy in Action API, which (supposedly) makes integration with Plone possible. Haven’t tried it yet myself. But I’m looking forward to it.
- Salesforce.com. Holy cow, these folks really get it. I’ve heard that half of their traffic is through their web services API. This is how a relationship management database should be — accessible by most any external application.
- WhatCounts. These guys do our email blasting. Lots of folks do email blasting, some probably just as well as WhatCounts. But what sets WhatCounts apart from the pack fo us is the fact that they have strong APIs. This lets us do cool stuff like pull in names from Salesforce, or inject new subscribers from Plone, or pull in content from a Plone site. (Well, technically pulling in content from the outside doesn’t use their web services API. But the point is that WhatCounts can pull in data from outside and let other apps push data in.)
- Another, less strictly “web services” example is Plone’s new PlonePAS framework. Basically, it’s a framework for authenticating users and retrieving user data from any old data source you’d care to write a plugin for. We’re going to try to use it to integrate Salesforce.com and Plone.
- The whole open-source GIS software ecosystem, most especially including MapServer. My next-door neighbor, Chris Davis of CommEn Space, has shown me some really mindblowing stuff with maps that dynamically draw in data from all over the internet, thanks to open data standards and web services.
Can you see an advocacy software ecosystem here yet? I can.
And let’s not forget all the “Web 2.0” applications out there that are getting so much hype these days. One important thing about the most exciting of these tools such as Flickr and Del.icio.us is that they can be written to and read from by outside applications via web services APIs. (Amazon has done amazing stuff here, too, albeit without getting much “Web 2.0” credit for it.)
This is where it starts to get cool. The days of monolithic application stacks that try to do everything are fading fast. A new “network-centric” software ecosystem is starting to bloom.
And the best part: nobody has to “deeply partner” or adopt a single platform to make it work. They just have to focus on building great web services APIs so that other applications can meet them halfway. That’s not easy, but it’s surely easier than getting everyone to adopt the same platform.
Some software tools that I really hope build strong web services APIs as they roll out their next releases include:
- Green Media Toolshed
- CiviCRM (their web services API work seems to have stalled out in favor work on a PHP API that only talks to a PHP application (like Drupal) installed on the same server. Hopefully their focus will soon return to playing with the outside world, too.)
- Custard Melt
- Advokit
- All of those nonprofit online donation tools that I am too tired to list right now. You know who you are.
- And, yes, Drupal, too. 😉
I’m probably overlooking some other apps that ought to be listed here. Feel free to suggest them. It’s late.