Free Web Hosting Provider - Web Hosting - E-commerce - High Speed Internet - Free Web Page
Search the Web

Monday, February 20, 2006

Mr. Mickos, are you sure about Oracle?

I think the urge to post a reply to Nick Carr's piece 'Oracle's open source rollup' came because I work at Oracle and after a little more than a year working there, am beginning to understand how this company ticks. In general, I thought Nick was open to the idea that Oracle may be headed to some interesting place with its OSS acquisitions, but it was the comment by mySQL CEO Marten Mickos towards the end of Nick's post that made me sit up and write out this rebuttal.

Before I start, I did hear the buzz somewhere that the Oracle-JBoss deal closed last week for $485m. Now that would be an amazing development!

Also by the way, this is the first post on this blog that's not about on-demand services, but I think it marks the beginning of my intent to start writing on Open Source as well out here. They're two different animals, On-demand and OSS, but in ways not entirely unrelated. They're both about the collision between the worlds of software and services. They're both about marginal cost economics of software products continuing to play their hand, with software prices tending ever closer towards reflecting the cost of service delivery and product costs tending to reflect...well..marginal costs. :o They're both where the future of the industry is going. Currently, both suited for different purposes - OSS for infrastructure software, and on-demand for Apps delivery - but that's not a strict divide, and they are both increasingly intertwined parts of the same services. RightNow being a perfect example here of on-demand service running on open source infrastructure.

Getting back to Mr. Mickos' comment, I think he misunderstands Oracle, even underestimates. Oracle is fully aware of the commoditization that OSS is driving up the tech stack and the consequent blur its creating between software and services. Of licensed databases selling on Linux, the fastest growing server market, Oracle has an 80%+ market share so they're pretty warm to working with OSS. About 60% of their revenue comes from support services, so they fully well know the value services drive. Also - recent hire is Omar Tazi (check his blog here), Oracle's chief evangelist for OSS. The fact is, Oracle is quickly sizing up the OSS force. I think their OSS acquisition moves - Sleepycat last week, possibly JBoss this week, maybe Zend as well...reflect a trade-off between the unstoppable risk to proprietary license revenue, versus the more manageable risk of seeking to embrace and bake in OSS-based IP creation processes into the company's development and business model. Tazi even calls it OPAL (Oracle, PHP, Apache, Linux)!

