The Twitter Question

There used to be a generation which thinks ideas can be stolen. A closed generation, a generation which thinks sneezing can be patented and that would be cool. That generation is slowly dying. Today's generation wants to share. Share what they think, do, feel, opine, laugh and cry about. Believing in the fact that knowledge silos are passe' and tomorrow's world will live by collaborating openly than we do.

I have my blog, I am a member of orkut, facebook and LinkedIn. But nothing prepared me to what twitter was. I wanted to express why twitter was "different" for me. Orkut and Facebook were places for me to catch up with friends. It was always about people I know though most people think differently, I consciously ensure that only people I know are in my circle. LinkedIn was a way of connecting professionally. Being able to connect to both friends and strangers by virtue of common interest or the fact that the connect will be helpful professionally. At the end of the day, I used Orkut and Facebook as a means of ensuring I am upto date with what my friends are doing. My blog had sporadic activity from me since I never felt I can keep writing paragraphs.

Facebook and Orkut encouraged Micro Blogging is some sense, Facebook using updates and Orkut using scraps...but I have never felt the urge to "update" fb or orkut for I dont know what reasons. Enter Twitter.

When I first registered to twitter I was a confused soul. I did not know how I am going to use it or how it will really matter. Infact I didnt understand one bit of what was happening when I first entered, when my cousin told me it will take time to get used it. For me, the single most important change I had to encounter was the fact that twitters rules were different. Here anybody can follow anybody, the darn thing was completely open, unlike facebook or orkut which was personal and restricted and had friend requests. I mean you can read the CTO of cisco wanting to hug her kids in the same breath as visiting Russia for a tech deal. You can read about the CEO of HCL wishing best of luck to kids writing the board exams in the same breath as talking about the indian budget and our hockey team.

For the first time I saw how open this was. But not everybody uses twitter for the same things. I have seen over the past weeks people using it primarily for professional reasons. I have seen PR consultants and Social Media gurus, tweet up links. I have also seen real time updates on the The Carlton Towers fire, Sachin's double hundred and people just tweeting about life, love and their dog all mixed and all confident that their thoughts matter and people respond! 

I think the most important difference between a traditional blog and twitter is not the length. Its the realtime feedback that you get. You know people are reading it and when its 140 characters people really want to say something. This is EMI for Blogs!

The most significant fact is that I quickly formed a circle of people I have never seen. I tweet and they respond and its as if we have been friends all along! I have @omniprasan my cousin who will be tomorrows CEO Entrepreneur @mad_nad who breaks ice with me whenever she is pissed with her cold, @PPrakash a buddy who made me feel at home from day one, @surekhapillai who refuses to reply to even one tweet:), @suja_s who is incredibly polite, @miilee who finds me whenever she searches and whole lot of others like @sudhamshu, @vidyavenkat,@DrDheep...the list goes on. None of these people know me personally. But we know each other! This was the single most important lesson I learnt. I had access to people from various backgrounds who were ready to help me. 

I havent fully grabbed in entirety what twitter will be tomorrow. But I already know that twitter is a door to a different world. A world where people share fearlessly, a world leading to tomorrow.

The Change in the rules of the game called IT

There is an interesting shift that is happening in terms of IT as a whole. Its as if the tectonic plates are moving really fast and this is going to cause a huge upheaval some time in the next 5 years. The fundamental driving force behind this change is the availability of a reliable public network a.k.a internet. It has taken some time for me to understand the overall impact that this is going to have on the way IT is today and it was good enough to wake myself from my blog slumber and write this post.

I know a lot of people are talking about Cloud Computing, Public Clouds, Private Clouds, Platforms as a Service and SaaS applications all in one breath though I am sure 90% of the people dont even know what the heck it is. I also know that the industry pundits are still grappling with the right definition of Private and Public clouds with one set saying there is no such thing like "Private Cloud" as it wont provide the scale of optimization and the other set saying Corporate will NEVER agree to push their IT into the public world.

There is another thread to this. With the "on the cloud" a.k.a SaaS applications coming up in tens every month and the fact the tomorrows IT needs will definitely encompass applications on the cloud, the Platform as a Service will eventually force a technology shift and the way software applications are architect-ed and designed. Integration factors to the applications in the cloud and in house applications are a reality and the problems will HAVE to be solved. There is no other way but to solve that problem.

I do see a "Private Cloud". Only not in the sense it is understood today. I am beginning to see the IT outsourcing providers smell something here. I see them beginning to realize that they are already providing services to thousands of customers, these corporations will themselves not be able to do "private cloud" and still get the optimization.

I think the rule change has come. IT Service Providers will have to deliver a lot more value that they do today. They will be FORCED to shift to delivering services on private clouds that they host and operate. This will help the IT Service Companies deliver the shared services optimization to the hardware just like they do in software simply because of their scale. Corporations will eventually have to agree to THAT model. The fact that their IT services vendors can host their apps and deliver IT end to end over a "private cloud" providing them the necessary security cover.

The next logical step for the IT services companies is to learn to be Data Center providers like Amazon. Amazon will NEVER be what the IT Service Providers CAN be to companies given the fact that they are already aware of their customers security policies and have learned to work with the restrictions. The fact that the hardware and software  services can be commodatized and delivered is something we always knew. It is just that we are at the right tipping point with technology enabling the need.

Those who leave out on this opportunity will have to close shop. This is because software outsourcing is not going to bring in tomorrows revenue. The ground has started rumbling. I can hear the shift..can you?

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.