Delivering a SaaS Application - Part 2

In the last post I wrote that the entire business process changes for a company when it delivers Software as a Service. Lets continue on this and see what other things change.

Customer Support: Traditional software companies sell licenses and expect customer support to get a call only after some serious debugging themselves and of course there is always the blame on infrastructure, configuration etc that can be the causes for the problems. However in a SaaS based scenario, all users directly and immediately get in touch when they face problems. There is a need to enable users to get back to the provider as soon as they encounter a problem and then track the problem to closure. Not only does this mean lots of customer raised tickets but also the responsibility of availability as well as configuration now lies on the provider. Seamless and quick resolution of the problem is the only solution and traditional customer support process needs to be modified to achieve this. This is not the only change, every customer must be updated with any downtimes, any problems that is being addressed, anything that might affect the availability of the service. This is crucial to avoid customer frustration and ensure stickiness. Being transparent with the customer in explaining what exactly is happening and ensuring that information reaches pro-actively if there is a planned event or as soon as possible if there is an unplanned outage.

Managing Delinquency: Traditionally delinquency existing only in case of support and one can always stop support if customers do not pay. Whereas in the SaaS model delinquency is a major reason for revenue loss. Understanding how much a customer has to pay, how much has alrady been payed, how much can be discounted and whether to take a decision to stop the service (meaning you basically stop access to everything, the service and support) is very important. Once the decision is taken stopping access to the customer must not be a clumsy process but must be seamless.

Re-sellers: Now this is an area which is perenially mythically clouded. As far as I am concerned, partners are not only necessary but the essence of partnership radically changes when it comes to partnership on the cloud. It is always easy to re-brand and sell a CD and price it 10% higher than the original software provider.All the provider needs to do is acknowledge the partner in some manner and maintain a repository of partners. It is defintely not the case in the SaaS model. In most cases partners are the sales channels and they cannot sell as they do traditionally. what is rather required is the ability to enter into a contract with the partners, share the same infrastructure that is being used to deliver the service to the partner also and enable the partner to white-label or co-brand and then either sell pre-configured service plans or even let the partner configure their own plans! Now that is the ideal way of enabling resellers. What is interesting is the fact that a partner would be treated as a customer and billing for the partner(credit/debit) must happen automatically and without any manual intervention. In fact SAP Acknowledged that their sales of Business By Design was primarily enabled by partners who had the domain expertise to handle their customers. Though this might look like a highly-complex service scenario, this applies at all levels. Even normal services require partners to help reach out to customers and as a rule partners can do this more effectively than the provider.

Lets dicuss this further in the next post....

Technorati Tags     SDP,Business,Process,SaaS

Delivering a SaaS Application

Its interesting what it takes to deliver a SaaS application. Most people do not understand the depth of functionality that is required to deliver an application in the SaaS model. In fact most people think that an on premise can be delivered in the SaaS model as long as it is multi tenant and it can be delivered over the web. This is the first step to disaster!

If you typically look at what changes, the entire business process right from sales to payment changes drastically. In fact most traditional software companies are simply not ready enough to deliver something in the SaaS model. They usually find this out pretty late that their traditional model of leads, sales, payment, support, Operations and even their engineering process changes!

Lets take sales, the traditional model of sales people going to sell software simply does not scale for the SaaS model. What you would require is the ability for people to simply visit you website, gather as much information and probably click and subscribe to your service. You dont have big time gaps from contact to subscription. What probably would be required is the ability for your customers to try your software out. 

Subscription: Since the customer no longer requires hand holding for your product, the subscription process must be simple, self explanatory and probably would be driven through a wizard where customer requirements are gathered and the customer transparently knows how much needs to be payed and for how long.

Engineering: 9 months or 1 year releases no longer works. There needs to be continuous innovation on the product to make customers sticky. Customer feedback needs to be immediately fed back into the product. This is probably tough on the product since this requires the product to be able to support a lot of customization via configuration. Since customers are accessing the product in a single instance and the product needs to support individual customer needs, there needs to be a lot of thought on how to allow customers the flexibility of a customized process versus the trade off in having a standard product being shared by multiple customers. Continuous Innovation also brings in anoter complexity in terms of operation which I will discuss a little later.

Recurring Billing and Payment: Given the fact that there are companies like Zuora having dedicated billing and payment solutions for SaaS applications, I believe one immediately understands that this is something that is completely unique to SaaS. One needs extreme flexibility in terms of billing a service. A lot of parameters can be used to bill and simple our right fixed billing simply doesnt work in the SaaS model. You need to genuinely show your customers that you are billing them purely on their usage and they can have the flexibility in controlling the usage if they want to. This is a very powerful point in convincing customers to opt for SaaS solutions.

I will explain the othe differences in the next post...

Technorati Tags     business,process,SDP,SaaS

SDO and SaaS

I have always been impressed by the Service Data Objects specification and the utility value it has when generic services interact with each other. By the very fact that an object can be percieved as a self-describing message makes service orchestration/choregraphy much simpler. The specifications are implemented by ASF with Apache Tuscany(C++ and Java) as well as IBM/Eclipse(Java) - Implemented along with the Eclipse Modeling Framework. Assuming a scenario where application can send messages in any format they want but as SDO objects which self describe themselves, other applications can sucessfully retrieve and interpret the data in a highly decoupled manner. The specification enables interoperability between applications in terms of data models existing between them.

What would be more interesting is to see if any of the SaaS application platform providers actually use the SDO specification for both their integration requirements as well as Data Model Extensions. Amazingly SDO is the perfect candidate to provide extensions to data models since they are self describing and therefore metadata driven.

Technorati Tags     SDP,SaaS,SDO

