Tuesday, October 30, 2007

Software-as-a-Service (SaaS) for CM systems

In a podcast on IBM developerWorks, Dave Michell explains about Software as a Service (Saas):

the customer does not take ownership of the software, but they're going to rent this solution in a subscription model, and it's delivered remotely. And that's very different from the ASP model. In the ASP model, or the application hosting model, what the customer is doing is they're buying the software.

In the Software as a Service model, again, the customer does not own the software. They subscribe to an offering and they buy that offering in a subscription model per user per month. So there's no software purchase to be made.

And the other key point here is in the Software as a Service model, the customer really has no say over what the infrastructure is. They don't get to decide what the hardware is or the middleware or the database — and more to the point, they don't really care.

So in the SaaS model, the customer says "I want to buy that application functionality. I'm willing to pay this much per user per month," usually is their typical model. "And the service-level agreement meets my needs. So I'm going to acquire that application that way."

Considering a configuration management system, such as ClearCase, many customers struggle with configuring the system for optimal performance, setting up and configuring servers, network and client parameters. In many cases, the users don't really care whether it is ClearCase, Synergy or Subversion behind the scenes, as long as that can do version control, baselining (or labeling or tagging), parallel development (or branching or streaming), delivery, rebasing, releasing, status promotion, structuring, setting attributes, and all the other CM stuff. Users don't care about sufficient licenses, disk space, replication across sites and other IT issues; they just want the system to be available and to work properly to their needs.

So, the CM system seems a perfect candidate to be deployed as Software as a Service. Even more, if the CM service is offered as a Web 2.0 application, the internet will be the platform allowing local and global accessibility.

If in addition there would be a standard set of CM service features, the CM back-end could be supported by just any CM vendor that complies with this standard. The front-end could even be of a different vendor or proprietary to the customer, e.g. as a dedicated integration with other systems. Customers could then focus more on the tool-vendor that suites best with their organizational and IT needs, and users could better focus on dealing with true configuration management issues, rather than being hampered by infrastructure and IT issues.

Why wouldn't a product like ClearCase be offered an SaaS model, if IBM is such a promotor of SaaS?


edelwater said...

Maybe because the CM system as a standalone thing is pretty old fashioned without integrations to other parts of the project/organization e.g. testtooling, buildtools, developmenttools, etc...

In a SAAS environment this would mean that either all these integrations would somehow have to be converted to webservices which travel over a secure fast line (uhm... so all vendors will have to rewrite their integrations, plugins, etc...) OR you would host everything at the SaaS environment including testtooling, build tools, development tools (eclipse, visual studio etc...).

If you say "users really dont care" , uhm thats basically with any application, so why don't they use MS Word as a SaaS and all goto Google docs? (scratch uhm and ofcourse this has then to be integrated with the SaaS-ed CM tooling :))

edelwater said...

And, yes, users dont care but users are typically in a specific environemnt e.g. .Net development, Java development a RUP project or a method X project, a JD Edwards project or a Siebel project. I think that the technical aspect e.g. "that is available" is only 1% of what the CM system is about, so either these CM SaaS will get pretty specific or nothing more than an advanced online storage and backup medium of which there are millions already (incl. the free Subversion hosting by almost any webhosting company).

Frank said...

Thanks for your respons.

You are mistaking that all integrations need to be converted to webservices. From a standalone application (e.g. a testtool), one could integrate with webservices without the need to convert the tool itself to a webservice.

An since CM plays a role in almost every design-related tool (requirements, design, testing, etc.) - and also with organization related tools (planning, reporting, etc.) - , having a standard CM webservice would be an advantage for integration.

edelwater said...

Well.. mistaken... 1) I think we agree that customizations need to take place. 2) Furthermore: what would be need on the client? Subversion still requires to install e.g. subversion tortoise, a full client. ClearCase currently could use the CCRC and the team API / CCRC command line. This solutions still use a client on the uhm client side. If you do not have a client on the client side then it means that almost the full cleartool command set needs to be provided via webservices. Is this logical, is this typically SaaS? 3) Furthermore there is a reason for Multisite: if a user checks in multiple megabytes large files (e.g. siebel projects) an hour, constantly, and this would go via a webservice you run into the same problems (very irritated users who spend long times at the coffee machine) that would otherwise could be solved by a multisite solution ergo synchronzing packages instead of calling a service on each and every action. Waarom doen we dit in het engels?