The software business: your risk model, should you need one.

I was just going back over Microsoft's announcement from January when they announced their "cost cutting initiatives" (it was referenced in a friend's "my last day at Microsoft" email), when I noticed at the bottom the bit about "forward looking statements".

These sections are usually pretty bland and generic - however, what is fascinating is that Microsoft have actually broken out all of their downside risks into a list for everyone to see: check out the list below. If you're running a software business and don't have a risk model, here you go. ;-)

•	challenges to Microsoft’s business model;
•	intense competition in all of Microsoft’s markets;
•	Microsoft’s continued ability to protect its intellectual property rights;
•	claims that Microsoft has infringed the intellectual property rights of others;
•	the possibility of unauthorized disclosure of significant portions of Microsoft’s source code;
•	actual or perceived security vulnerabilities in Microsoft products that could reduce revenue or lead to liability;
•	government litigation and regulation affecting how Microsoft designs and markets its products;
•	Microsoft’s ability to attract and retain talented employees;
•	delays in product development and related product release schedules;
•	significant business investments that may not gain customer acceptance and produce offsetting increases in revenue;
•	changes in general economic conditions or the availability of credit that affect the value of our investment portfolio or demand for Microsoft’s products and services;
•	adverse results in legal disputes;
•	unanticipated tax liabilities;
•	quality or supply problems in Microsoft’s consumer hardware or other vertically integrated hardware and software products;
•	impairment of goodwill or amortizable intangible assets causing a charge to earnings;
•	exposure to increased economic and regulatory uncertainties from operating a global business;
•	geopolitical conditions, natural disaster, cyberattack or other catastrophic events disrupting Microsoft’s business;
•	acquisitions and joint ventures that adversely affect the business;
•	improper disclosure of personal data could result in liability and harm to Microsoft’s reputation;
•	outages and disruptions of online services if Microsoft fails to maintain an adequate operations infrastructure;
•	sales channel disruption, such as the bankruptcy of a major distributor; and
•	Microsoft’s ability to implement operating cost structures that align with revenue growth.

Ray Ozzie: Cloud lowers margins shocker

Ray Ozzie at Microsoft has gone and said the unsayable: the economics of Cloud Services will yield lower margins than packaged software for Microsoft. Uh, yeah. The company’s gross margin for the quarter ended March 31 was 79% - is that sustainable in a new industry paradigm which is relentlessly driving out efficiencies and economies of scale?

On the other hand, as Google and others have shown, when your technology scales to 1.4 billion users and counting, and supports a significant percentage of global commerce, then margins aren't everything.

Perhaps of most relevance is Microsoft’s key incumbent strength in this space: an estimated 5 million to 7 million developers who write software based on Microsoft technology (mainly .NET these days). MS isn't going away any time soon - however they will need to work out how to monetize Azure differently to the open source / EC2 crowd.

Google Wave - the future of email, collaboration?

Just seen this preview of Google Wave:



Letting the implications sink in but if Google migrate all of their (commercial and consumer) GMail users onto this platform when it launches next year this could become the new paradigm for enterprise(to-enterprise) collaboration pretty quickly: email, IM, documents and media sharing. As Rod Drury comments: the classic Exchange email model is just broken.

Google are going to open-source the APIs - how many new apps could be built upon the top of this and what new business models could that lead to? (Google exec quote: "...this again is a very early release and at Google we have quite a luxury that in the beginning of the life of a product we focus exclusively on technology and making a product successful....the question of monetising we deal with later"). Yeah right.

(Incidentally one of the jumpouts of the demo was the multilingual collaboration on a document - 4 users editing in English Chinese, Hindi(?) and another asian character set all at the same time! - not sure if this is in Google Docs already, but mindblowing compared to just a few years ago)

Cloud Services in the Enterprise - slides from Canterbury Software Cluster meeting 5 May 2009

I enjoyed giving a talk on "Cloud Services in the Enterprise - Making Sense of XaaS" to Canterbury Software Cluster on Tuesday. Lots of great questions at the end and conversations afterwards - please feel free to carry on the conversation by email or here on the blog.

The slides are here for reference:

Google App Engine supports Java!

In case you missed it Google App Engine now supports Java. See:

http://googleappengine.blogspot.com/2009/04/seriously-this-time-new-language-on-app.html

That's likely to drive adoption considerably deeper than support for Python, then.

PS Also in case you missed it see the earlier Google App Engine blog article from April Fools' Day: Google App Engine Supports Fortran. Funny.

Ruby over ABAP - is this SAP's cloud PaaS play?

Something caught my eye the other day which might be nothing, but might be the first inkling of another global PaaS play. This great interview on InfoQ with Juergen Shmerder on Blue Ruby, SAP's implementation of a Ruby VM over their proprietary ABAP stack.

So this is SAP's strategy to drive much broader developer adoption of the ABAP technology in which much of SAP's ERP products are written. (Let's face it they're never going to do it with ABAP by itself! ;-) ) To quote Vishal Sikka, SAP CTO:

"The language Ruby, for example, is thought to have reached a million programmers faster than any other language ever."

Now Blue Ruby itself is still very much still in SAP's laboratory, but when you combine this with SAP's recent acquisition of cloud application platform Coghead's IP assets, and (maybe I'm reading too much into this) you start to see another PaaS play emerging. In the same way that SalesForce have leveraged their leadership position in the CRM space to drive adoption of Force.com and the Apex language, so SAP might play in the ERP space with Ruby:

	Google	SalesForce	Microsoft	Bungee Connect	Heroku	SAP?
Platform	Google App Engine	Force.com	Azure	Bungee Connect	Heroku (Rails over Amazon EC2)	SAP Cloud Platform?
Language	Java and Python	Apex	C#, VB, Python, Ruby	Bungee Logic (proprietary)	Ruby	ABAP and Ruby

Cloud Services Stack - "Above the line"

Well it's been a while since my last post: so happy new year, then. ;-)

(I've been very busy! Among other things adding lots of features to the Memia Cloud Services portfolio management toolset which is currently in development *and* doing a load of business planning around the forthcoming SaaS offering - watch this space...)

Meanwhile, I've recently joined the Cloud Computing Interoperability Forum (CCIF) and while browsing through the forum posts I came across one from Kent Langley of nScaled : "Cloud Computing Stack Update". In this post Kent updates his ontology of the Cloud Stack - copied below. This picture gives a nice "ground up" taxonomy view of the Cloud Stack, from "public utilities" (=power companies) upwards.
However, I'm often struck by the subconsious manifestations of the two primary mindsets at work within the "Cloud" space. Generally people seem to either come from an infrastructure background or a software background, but not both. So while this diagram gives plenty of detail describing everything up to and including "operating system" (ie what I would call "Cloud Computing" but not "Cloud Services"), it doesn't place the same emphasis on the variety within the SaaS space. That is, it's an infrastructure-centric view.

Nothing wrong with that, but as someone working in the Cloud space with a primarily *software* hat on, here's an (equally skewed!) ontology which elaborates a more software-centric view of the Cloud - effectively "above the line". Obviously its horses for courses, but in my opinion if we're trying to define the whole Cloud stack from top to bottom then we need to be more granular when describing the common services living within and across the PaaS/SaaS level. (Feedback invited on the contents of the light blue boxes - this is a first cut and I intend to iterate.)