As the software as a service (SaaS) field heats up, some vendors and customers are finding creative ways to implement SaaS projects.
For instance, a recent CRN article
by Doug Henschen
explains how the University of North Carolina Charlotte (UNCC) is using Xythos OnDemand -- an SaaS document management offering we covered
on Dec. 8 -- as a stepping stone to aid their decision about which document management system or service they will eventually buy.
The idea of SaaS as a product test drive is not new, but UNCC's approach to implementing a pilot project highlights the importance of sensitivity to internal politics which may demand gradual change.
CRN quotes UNCC chief technology officer Tom Lamb as saying, "We needed a champion who could sell it to the rest of the faculty and help build momentum for an enterprise-wide deployment." Henschen adds, "Lamb found his champion in Dr. Tom Kitric, a visiting professor who agreed to spearhead the pilot as part of a class on content management. Kitric, 30 students and a score of faculty members will begin using the on-demand service this month [January 2007]."
Taking a gradual approach to SaaS also may help protect customers if a provider turns out to be a dead end. In the Intelligent Enterprise, another recent article by Henschen, "Will Your SaaS Provider be a Survivor?
" observed that many companies that offered SaaS document management in 2000 are no longer visibly in that business.
How do you spot a likely survivor? Henschen suggests
that SaaS systems based on service-oriented architecture (SOA) stand a better chance of serving customers' long-term needs. "You certainly don't require a SOA to use SaaS," he writes, "but if you want to effectively mix and match external services with on-premise assets and services, SOA will make it possible to efficiently build, deploy and manage composite apps."
And how do you tell if a document or content management system really
is SOA-based? Keep in mind this basic definition from TechWeb
: "Instead of building monolithic applications for each department, an SOA organizes business software in a granular fashion so that common functions can be used interchangeably by different departments internally and by external business partners as well. The more granular the components (the more pieces), the more they can be reused."
In other words, if the architecture includes lots and lot of functions to manage basic-sounding, generic tasks and sub-tasks, chances are good that the SOA is genuine. Watch out for too many references to tasks that seem focused on a single department or type of user.