Moving off blogger

I finally got around migrating off blogger. Don't get me wrong, it's a pretty good non-intrusive platform, but I rather have more control of my own blogging platform and especially my data. Since I am currently renting VPS with slicehost I thought I would just use another virtual host for my blog.

So, if you have been reading my entries, please update your bookmark to here, and your feeds to here.

Bye Blogger!

The B2B of Mashups: Mashboards

I came some time ago across an interesting buzzword, mashboards, which is really starting to show that at the end of the day what really matters is systems integration. Where we had mashups in the B2C world, we now have mashboards in the B2B world.

Mashboards will become a flourishing area for SaaS. They target the SMB market and address exactly the customer pain. I can see how we'll be hearing about SOA for web in no time, or web-driven business processes, ... Let's wait and see how the analysts call this one. For the time being I'll call them mashboards.

The future of hosted software

As we discussed originally while looking at Web 2.0 software-as-a-service business models, we saw how hosted software is not a competitive offering for mid- to large companies over 500 employees. New research by Quocirca and Forrester now comes to a similar conclusion, and they add that there is a grey zone between 250 and 500 employees where it's not clear the value in hosted services. Quocirca concludes saying that hosted services are rarely cheaper than in-house services, overseeing the 5.7 million businesses in the US under 500 employees. I am still to read both research reports to understand the full details.

Additionally, these studies seem to use current pricing models, such as the one from salesforce.com, but miss some of the points raised by Mark: the utility of hosted software goes well beyond cost (the focus of Quocirca and Forrester research) and includes less tangible things such as training time, added security, and productivity (as already commented by Steve Garnett, of salesforce.com, when asked about these two research reports). Also, as we discussed while comparing the Web 2.0 to the "old economy", it will become necessary for hosted software providers that want to remain in the market to start providing free services, adding premium services, leveraging information lock-in and enhancing the value of the intangible benefits such as usability, ease of upgrade, automatic security/patch management, etc.

Web 2.0, The New Old?

There seems to be at least 17 startups taking on the A-Team of the desktop applications, and possibly another hundred thousand teenagers creating their own little Web 2.0 application-du-jour in communities like entrepreneur extraordinaire Mark Andressen's Ning.

Since the software-as-a-service business model is mainly only attractive for smaller to medium companies, why are there so many web 2.0 applications popping out everywhere?

I believe the catalyst has been a generational change. Web 2.0 is not anymore an emerging phenomena only found among geeks playing with XML, and asynchronous HTTP requests. The generation of young adults in their early- to mid-twenties have grown using the internet as a routine. They learned how to collaborate online using Yahoo!, how to use Google to find the solution to their assignment or homework, how to download MP3s using eMule, etc. and most importantly how to skim through the rubbish to get the very simple: content. The internet is just one more thing they use in their lifes, just like a phone. Given that they have grown on it, doing homework and making friends on the web, it is the collaborative aspect of the internet what possibly makes software-as-a-service interesting. It's Wiki-Extreme if you let me put it that way.

Okay, so you have a market. You have entrepreneurs. How do they meet each other? Most of the startups doing Web 2.0 services will fail (I hope this is not a surprise!) and only those that are able to see beyond the collaborative, minimalistic aspects of the software-as-service business model will be able to survive. Simple usability, Apple-like design and aesthetics, and a beta-always badge are requirements to be in the Web 2.0, but fulfilling functional requirements are at the end of the day what makes an application work. Collaboration is fine, but not all business processes are suited for collaboration. So, what's the new old?

• Information lock-in is the biggest simple asset these startups should leverage. They will need to lock in their customers into their proprietary document/workflow formats, to avoid switching. It's a market with almost no barriers of entry, and the only protection they will have is information lock-in.
• Web 2.0 software-as-a-service should offer the products for free right now (yes!). The marginal cost for you to give the application to an additional user is close to zero, so your only short-term objective should be to create a large customer base, bigger than your competitors. As the market develops, the number of players will be reduced, but you will have your customers locked-in.
• As the market matures, you will need to start making money (uh?). Seriously, don't expect to make a business out of AdSense! So how do you make money? Your best returns will come from premium services targeted those companies to who software-as-a-service is borderline to not being competitive anymore, and would be tempted to go for traditional solutions ala Microsoft Office. For these customers you will need to offer the extra mileage: better backups, better training, consultancy, etc.
• Price accordingly: free for most, pay for a few. The more free customers you have, the more the few will be willing to pay to ensure format compatibility.

These are nothing but the good old economical principles that apply to the web 2.0 information economy. Not surprising.

Transport and Housing: Chicken and the Egg?

The British policy makers seem to have a tendency to first develop land and then put suitable transport infrastructure in place. Obviously, a significant factor for people choosing their next residence is road infrastructure and, to a lesser degree, public transport. Current government plans include creating over 100,000 new houses in regions like the South East, partially to release some pressure from the already overcrowded London. In cities like Ashford, in Kent, the local job market is almost non-existent, and the only population that can potentially be attracted to these new developments are London commuters which move their residence but keep their jobs in London.

The authorities seem to forget who they are really promoting housing for: without suitable public transport, London commuters will not chose to live in Ashford; without an inflow of public money and incentives to businesses to relocate to Ashford, there won’t be any job creation. The government policy is however to invest in infrastructure only after there is housing demand. Obviously there won’t be any housing demand since there is no infrastructure for the London commuters.

To be completely fair, some level of investment is being made in road infrastructure. Road construction creates local jobs and gives a huge inflow of construction money to the regions of Britain, boosting local economies with public money, and providing a fertile environment for new businesses, thanks to public money and modern transport links. Altogether, road infrastructure investments create significant public wealth and are a powerful vehicle to redistribute wealth.

