Sunday, February 05, 2006
More on Mashups and SaaS
Mashups, SaaS, Web 2.0, whatever we're calling distributed & combined services this week, promotes agility and flexibility. Reconfigure or redesign, basically, at will. It makes the web one giant OS or platform with wiki-like ability to access and update data.
Flexibile and efficient. Who wouldn't want something like this as opposed to the monolithic apps we've built for decades? I sure would, and so would a lot of people I know.
And that very flexibility could be the great undoing of Web 2.0, if caution is thrown to the wind with respect to security and operational effectiveness. Right now, I've got a big problem with data security in schemes like this. For example, I'm not as much concerned about personal data flying over the ether as I am that it lands somewhere - in a database - where it shouldn't be. I'm just waiting for the first service or SaaS spoof incident to come forth. And that's not if folks, but when.
Finally, we get to a conundrum I've thought about but haven't had anything substantial crystallize as yet: we have always been taught that single-points-of-failure are bad, bad, bad. Made sense then for various reasons, and continues to make sense today. In a services scheme, SPF's come part-and-parcel because the uniqueness-of-service concept overrides wide distribution of a service. A basic or me-too service would most likely reside on multiple provider URLs and not be subject to SPF issues. However, as the recent salesforce.com outages reveals, dependent entities are largely dead-in-the-water if the dependency on services or SaaS apps is large enough to shut down significant portions of the subscriber's business. Not good at all.
Agility will never trump security and robustness as the latter two present hugely unacceptable risks to organizations. If we're going to do Web 2.0 right, these issues deserve as much consideration and effort as the agile mashing of services and the building of them do.
Links to this post: