Handicapping PaaS

I was thinking of cooking up a post on platforms in the cloud when Abhijit Dubey, Junaid Mohiuddin and Aadarsh Baijal at McKinsey & Company (and several pundits by now) beat me to it.

The report outlines this new market for SaaS platforms that provide some combination of:

1. Traditional software stack components (e.g. OS, app server, DB)
2. Unique SaaS components (e.g. billing, SaaS dev tools, )
3. Hardware as a service (pay by the drink CPU/storage usage)

The report goes on to categorize different PaaS plays into categories based on what cocktail of components they offer today (e.g. Amazon’s EC3 is just hardware whereas Force.com is a full dev environment and runtime).

Good. Fine. Agree.

Then the report goes onto describe how lucrative the market for PaaS will be based on the notion that lots of SaaS ISV’s are getting started and much of their revenue will get paid back to the PaaS vendor for providing the infrastructure, with 30% of the PaaS value then getting passed onto the underlying database vendors and the like.

Strongly disagree. More on this later.

The paper goes onto make a few more predictions, namely:

1. The data center/rack space vendors will coexist with the Amazon EC3 types for a while as they serve somewhat different needs.
2. On premise development platforms (e.g. J2EE, .Net, etc) and on demand development platforms will start competing immediately.
3. Application focused PaaS offerings will fragment into several purpose built sub-markets (e.g. for UI intensive apps vs. transaction intensive apps)

More disagreement.

I think the team does an excellent job cataloging and categorizing the various PaaS plays in the market but mis-reads the market and competitive trends that will drive the evolution of these businesses.

In enterprise software, the real platform money is in the enterprise in-house developer, not the ISV.

In fact for most enterprise software vendors, the ISV is a break even venture at best. This is for several reasons:

1. ISV’s are cheapskates. Most of them are losing money or breaking even themselves and so they cannot afford to pay much.
2. ISV’s are technically savvy and so they are very savvy platform shoppers.
3. ISV’s are fickle. They are afraid of holdup costs and so they want to play on multiple platforms at the same time.
4. ISV’s go out of business often.

Basically champagne tastes on a beer budget. The main reason why platform vendors cater to these developers is they create ubiquity for the platform which encourages the enterprise vendors to pay the serious money for the platform. The checks that Citibank’s CIO writes to IBM Websphere dwarf what any ISV will write.

So focusing on who will win the ISVs is (nearly) a moot point. A PaaS company whose business model is built around monetizing ISV customers will most likely change their business model or go broke.

PaaS offerings of all types and flavors will compete with traditional on-premise development environments and runtimes for the hearts and minds of the enterprise developer. If you look at Force.com and Coghead for example both focus their marketing squarely at this audience.

It is very early days, but I think development and application oriented PaaS offerings will face an uphill battle to win the hearts and minds of the internal IT developers currently using WebSphere, .Net or LAMP. The simple reason being customers who buy SaaS are usually choosing to outsource some IT project they find to be distracting or problematic while choosing to develop in house is in many ways a choice to embrace a project that they believe is important or solvable.

This all sounds like I’m a PaaS pessimist when I am not entirely. More to come in my next post…

Determining success in software product development

My blogging has slowed to a crawl in the past few months. This is in large part because my group (SAP Governance, Risk and Compliance) has been on the verge of releasing two new versions of its flagship products Access Control and Process Control. Like a marathon, it’s that last mile that hurts the most.

During this past year and especially during the past few months, I’ve spent a lot of time thinking about what defines success when one delivers software products. It’s very difficult to know when to say “job well done” and I think many experienced software executives still make this call incorrectly.

False Measures of Success

If you work in software, you can understand why this assessment is hard. Software development is a tricky activity to measure, and the measurements you can make are very context dependent. Thus results are typically useless when comparing one product or release to another.

For example, you cannot say you have been successful if you “delivered the product on time.” After all it is easy to deliver a product on time if you cut back on scope or skimp on quality. This basic product delivery loophole is a byproduct of what project managers refer to as the “iron triangle” of scope, cost and quality. To move one variable up you must decrease the others and these relationships are for the most part fixed.