User Authentication in SaaS applications

I have been working on a SaaS delivery enablement platform called Agora. I have had some insights after talking to multiple customers and most of them have always hinged on one crucial function, namely, User Authentication. It looks like this is a very common problem.

I believe Salesforce has a feature where in, the customer can implement a webservice interface given by salesforce, provide the details and Salesforce can then call the webservice for authentication. This was primarily done to abstract out the implementation/integration problems of multiple types of authentication.

The other option ofcourse is standards like OpenID. Allow users to have logins based on OpenID Providers and then use the same for the SaaS application too. But corporate customers would'nt want their user accounts to be personal email accounts. But this definitely is an option if the application is end consumer oriented.

I dont think that Federation as in replicating the user details or having a secure VPN between customer and SaaS App Provider is the right way to go, the former completely unnecessary and the later very costly.

I think the Salesforce approach does make sense. For e.g. a corporate customer can allow its users to login into the SaaS application using their corporate credentials for the first time. This action then creates a mapping between the SaaS application and the corporate user account. Subsequently any further requests for authentication can then be done seamlessly. The specifics of the implementation coule be anything ranging from SAML assertions to simple custom API's. The crucial question though is the communciation medium between the SaaS app provider and the corporate. I think either a standard auth gateway at the customer premise if already available or a standard webservice implementation like what Salesforce does.

Technorati Tags     SDP,Authentication,SaaS

SDP and Backoffice systems

A net native ISV who builds a service and delivers it on-demand basically builds a new LOB. There are no legacy systems and the operations are confined to managing the infrastructure and adhering to the SLA's promised. However, for an existing ISV who has hundreds of existing customers, resellers who are managed by an existing suite of backoffice applications, creating and enabling this new LOB becomes a big problem.
Since the delivery mode of the existing software is following a specific route, integration for the reason of book keeping is absolutely necessary and most of the departments resist changes to th e existing process of order, invoice and payment.
Therefore the platform that is used to deliver the on-demand service would have to integrate with the existing back office systems, with data coming from back office systems to the platform or vice versa.
It will be interesting to know if there are any existing large ISV's who have gone through this process and if there are any interesting learnings that they have accumulated in the process.

Phew! its been a year without blogging

Its one of those "I cant say why I did it" thingies. Its more than a year since my previous blog spot and the date is definitely not an indication for my stagnant mind :) I've been doing the usual, trying to be on the bleeding edge, trying to understand new markets, understand SaaS in particular, Web 2.0, SOA, Architecture and some stuff. It was a pretty normal year. I got married too. and you know the usual.... whoa! I got married! It seems kinda odd repeating that to myself. I am a married man! I feel like OLD? :)

Well that apart, I think last year was important in many other ways. It was the yet another year for industry consolidation with companies running amock with M&A's, re-inventing themselves, creating new technologies, churning out new stuff. There is a plethora of Hot Technologies that have gained significance. GWT, RoR, Flex, JavaFX, Scripting Langs, Mashups, platforms and all said and done there are still people who think that Hibernate is bleeding edge:) yeah may be they should feel proud of C!

I have kind of categorized blog posts that people tend to write when they simply cant think of anything else to do..no writing reflections is not one of them ;). They either write stuff like "How to write a Resume" or "Top 10 items for the XXXX" or "Agile XXXX" or "Why Agile Sucks" or "How to improve software development". PPPPPlease.... it all started with Steve Yegge , the funny blogger as I call him started lashing out at Agile. And the band wagon started with Anti-Agilists being a cult theme. You are cool if you thump the agilists! No doubt Steve had some very valid and some very funny points that I completely agree with. Infact he kind'a crushed, and poured mud over Agile's grave. Whats the use of digging up the body and thumping it left right and center? :)

Then all of a sudden people had no idea how to write a resume, atleast thats what the bloggers thought! The rantings about resume continued. Everybody looks at ateleast zillion things at multiple stages in the resume. No use writing about it in a blog, you actually require a 10 volume book for it. The simpler approach is to simply be yourself and make the resume reflect you. You will end up someplace where people actually like you simply because they thought your resume makes sense!

At the end of day the only thing I can think of is, blogs have their advantages and dis-advantages. You give the pen to everybody, you better be ready to get a truck load of S*** from most of them but feel happy that the couple of folks who wrote somethings that made sense improved your knowledge some way!

Coming back to what I did last year, I have been actively looking at SaaS, architected a platform for SaaS based service delivery and did some cool Web 2.0 work with GWT and man I love GWT. We even used GWT for the SaaS Service Delivery Platform and it really works wonders to non-JavaScript guys trying to make sense of what the heck JavaScript is all about. Of course you need some JavaScript skills along with some hard core troubleshooting DOM of different browsers with Firebug and IE Dev Toolbar. But I am happy with GWT and am evangelising it like hell in my org!

SaaS seems to be an intersting market, with its own challenges. A part being application architecture, a part being supporting platform architecture and of course the Operations Architecture. You need to get everything write or you are screwed!

Have been reading Gianopaolo's and Micheal Chong's Blogs since they started to get some insight into what they have gone through. They are pretty cool guys.

Last year also was the year when I got some first hand experience with building and understand SaaS. The Appliance Model seems to be a very interesting compliment to SaaS based delivery and most companies are realising it.

Its been a quiet year with lots of value adds to me and from me to my org. I probably am beginning to better appreciate the future of this business being driven by SaaS as the primary model of delivery with augumented offline delivery modes like Google Gears and Appliances.

Integration with inhouse as well as standard on-premise models as well as on the cloud integration, standards for compatible data exchange between Service Providers, are all things that would evolve over the next years.

and I will be keeping track....