Sunday, January 4, 2009

New evidence of "Recession Proof" SaaS

My proximity to New York has given me a close up view of the economic problems we are facing. I have many friends and neigbors who have either lost their jobs in large organizations or have problems sustaining their small businesses.

Having just returned from a trip to New Zealand, its been interesting to experience the general morale of NZ vs. New York. The problems are far more visible in New York at this point. That may change over time.

Anyhow I digress..

For the last 18 months, plenty of bloggers have talked about how SaaS will perform in a recession, now the "proof is in the pudding" so to speak.

Can SaaS really outperform traditional On Premise Software solutions in such a challenging environment?

Sramana Mitra writes that


Salesforce.com (NYSE: CRM), the leading SaaS vendor, yet again, reported strong third quarter results on November 20 that beat Street estimates in an increasingly gloomy economic environment: yesterday the National Bureau of Economic Research officially declared that the U.S. has been in a recession since December 2007. Despite the challenging market conditions, Salesforce.com is set to cross the $1 billion revenue milestone. I believe the SaaS sector is relatively recession proof, and Salesforce.com’s performance this quarter is more evidence of the sector’s strength.


Now this has to be concrete evidence of the robustness of SaaS in all economic climates.

Admittedly Salesforce.com is the most dominant On Demand company on the planet, and by traditional comparisons its in the top 10 largest "software" companies in the world (not that Salesforce.com really wants to be labelled a software company).

However the core strengths of SaaS should help the smaller SaaS vendors as well. I am not saying its going to be easy for any organization, but the strengths of SaaS for an end user organization should at least give some sort of advantage when competing for a job

These strengths include
Lower Cost of Ownership
No internal technical resource requirements
Operational Expenditure vs. CapEx.

All of which are significant benefits during tough economic times. In fact these could generate revenue opportunities for SaaS. In particular within organizations who have had layoffs, have a hiring freeze and spending cuts, SaaS could well be a cheap way to provide services within these restrictions.

Not all SaaS vendors are going to survive through these times, but in comparison with traditional on premise vendors, I truly think SaaS has key strategic advantages which should see it in good stead.

An Update

Dear Readers,

Its been several months since my last post. I found myself prioritizing revenue generating work for the company I am currently involved with,
over most other things including my blog.

Well like many of you out there I am glad to see the back of 2008 and since 2009 has just commenced, I have decided to relaunch my blog afresh. I will continue to write posts to this blog, but am also looking at revamping how to deliver my blog posts to you. this will evolve over time and I will let you know when its ready.

Please be on the lookout for new posts, and I thank you for your patience.

Monday, July 21, 2008

There is no such thing as "functionally complete"

I just completed revisions to our Software Development Methodology handbook. It got me thinking about how many times I have written something like this and how its changed over the years.

As would be expected from a Software as a Service company, we approach things from an incremental development and update perspective.

We look to deliver new features every 6 to 8 weeks. We have a product roadmap which is a living and breathing organism. At the beginning of each year, we sit down (representatives from Marketing, Client Services and R and D are all there).
We look at the Roadmap and work out what is needed for the following year.
Once we satisfy this objective we then proceed to work out what is needed in the first 6 to 8 week iteration. As we release each cycle, we review the roadmap and determine the requirements for the following cycle.

This is the reasoning for my post title. At no point do we ever say our product/service is functionally complete. Back in the days of on premise software, we would pursue the venerable Waterfall approach. We would map out and plan for a development project of 12 to 18 months, aiming for at most 1 release per year. Users wouldn't even get close to the new version until it was close to being "functionally complete" as a product. I would remember our customers/prospects getting all excited by some great new feature we would show them in a presentation, but a year is a long time in business, and by the time the product update was officially released, all the positive "vibes" and excitement of the initial announcements would have truly been forgotten.

By having 6 to 8 week feature updates, we are continually registering small wins with our customer and prospect base and keeping strong the goodwill of those customers. It also makes the term "functionally complete" an anachronism. A service should always be evolving and adapting. If you wait for 12 to 18 months between releases, your product will die a slow death.