You also cannot say you are successful if you “delivered the product on time, on scope on quality.” While this sounds impressive on the surface, it is really more a function of good expectation management. Time, scope and quality are things you set targets for (i.e. fixed values). Whether you arrive ahead of or behind a target value has a lot to do with the target itself. Delivering on time, on scope, on quality is more often the result of a successful negotiation on the part of the project manager.

Any Hope to Judge Success?

I’ve come to understand that there are actually two triangles and, given the right timeframe, neither one of them is iron.

Let us call one the “execution triangle.” This is essentially the same stuff as the iron triangle: scope, time/resources, and quality. In software, this triangle is truly iron for short periods of time (e.g. 3-12 months), but you can push and pull at it when you look beyond that time horizon as you have more freedom to change processes, practices and technologies.

The other more strategic triangle is the “context triangle.” It is comprised of change, waste and innovation.

Change – how rapidly is the context changing while the product is being built? If you decide to simultaneously change the architecture, the people, the technology and the requirements, the size of the execution triangle will get very, very small.

People – how many good people do you have on the team? Product managers that write first rate requirements? Engineers with years of experience with the tools and technology? Architects that are not astronauts? If you want to accept more change with the same level of waste, you need better people on the team.

Waste – What percentage of the time and money you spent on release was put to productive use (i.e. working code that someone wants) and how much was lost to confusion and dead ends? If you want more change with the same people who built the last release, you must accept more waste.

The relationships between the elements of the context triangle are also fixed (e.g. the same release with a higher rate of change will result in greater waste). In addition, the context triangle drives the size of the execution triangle. If you have great people, low waste and a low rate of change, you can deliver some 5-10 more functionality with the same amount of time and same level quality as you otherwise could have.

Many people, executives in particular, are willfully blind to the context triangle. They do not want to believe it exists because it takes away strategic choices. To understand the context triangle is to understand for example that one cannot enter a new market with a new product on a new technology platform with a newly hired team.


So What’s Your Point?

Like most things in business, it is important to distinguish between lucky and good, circumstance and success, however tricky it may be. And so, true success in software development is the execution you achieve given your context, because the context is almost never under your control. Change, waste and innovation are the cards you are dealt and how much scope and quality you derive from these circumstances are how you played them.

P.S.

If you're in the market, please take the time to check out the newest releases of SAP GRC Process Control and Access Control. They’re both excellent. I should know :-)

The enterprise software industry in 2007

Happy New Year to everyone!

I wanted to jump into 2008 predictions but only seems fair to review my track record from 2007. 2007 predictions included:

The last of the SOA middleware vendors get merged, acquired or shut down

I was almost completely wrong here. Savvion is still around as is Amberpoint and the rest of the gang. Above All Software seems to have shut down which was a real pity because Roger Sippl is something of a role model for me.

No open source companies will exit throughout 2007

I almost got this right but the acquisition of Xensource by Citrix killed this one. Much like Red Hat’s acquisition of Jboss, I can safely predict this deal will never turn accretive and will not transform the acquiring company’s prospects.

Oracle will acquire one or more sizeable application software companies within the first half of the year

OK, not such a hard prediction to make right? But keep in mind Oracle’s acquisition of Hyperion happened right at the end of the 1st half of 2008 and as predicted, just in time to keep analysts from determining if Oracle is achieving any real growth outside of the growth it acquires.

A significant handful of SaaS companies will make it through the IPO window

For sure this happened. Successfactors made it out as did Netsuite, Constant Contact and probably more I’m not tracking at the moment.

Tech boom enterprise applications startups come back to life

Big miss on this one as far as I can tell. The rich keep getting richer in enterprise applications as conservative customer buying patterns and a lack of innovation in the startup apps community prevents the new companies from taking off.

2007 will not go down as the year the Web 2.0 bubble burst.

True! Companies grew, ad revenues were up, bankruptcies were few. 2007 was another banner year for the web 2.0 trend.

In conclusion

So my batting average for 2007 was 3.5 / 6 or 58%. Does this mean I’m ready for analyst fame or infamy? Let’s see if I can get this up to 70% next year.

A new wrinkle on SaaS

Salesforce announced an interesting new capability to facilitate the sharing of specific types of information between different SFDC subscribers. An early example would include something like sales leads. So, for example if one SFDC customer sells a complementary product to another SFDC customer, they can share information like leads among one another.

This is in retrospect a pretty obvious capability for an enterprise SaaS vendor and I'm a little surprised that no one has thought of it before. While SaaS has cost efficiencies for the vendor, I think it's been a struggle to say that SaaS itself provides competitive advantage for a software vendor. But this is something that would be difficult for on-premise vendors to replicate: an application network effect that's could be genuinely beneficial to the user. The consumer web companies have all figured this out some time ago, perhaps because consumers are more fickle than enterprises.

In the case of Salesforce, I doubt it the feature will be very utilized as few companies share leads frequently enough to make this an often-used feature. It feels a bit forced and after the thought. But it does spark some thought as to what the next generation of SaaS vendors may portend. They say that with every architectural shift, the first generation of new companies uses the new architecture to ape the old paradigm. But the second generation uses the new architecture to accomplish something truly novel.

Where is it all headed? What does it all mean?

I’ve let the blog go a bit cold! It’s been a very busy past few months and feeding the beast has been tricky despite a busy tech news season.

A few weeks ago, Oracle announced a semi-hostile takeover bid for my former employer BEA Systems.

The Wall Street Journal put the offer in context with an article that portrayed Alfred Chuang as one of the last of a dying breed – the founder/CEO of an independent mid-sized software company.

The data supporting this assertion are actually mixed.

1. Many mid-sized enterprise software companies are still alive and kicking including TIBCO, SAS, Kronos, Cognos, Manhattan and Parametric.

2. However many mid-sized software companies have left the scene including Siebel, Hyperion, Agile, Retek, PeopleSoft, webMethods, Mercury, and now possibly BEA.

3. However many newcomers seem poised to replace those that have left. For example Salesforce, Successfactors, vmWare, Red Hat, Netsuite and Rearden Commerce.

4. However many of these newcomers are struggling to sustain growth as public companies or are struggling to get public in the first place. And the aggregate revenues & employment of the new companies is far less than the companies they are replacing.

So what does it all mean?

Since inception the high tech industry has moved in cycles. But I don’t think all parts of the industry follow the same frequency. The frequency many of us think of the system architecture cycle. We’ve heard this dozens of times before: first there were mainframes, followed by minicomputers, followed by client-server, followed by N-tier apps, perhaps now followed by something more grand that lives in the cloud. If you look at the history of this evolution, it would lead you to believe high tech has roughly a 7 year clock cycle from boom to bust and back again.

But if you look just at consumer software applications, it would look quite different. First there were many desktop application companies, then there was Microsoft, then there was more Microsoft, then there was more Microsoft and well, you get the point. Microsoft launched Office as a suite in 1989 and it has taken roughly 16 years before anyone or anything managed to mount a credible assault on its hegemony. Much slower clock cycle.

So, whither enterprise software? Is our industry consolidating? If so, is it the consolidation before the next big bang? I’m pretty unsure of both points at this stage.

Software Product Marketing 2.0?

One pet peeve I have with the enterprise software industry is the marketing. I find most software product marketing to fluctuate between the puerile to the abstruse.

The abstruse bit actually gets me more than the puerile does. For example, most product brochures do an amazing job filling 2-4 pages with words and the obligatory marketecture diagram, but still saying next to nothing about what the product actually does or how it will specifically benefit the buyer. My belief is this is a contributor to sales inefficiencies because now it takes 2 flights from a sales rep and a demo from a sales engineer until the customer has the first clue what the product does or what to compare it to.

Can we throw out the product marketing slick? What would replace it? I was pondering the idea of a product marketing slick wiki. The idea would be that for each product you start with a normal 2 page product description but then readers could comment on it or ask questions and the product managers, marketers or users can clarify and enhance until all the marketing-speak is scrubbed out and you're left with a lucid description. I’d be curious to get any comments if this sort of thing has been tried before.