Road infrastructure investments however result in increased flows, and surprisingly do not reduce traffic jams but in the very short-term. Quite the opposite, new motorways end up creating more traffic congestion, measured as person*hours of wasted time to the economy. While road infrastructure investments have clear benefits for local and regional development, they don’t quite help to attract new population since road infrastructure does not make a commuter’s journey significantly shorter.

The British authorities should consider investing more in public transport, and less on motorway expansion. Without better public transit, it will prove impossible for the authorities to introduce the planned road pricing and ramp metering changes; at least not without becoming a political suicide.

Most London commuters use trains, often their only choice. The railway system offers very poor service levels due an ageing and undersized infrastructure, and it requires multi-billion investments to be fit for purpose. Unfortunately it’s not only a matter of money: the railway system is very hard to scale around London given the scarcity of land. It proves to be a very unpopular choice to demolish a voter’s house!

Giving these constraints, British authorities should really look of infrastructure as an instrument for local and regional development, and they should clearly consider alternatives such as High-Occupancy Vehicles, Fast Lanes, Commuter Bus Services, and potentially faster rail commuter services.

Pricing Models for Web 2.0 Software as Services

The recent advent of Web 2.0 no-software start-ups like 37signals, salesforce.com, Writely, etc. is getting plenty of attention by the media and VCs alike, but I have not seem much about the pricing model of these no-software business models.

The basic idea, repeated all over the place in Web 2.0 start-ups, is that one can develop very rich user interfaces using thin client technology. Instead of installing a local copy of Microsoft Word, you use Writely. Instead of installing Siebel in your enterprise as a CRM solution, you use Salesforce.com. And so forth. Even Microsoft's Bill Gates, highly concerned about the future of Microsoft in a world of "applications built from the grassroots" is putting forward an online Microsoft Live CRM service.

The advantage of using online solutions are allegedly savings in infrastructure and support costs. But is this really true? Will individuals and business of all sizes alike chose online services versus an offline dedicated solutions? Obviously not, so who is then the target customer? Or rather, when will a consumer chose online vs offline applications?

An informed consumer (be it a home user, a web designer, or a CIO) will make a choice based on the expected utility he gets as a consumer from the software. He will compare the utilities and chose the one that seems most likely to suit his needs. The expected utility for each option, online or offline, will surely include quantifiable factors, such as software price, downtime costs, support costs, infrastructure costs, etc. as well as perceptions such as privacy, reputation, etc.

I prepared a highly simplified utility model that I could use to bring some light. In this model the only factors I considered were:

• Software price, for an offline solution, expressed as a monthly depreciation cost as a function of the number of employees. For solutions that require systems integration and professional services, I have diluted the cost of consulting in the total price of the solution, which then gets expressed as part of the monthly depreciation costs per employee.
  
• Service price, as a monthly recurring charge by the provider as a function of headcount.
• Infrastructure costs, for the offline solution, usually comprising storage, servers, backup, etc.
• Service support costs for the offline solution, to support the local infrastructure costs.
• Cost of downtime. I have assumed local class 4 availability in each domain. This translated into 0.01% downtime for offline software, 0.01% to local network, 0.01% to the local ISP, 0.01% to the provider ISP, and 0.01% to the service itself.

I have run the model with existing data for both "consumer applications", using 37signals Basecamp and Microsoft Project for pricing data, and for "enterprise applications", using Siebel and Salesforce.com for pricing.

The model yields interesting results:

• For both consumer and enterprise applications, the break-even point where the software-as-a-service is not competitive anymore is somewhere around 500 employees.
• The key differentiation between the utilities derives from infrastructure and support costs. For small to medium businesses, the cost of a dedicated and under-utilized infrastructure and service support personnel is prohibitive, and only large companies are able to realize economies of scale to make offline support viable.
  

We can clearly see the validity then of these start-ups, since in 2003, there were 5.7 million businesses in the US with less than 500 employees, at an average of 10 employees per firm; and 16,926 businesses with more than 500 employees, at an average of 3,300 employees per firm.

These 57 million businesses with 10 employees cannot afford the costs of dedicated infrastructure and service support, and are better off to chose an online application. For an average of 10 employees per firm, the model yields a cost of approximately $5,000/month for an offline solution, versus a $150/month for an online solution. $4,850/month of infrastructure and support savings surely justify the consumers choice.

As a side effect, the model yields a potential market size of approximately $10 billion for the Office applications, possibly close to $50 billion for the standard applications used currently in small and medium-sized businesses.

To conclude, it's interesting to note that the online software-as-a-service business model is a side-effect of an underlying consumer pain: lack of secure shared infrastructure.

Taking the Rails to Django

While developing our trading application, I have come across two key things Rails does not have:

* Transactions. Rails does not offer distributed transaction management. This does not bother me much, since I am not a fan of having transactions span across multiple datasources. However, Rails does not offer cross entity transaction management on a single datasource for unrelated entities. The Rails model works well for ensuring autocommits on parent-child relationships, but anything beyond that requires extensive work and bookeeping in your controllers. For most jobs, the Rails model is enough, and does the job. It actually does the job pretty well. But there are jobs, such as updating multiple trading and position tables where Rails is not the right tool.

* Security. Rails is absolutely agnostic of security. Authentication, authorisation and Access-Control Lists are foreign to the framework, by design. The whole plumbing required may become daunting, and while there are engines and plugins out there doing part of the job, I truly hate taking ownership for the security bits within my application.

Localisation and internationalisation is yet another third a bit weak in Rails, but I am yet to have true requirements in this area to be able to give an opinion.

Anyway, Django looks like a promising alternative. It offers both more comprehensive transaction management support and a complete security model, with the whole plumbing being in the framework itself. Whether it will fit the shoe, we'll see as soon as I write the order island book.