Tuesday, July 1, 2008

Google building Business Apps

I read a very interesting post by software engineer Sergey Solyanik who tells his story of leaving Microsoft, going to work for Google and returning to Microsoft.


Its a balanced account of the reasons why he returned to Microsoft, What caught my eye and got me thinking was his opinions on the challenges Google has in building solutions targeted at business. Google along with its primary search products has built a series of popular "free" products. By being "free", Google enables its development teams to be more "agile" and release code to production environments frequently, however accordingly there seem to be fairly frequent introductions of new bugs and outages but by being "Free", the user base is also more accepting of these issues.

This would appear to be a major inhibitor to Business market dominance. As Google begins entering the business market, the dynamics totally change. You have to build apps which are an integral part of running a business, not just "free" nice to haves, otherwise you will need never get widespread adoptance. Businesses by their very nature are far less forgiving of problems and as such would prefer to pay to ensure adequate quality,reliability and support are in place for any products they choose to use in their business.

Technical Support for business with SLAs in place does not currently exist at Google.
This got me thinking about the Salesforce.com/Google Apps colloboration. This is a pretty smart move by Google. I have to think this would benefit Google more than Salesforce.com though. Google partners with a company with huge credibility in the business world and they also get to leverage the infrastructure for training and support of customers that Salesforce.com have in place. In a way, Google is outsourcing these functions to Salesforce.com.

This is all good for customers who are using Salesforce.com and Google Apps, but what about the others who don't use Salesforce.com but want to use Google Apps with agreed upon SLA's and support?

Its my guess though that Google is not going to setup huge Support and Client Service Departments, I think they will continue with outsourcing this part of the business and utilizing business partners.

Salesforce.com Data Centers are also more focused on running business apps with high percentage uptimes and SLA's in place. I am not sure how Google's distributed server farms will handle business applications at guaranteed Service levels.

Google are certainly big enough to make it in the Business Market, but its not going to be a quick win.

Sunday, June 1, 2008

Is Microsoft Silverlight ready for prime time Business SaaS Development?

There is no doubting the success of Adobe's Flex development product set in the SaaS Web 2.X world and there is no doubt with the release of Microsoft Silverlight Version 2 beta, Microsoft is attempting to head the same way.

Silverlight 1 was clearly targeted at simple website development with video streaming, animations and javascript/Ajax dev framework to enable a richer web experience, but it wasn't close to being ready for business application development.

I spent some time researching SL2 in my continuing endeavours for improving SaaS user experience. It introduces some major functionality including

1. A cutdown .NET managed code environment as an alternative to Javascript. This will be an attractive feature for the literally millions of .NET developers out there.
2. Ability to generate and use proxies for consuming SOAP and RESTful based services (A critical requirement for Business applications who need access to hosted databases).
3. More standard controls such as listboxes and datagrid.
4. Linq to SQL

SL 2 is definitely a huge improvement over SL 1 but there are still some major pieces to the puzzle missing.

1. Certain key controls are yet to be released including a tab control. Tabs are a very common metaphor nowadays in business apps. I cannot seem to find a combobox implementation, the most basic of databound controls.
2. Linq to SQL is great for handling collections of generated proxy data objects but what about situations where the data schema is not known at compile time, for example CRM and Business Intelligence Applications
3. Third party vendors are still building their Silverlight components, vendors such as Infragistics, and Telerik having announced their intentions to release but have yet to do so.
4. Cannot merge external resource dictionaries which makes it difficult for dynamic skinning.
5. No concept of a right click. Which makes it difficult to build right click context menus. Can be done by Javascript hookups, but is not a default behavior in managed code form.

So is Silverlight ready for SaaS? Well, due to its flexible UI design foundations (XAML) which enable you to build your own controls and the new capabilities for managed code development and Service consumption, the answer is yes (if you have time to work around the controls that are lacking). But I suspect that many ISVs will wait before adopting Silverlight as their primary UI platform for delivering SaaS applications, otherwise they risk reinventing the wheel.