Dissecting the SaaS business model

Three SaaS companies, Netsuite, Successfactors and Constant Contact are preparing for IPO. This is great news as I get to tick off a “win” on one of my 6 predictions for 2007.

Jason Wood did a stellar writeup of the Netsuite S1 and Jason Corsello did a good note on the Successfactors S1. I thought I'd take a comparative look at all of them.

What struck me with all three companies was the losses. The first order explanation is quite simple: all the companies spend a ton of money on sales & marketing (between 65% and 100% of revenues). Most of these businesses are the farthest thing from the oft discussed but seldom witnessed “pull model” that’s supposed to lead to superior profits.

The root cause for the losses is a little more subtle. In a recent article, McKinsey consultants asserted that the primary cause is scale. In fact they go so far as to say that these scale economies are nearly identical to those of on-premise software companies.

On the surface this appears to be a reasonable explanation. Successfactors had $36m in 2006 revenues and spent roughly 100% of revenues on SG&A. Netsuite is at $65m in 2006 revenues and spent 78% of revenues on SG&A. But I think this is a bit off. Salesforce is at $309m in 2006 revenues and still spent 67% of revenues on SG&A. Rightnow was at $110m in 2006 and still spent 71% of revenues on SG&A. Meanwhile, many smaller on premise companies like Aspen Technology, Quest Software and VMWare keep these costs around 40-50% of revenues and turn an operating profit of 10% or so.

The true factor driving SG&A for these SaaS companies is growth, not scale. This is logically consistent as the economics of most any subscription business is based on the cost to acquire a customer versus the future returns of that customer relationship. I took the financials for all four companies and lined them up not based on year but based on when they are at a comparable size (comparable stage in their evolution). They look like this:


You can see that SG&A spent in the prior year (cost to acquire customers) correlates very well to growth in the subsequent year (returns from customers acquired). So, as long as you believe there’s growth left in your market, keep spending to capture that growth. To prove the point, Successfactors had an interesting period in their fiscal 2004 where they seemed to prematurely press for operating profits by taking SG&A down from 108% to 75% of sales. They were horribly punished in the following year with tepid growth of 35%. They corrected the error the following year and growth sprang back to life.

I created a simple ratio I called “growth efficiency.” This ratio is growth rate in a given year divided by the SG&A % from the prior year. Essentially this evaluates how much growth is generated by a point of margin spent on SG&A in the prior year. I think this ratio is a pretty good indicator both SG&A spend efficiency and is probably also a pretty good indicator of long term profitability. A few observations on the ratios for the 4 companies:

Salesforce had reached a fairly stable equilibrium where a point of margin spent on SG&A returns a point of growth the following year. However this has been deteriorating over the past 2 years. If the high end of Salesforce’s 2008 guidance holds, they will be down to a .69 ratio, equal to or worse than anyone else in the group. Interestingly, this is trending down at a time when Salesforce has been raising prices through various premium offerings that can now drive the user/year fee as high as $2,350. I think there are lots of interesting theories to explore here.

Successfactors’ ratio is all over the map due to their experimentation, but in 2005/2006 a point of margin spent on SG&A returned a point of growth. I think it’s too soon to extrapolate any long term trends for Successfactors.

Netsuite has been a consistently less efficient business. A point of margin spent on SG&A currently returns only 2/3 of a point of growth the following year and this was 1/2 a point of growth a few years back. That reinforces my theory (and persistent rumors) that Netsuite should have a tougher time acquiring customers than a Salesforce. Financials is a more centrally controlled purchase decision and is more likely to go through a comparative evaluation. In their defense, the picture has been steadily improving.

Constant Contact has the best business of the four. A point of margin spent on SG&A gets you 1.4 points of growth. This with a product whose average selling price is just $34/month. This also makes sense as e-mail marketing services for SMB companies has got to be the ultimate impulse buy. Constant Contact uses no direct sales force and generates almost all revenue through marketing campaigns and channel partners.

The pull model is as elusive as ever, but Constant Contact seems to give us a few hints as to how it's supposed to work.

[SaaS], [Business Models]