From the community angle, deep technology firms like Oracle, Sun, IBM and Microsoft are strongly aware of how their business success has its roots in the technical and creative capabilities of talented engineers. A lot of this talent today is passionate about working for OSS projects. What better way to align with the interests of OSS communities than to find mechanisms to work with and sponsor them and their members, afford them the freedom to keep tinkering and creating IP in a sustained way, invest in productizing the IP, while providing a reliable, global service and support infrastructure to companies who need it and will pay for it. Ofcourse, Microsoft may take far longer to figure this out for their server products, or maybe never (or maybe they're just not nice..;)), but that's really because they care more about consumer technologies where they have different, fiercer battles to fight - the internet, the living room, the device in the pocket...

So that's where I think Oracle is heading, mostly to play a friendly game with OSS. While I'm nowhere near privy to Larry Ellison's deepest thoughts on this, friendly or not, he certainly has the ability to keep Oracle playing a game that spectators don't want to miss.

Saturday, February 11, 2006

SAP's isolated tenancy on-demand model

Isolated tenancy - that's the spin SAP put on their on-demand CRM service they launched last week. Sounds like a fancy term for delivering software updates to on-premise installations via web services. Their 'isolated tenants' are still expected to run their software and infrastructure on-premise. There is ofcourse subscription pricing for the service.

My take - what SAP touts as the '3rd generation' of on-demand is really just them trying to sound like they're pushing the envelope. In reality, its simply the old guard taking a step closer to where the future's going to be and where those who're not of SAP's vintage are already playing. If Corio was ver 1.0 of on-demand (single tenant hosted, ASP model) and salesforce.com circa 2001-2004 was 2.0 (multi-tenant on-demand with subscription pricing), SAP on-demand is more like 1.5. And to be sure, 1.0 and 1.5 are still derivatives of the on-premise model.

But now, I would'nt heckle too much. Microsoft only just came out with a 1.0 on-demand flavor with their partner hosting program for the latest MS CRM release. And while Oracle On-Demand, another 1.0 offering, has been around a while, it surely needs an upgrade. Oracle does have newly acquired 2.0 assets in its possession via Siebel OnDemand, but as the erstwhile Siebel's experience with On-demand shows, blending 1.0 and 2.0 business models is not without its own challenges. Going from 1.0 to 2.0 is such a leap in terms of the technical architecture and more critically, the business model, that I think none of the old guard companies are going to get there without a few interim versions and a good deal of pain.

To be sure, ver 2.0 is not without its own set of growing pains - reliability issues, deep customization, integration, and integration security most notable. Some of these are getting better addressed with ver 2.5 (salesforce.com circa 2005-2006, RightNow, NetSuite, Intacct) now doing the rounds.

Getting back to SAP's 1.5 flavor, it does offer some of the benefits of pure bred 2.0 - primarily subscription pricing and remote software updates (hopefully SAP keeps this simple enough). Most likely, I'd guess SAP is also going to mandate the specs for the on-premise application infrastructure, which in turn means 2.0 type operational efficiency in product development due to a single code base. SAP marketing also found a clever, opportunistic way to exploit the reliability pains salesforce.com is facing these days with its big iron stack, and touted their isolated tenancy as the answer to that. I hope they don't believe too much of their own marketing though. Because that's just FUD against salesforce.com's particular situation rather than an industry-wide 2.0 problem.

But here's what SAP's flavor is missing - economies of scale in operations and distribution. Its biggest limitation is that its nowhere near what's required for near consumer scale, lower tier SMB distribution. Not that SAP does'nt know this, or perhaps cares about either. They know (and say so) that it will make sense only for installations with 100+ users. Its a viable option only for existing SAP customers, for larger SMBs and large enterprise divisions that SAP might not like to lose to salesforce.com or RightNow.

And therein, within this apparent threat from SAP is the opportunity for the 2.0 players. Companies like SAP are motivated to serve the larger business and have a distaste for the lower end. It because, as a business, they don't quite know a good way to make money there. If someone can do it, its the likes of Google, Yahoo, eBay. Amazon if they're interested. Salesforce.com certainly, already becoming the best proof point for lower SMB business apps. Microsoft and Intuit, if they set their mind to it. Wild card for Oracle. No way SAP.

For good or for bad, that's splendid isolation indeed.

Wednesday, February 01, 2006

Outages: growing pains at salesforce.com

Salesforce.com (SFDC) has recently been getting the wrong kind of attention about its outages - Salesforce.com Crashes Again. There's a chorus of people complaining in public - company watchers, analysts, customers. Competitors are opportunistically picking on it as well. Wall Street initially got a bit nervous and slammed SFDC a bit, although they seem to have come to terms with it. And check this out - a blog called GripeForce!

So what is the ballyhoo about?

At a perception level, its simply people asking a poster child to be more accountable about, well, being a poster child. Outages like these, even more, are common with on-premise software. But on-demand outages occur at a concentrated point of failure, affect lots more people simultaeously, and this sets up a big common target whose neck can be wrung. The market even has an incentive to talk more publicly about it than it has for on-premise failures.

At a service operations level, outage risk is inherent with shared infrastructure and simply needs the right kind of risk management practice - usually, the right level of investment in infrastructure redundancy and monitoring tools, with an SLA providing the sort of skin-in-the-game that gives customers the assurance they need. And heck, outages are like teenage awkwardness...everyone that grows up in the web world goes through it. Yahoo had them back in 2000, Ebay back in 2001, and Google got hit last year.

From SFDC's standpoint, their outages are actually not a bad problem to have. Sure they've probably gotten a bit ahead of themselves with the explosive growth they're seeing, the new products (err...services) they're building and the market foment they're working up. They did see some of this coming and started taking steps to avert it a few months back with the MirrorForce datacenter investments. I'm sure they also have more coming to address Forrester's recent comment “Salesforce.com: Time For A Standard SLA”. I would'nt doubt this company's ability to execute on growth.

And while competitor RightNow was certainly not as strained about managing growth as SFDC, they do appear to have made very different operational choices. With due credit to them, they're now even crowing about it. A couple of little secrets about RightNow's sauce is that they don't actually run their own data center...they use co-located facilities, and they run their platform on open-source tech components. To some extent, RightNow's uptime performance validates a couple of very useful things to know about running on-demand operations - 1) that data centers are best run by specialists that manage large scale infrastructure...a point that Nicholas Carr makes in his post 'Salesforce.com's hiccups' . 2) Open-source tech components have a high enough degree of reliability to run SLA grade on-demand operations and if there's a glitch..Can We Fix It...Yes We Can! (Just got carried away a bit there with my son's Bob-the-Builder slogans...). So what does SFDC do when something like this happens - they point their finger at their proprietary database vendor. Tough luck. Tough choices.

Getting past the operational level, matters start to get really interesting from a market strategy perspective around outages. What is a fair and reasonable benchmark for application availability levels? Is 99.98% good enough? Are there customers who can manage their application infrastructure better on their own? Are they a useful market for on-demand vendors to address? How much better can those customers manage and what is it worth to them to do it? How much are they willing to spend doing it? Is it worth segmenting and serving market demand along varying degrees of SLA availability levels priced differently per customer needs? Or are multi-tenant on-demand platforms like economy-class air travel - inherently self-segmenting in terms of the market segment they address and the mission criticality of customer needs that they serve. Basically goes like this - if you're one of the sorts who needs home-in-the-air sort of air travel, whenever you like and to wherever you like, you don't buy an airline ticket. You buy and run your own corporate jet. ;)

So while its fair for customers to demand benchmark service availability levels and for vendors to bear the cost of delivering it, there may actually be some opportunity around outages as well.