Tuesday, May 20, 2008

Preparing for the Business Cloud

An interesting interview with the head of Microsoft Office products, Chris Capossela provides a clear indication of a couple of things.


  1. Microsoft is investing heavily in Cloud Computing
  2. Cloud Computing is a serious player in not just the consumer space but in business also. ( And not just in Cloud CRM which Salesforce.com leads by a country mile, but in general business applications also)

According to this interview,

Microsoft Corp (MSFT.O: Quote, Profile, Research)
sees tens of millions of corporate e-mail accounts moving to its data centers
over the next five years, shifting to a business model that may thin profit
margins but generate more revenue.


Microsoft is adding 10,000 servers a month to its Cloud focused data centers. Thats 10,000 servers a month which apparently is equivalent to the entire server count for Facebook. Pretty impressive numbers.

The company said Coca Cola Enterprises Inc (CCE.N: Quote, Profile, Research)
signed up 70,000 seats for Exchange Online, switching over from IBM's Lotus
Domino system

70,000 seats for any software business is a major win, its a true Enterprise sale, and an accurate indicator of whats happening with the business cloud.

The article does indicate however the "Fence sitting" of Microsoft. They see themselves differentiated from traditional service players such as Amazon and Salesforce.com, because they still offer On Premise solutions.

I can see why On Premise for Enterprise, may still be preferred for some large scale multi country integration heavy type applications, but surely Microsoft must see its Email solutions heading up into the clouds? Email solutions don't differ from customer to customer which makes implementation and setup costs very low if not nil.

I know, I haven't used a locally hosted on premise email system in years, and don't see myself ever doing so again.

Its an exciting time as we see large scale vendors adapting to the presence of Cloud Computing in business.

Saturday, April 19, 2008

A Microsoft Cloud Database. Now its starting to make sense.

I apologize in advance for this fairly technical article, but I wanted to post about this to highlight that Microsoft can produce some really impressive stuff on the Development side of things, even for SaaS.

It was announced fairly recently that Microsoft was planning to release a cloud version of its SQL Server DBMS, called Microsoft Data Services, (Whitepaper found here.).

There are a number of major players in this arena, including Google, Amazon and even Intuit but that isn't the focus of this blog post.

Despite Microsoft's sometimes "perceived" less than committed approach to SaaS and Cloud Computing in general, they always seem to come up with some great additions to their development platforms.

Their latest .NET framework 3.5 Platform introduces a component called Linq or Language Integrated queries. This component which is based upon Functional Language constructs and Lambda expression building blocks essentially provides a SQL language capability embedded in the C# and VB.NET language sets used by many. It provides an abstraction layer hiding database specific language constructs from client apps.

Example:

var query = from p in Contacts where p.LastName=="Wing" select p;


Linq can be used against all types of collections, and in fact the building blocks of Linq, Lambda Expressions and extension methods also simplifies many scenarios where you have to iterate through collections. In instances where you would traditionally write multi line code with a FOREACH statement you can replace with a single line.
string[] contacts= {"Troy","Jane","Kim"};
IEnumerable contactList= contacts.Select(p=> p += " Wing").
.Where(q=>q=="Troy");
So back to the reason why I am blogging about this and why its "starting to make sense", these technical features which can make developer's lives a lot easier, actually have a more significant and strategic use. They will form the development platform for ISV's to build apps against Microsofts Cloud Database. Because Linq is Database agnostic, it becomes the perfect tool to use in the SaaS world when building Multi-Tenant Client apps. It removes the need to write complex database specific code anywhere in your app.

It will simplify development, and provide the ability to bring to market a SaaS product requiring a database backend a lot more cheaply and quickly and perhaps open up the SaaS market to smaller organizations who normally couldn't afford to build such an app.

It would have taken several years for such significant features to be designed and implemented by Microsoft, so although I don't know whether this was intentional or not, Microsoft has been seriously thinking about architecture for Cloud Computing for quite a while.