Friday, 30 November 2012

Why Software companies fudge their numbers (and how they get away with it)

The story that won't go away


More detail emerges

So the Autonomy kerfuffle rumbles on. Nearly a week in the story still hasn't gone away.

Of course we still lack precise details of what has been alleged. After the initial rush of coverage subsided we've now had a crop of "inside Autonomy" articles - the NY Times on Monday, Reuters today long on colour, short of detail.

A few more hints came out in this WSJ article (if you don't subscribe Google the headline and then access it via Google News). It flagged some some interesting stuff about channel stuffing with reseller Tikit, and round-trip accounting with customer VMS.

(In interests of disclosure, I corresponded with one of the WSJ authors of the article before publication, but none of these allegations came from me.)

Mike strikes back

Unsurprisingly Mike Lynch has come out fighting with his multiple TV spots and open letter to HP. HP's response has effectively been "we'll see you in court".

I think this post from AllThingsD sums up his PR strategy quite succinctly. The line of attack is to muddy the waters by focusing on HP's (undoubted failings). As I said before this is something of a red herring - HP being complete incompetents and Autonomy being dodgy are not mutually exclusive conclusions.

Time to take a break

My suspicion is things now take a pause. Given HP has referred the matter to the authorities, I suspect the case is now sub judice. This means we are unlikely to get any more details soon, no matter how much Mike yells for them.

So given there's probably going to be a break in the newsflow I want to look at the broader issue of how software companies dress up their accounts. I suspect this will provide some useful context for what may or may not follow.

First I want to explain in simple terms how and why companies massage their numbers. Then a few thoughts on why it happens to software companies so often. And finally I want to present a rough guide so some of the more common wheezes.


Why software companies massage their numbers


Valuation ratios and perverse incentives

You would have thought it was self-evident why companies want to boost profits. More profits = a higher share price right? Actually its slightly more complicated than that.

I wrote about this back in October. In summary the only way to properly value a company is to figure out the net present value of all the economic benefits that will accrue to you from owning it. In short either DCF or EVA the bastard - the maths come out at the same answer.

But as I wrote in September, people often use valuation ratios as a short-cut. The key point is that while valuation ratios provide a sense-check they should never be a substitute for an in-depth long-term valuation. If you do "value" a company based on a valuation multiple you are implicitly making one very big - and very dumb - assumption:
You are taking the value of one year's revenue / EBITDA / earnings and extrapolating the entire value of the company forever and ever and ever based on a single number.
That to me is completely nuts. While this year's number is an indicator of how things are going at the moment, in most cases it says very little about how things will be going in two, ten or fifty years time. US quarterly reports are the most heinous example of this - Mr Market regularly marks the long-term sustainable value (i.e. the share price) of US corporates up or down five or ten percent based on three months trading data. Signal & Noise.

But back to the topic in hand, the other consequence of this is a perverse incentive for management. Because in order to maximise the value of their company they don't have to build a long-term sustainable business. The only need to pump up the near-term numbers until they can either cash in their options or attract an M&A bid. Agency Problem 101.


But why is it always Software companies?

Okay so if Mr Market uses imperfect yardsticks like valuation multiples, all companies have an incentive to cook the books. But software companies seem particularly vulnerable.

In my time covering the European sector iSoft, FAST and Torex have come to trial, and I'm sure there are many more that have not. In the US Informix was the highest profile case (shock, horror CEO went to jail for a whole two months), but outside the courtroom Microsoft, Oracle, Computer Associates, Veritas, Sybase, Symantec, I2, Red Hat, Macromedia, Microstrategy and BMC have all had to restate their accounts.

There are two problems here. Means and Incentives.


Problem 1: The means are close at hand

Means first. The basic problem is that a software companies don't sell physical stuff, they sell intellectual property (specifically software licences). As I've written previously, this has tremendous benefits with regard to creating a scalable, asset-light business model. But there are downsides. Because there's no physical product to be shipped it is very difficult to determine when you should recognise revenues and how to assess the costs.

Take revenue recognition as a case in point. The gold standard for this is US SOP 97-2, (in paraphrase: you need a contract, product must be delivered, the fee must be fixed and collection of it likely). However even under this regime much of the actual revenue recognition comes down to a matter of judgement. Let's give a practical example:
It's 11:50pm the 31st of December and a customer has just signed a $5m deal for your enterprise software package. At 11:55 you send them a download link with a copy of the installation files at the other end. However actually installing the damn stuff is going to take about 18 months and involve two dozen wage-slaves from Accenture. Testing it and getting staff trained up on the system is going to take much longer. Obviously you haven't received any cash yet - the customer's not that stupid.
So when do you recognise revenues? You've got a deal, product (or at least a download link) "shipped", the price is in the contract and payment is likely (so long as you don't screw up). Do you recognise it all at 11:55? Or do you wait until Accenture have started, or Accenture have got so far the customer can't back out, or Accenture have finished and the customer has signed off, or the customer has trained their staff and they're all happy. And what if you find a show-stopping bug five months down the line? (Remember a v1 software package is probably the only product guaranteed to have defects on day of release!)

In the end, it comes down to your judgement. Useful...


Problem 2: The incentives are massive

Secondly on Incentives. Tech is intrinsically high growth (in a nutshell: Moore's Law). High growth companies attach high valuations. High valuations mean rich earnings multiples. This means the benefit from each additional penny of earnings when you capitalise it on 35x P/E is commensurately greater.

Coupled to that software companies have a culture of rewarding employees with stock, and you have ample to incentive to ramp the share price at least until your options vest.

In short the high rewards on offer to tech companies present ample motive to fix the numbers.



How software companies massage their numbers


Four ways to fiddle your numbers

Okay that's the theory. How does it work in practice?

To start with a general framework. If you are trying to maximise profit you can do to things - either increase your reported revenues or decrease your reported costs.

In turn there are two ways you can do this - you can change the timing of revenues/costs (pull forward future revenues; push costs into the future), or you can artificially change the magnitude of revenues/costs (booking false revenues; not showing appropriate costs).

Stick these in a grid and this is what you get:

What they didn't teach you in Accounting class...

Let's go through these one at a time.

1) Changing the the timing of revenue

  • Taking licences upfront: As I said earlier with software companies it is often a matter of judgement as to what proportion of a big licencing deal you book upfront. 30-50% is not unusual. 100% happens, but is probably imprudent - that would certainly inflate your revenues (and you all-important revenue growth rate).
  • Misclassify types of revenues: Different types of revenue are accounted for in different ways - as I said above software licences might come up front while long-term consulting projects take longer. So if you mis-classify consulting as software licence (call it a "solution"...  no one will know...) they you could take the revenues early.
  • Channel stuffing: Often technology vendors don't sell to the end user, they sell to a reseller who holds a certain amount of inventory on hand to fill customer orders. So what you might do is sell more into the channel, book it as revenue. Except next time the reseller still has all of last quarter's kit lying around so doesn't need to buy more from you, and your revenues fall off a cliff. Let's be clear - variations between sell-in to the channel and sell-out to final customers is a normal part of doing business and very common in consumer hardware. But there remains scope for it to be done to an inappropriate magnitude (I think this is one of the things HP is pointing to with Autonomy).


2) Changing the timing of costs

  • Merger provisions (and other provisions): When you do a big merger you typically take a whacking great cost upfront through the P&L which everyone ignores (because its seen as part of the capital cost of the acquisition). It then sits on your balance sheet as a provision - a kitty of expenses already taken against a rainy day. However if you find the provision you've taken is too big you can then write these costs back through the P&L. This write-back doesn't have to be disclosed on the face of the P&L, and reduces your costs in the period (inflating your profits).
  • Capitalising R&D: This is a notorious one in the software world. When you develop a big product which is going to be sold over the next few years you typically don't expense all the R&D costs up front - instead you capitalise them on the balance sheet and expense them through the P&L (in the form of amortistion of capitalised R&D) over the period you sell the product. That's all when and good, as in the long-run amortisation of historic R&D should match up with captialisation of this year's R&D. But an obvious trick is to capitalise more this year then you did 2-3 years ago. This creates a mismatch between the (positive) capitalisation and the (negative) amortisation, boosting profits.


3) Changing the magnitude of revenue

  • Round-trip transactions: Another one which has been hinted at in the Autonomy case. I sell software to a telco, they pay me not in cash but by giving me free phone services for a year. I record the software as revenues and the phone services as an equally-sized cost. That makes sense if they would have otherwise paid you cash and you would have otherwise taken that cash out and spend it on phones, but if that isn't the case the transaction does not reflect the underlying economic reality, and could potentially be inflating revenues.
  • Side-agreements to modify a sales contact: This was the Informix example - they booked what looked to be perfectly respectable contract representing the sale of their gear with no recourse and standard payment terms (which is what they showed the auditors). But they also wrote side letters effectively saying "actually you don't have to keep the product or pay for it if you don't want it" (which they didn't show the auditors). Hmmm.
  • Holding back revenue at acquisitions: It's April, you've just acquired a company but the deal doesn't close until June. You have a quiet word with your future minions at the target and ask them to hold back on sales until the deal closes. Then once the deal's closed in June they they go out, sign all the contracts and give you a bumper month which also includes sales held back in April and May. Effectively you are stealing revenues and profits from the previous owners of the company (who don't care as they've agreed to sell it to you anyway).
  • Ignoring the bits with aren't growing: All software companies like to show off great growth figures. You can do this in two ways - produce great growth figures or change the basis of comparison. So you can do stuff like say "we are sunsetting 15% of out products which are declining at 50% y/y, so we don't include them in our growth calculation". Now there is nothing illegal as this - its simply a way of adjusting the numbers that any idiot with a calculator can see through. But you'd be surprised at how many analysts then use the "growth rate excluding the bad stuff" as the basis for future forecasts (which implicitly assumes "there will never be any bad stuff in the future"). Hmmm.
  • Falsifying orders: Okay if you're going to fiddle your numbers you may as well fiddle them big. Invent a customer, photocopy their signature onto a draft contract, the possibilities are endless. In theory the auditors should catch this quite easily when they a) ask to talk to the customer and b) ask why the cash hasn't arrived, but you'd be surprised at how much they miss. This is especially true in software where you don't actually have to ship a physical product and produce a delivery receipt.


4) Changing the magnitude of costs

  • Restructuring costs: This is linked to the point about merger provisions above. Sometimes there are costs which are so large ("Exceptional Costs" in accounting jargon) that companies tell you to strip them out of earnings. Restructuring costs when you're firing lots of people in a recession is a good example. These will be included in the statutory accounts, but often excluded from the "adjusted" EPS used for valuation purposes. People then go and blithely whack a P/E on that EPS to capitalise the value of the company, effectively saying I don't believe this company will ever take big "one-off" costs ever again". Completely above-board, and completely stupid.
  • Using stock options: Another cost contained in statutory accounts (at least under IFRS) but often stripped out of "adjusted" numbers are stock option costs. Again completely nuts. I'll let Warren Buffet make the point: If stock options aren’t a form of compensation, what are they? If compensation isn’t an expense, what is it? And, if expenses shouldn’t go into the calculation of earnings, where in the world do they go?

A couple of caveats here:

  • Not all of these are illegal or against the rules. Many of these techniques are, in the right hands, perfectly responsible ways of reporting. However in the wrong hands all of them have the potential to mislead.
  • While I kicked off the post with our friends at Autonomy, this is a broader industry discussion. I am not alleging these things went on at any one particular company. I'll leave that to HP!
  • Finally this isn't a comprehensive list - I am not a trained accountant, merely a (modestly) experienced practitioner. I'm sure there's stuff I've missed or just mis-described. There are certainly many tricks I have omitted, in particular ones less relevant to software companies like mucking around with investment income, plant depreciation charges and FX rates.

If you want to know more I can recommend two good books on the subject - Terry Smith's classic Accounting for Growth - a bit 1980's now but its principles are as relevant as ever. Secondly Howard Schilt's Financial Shenanigans - a bit more recent and extremely approachable.

That's all for this week. It's getting deep into Friday afternoon and I really want to have a go on my new copy of Assassins Creed 3 which finally arrived yesterday (I still stick to the PC version, which is on delayed release). Ubisoft FTW! *

* Actually sat in on a meeting with the Ubisoft CEO last week. I think he's got a great thing going on the console execution front - Far Cry 3 also looks like another surprise hit given the Metacritic scores. I do think they have a yawning gap on the mobile side though, particularly if tablets/post-PC devices steal the market from nextgen consoles. But that's another story...

Monday, 26 November 2012

Time for Oracle to buy HP?

The script normally runs like this:

1) HP Screws up.
2) Oracle CEO Larry Ellison takes a pot shot at HP's management/board/strategy/choice of pet dog.
3) Rumours swirl around Oracle acquiring HP.

Except in the last week parts 2) and 3) have been noticeably absent. It may be that Larry and Oracle President Mark Hurd are still too busy chortling into their cornflakes to get on the line to their investment bankers. It may be that HP has finally demonstrated that its such a lemon that even Larry's magic touch can't turn it around. However now that the dust has (slightly settled) its probably worth thinking the unthinkable (again).

Is it time for Oracle to put HP out of its misery?


The most important diagram in enterprise IT


Click to see higher res image. Blue indicates a company offers products in this area. Dark blue are places where I think their offering is particularly strong. Any egregious errors/omissions are my own.
First why would this deal make sense? If you want to understand it then look at the chart above.

It shows how, over the past ten years, the enterprise IT has consolidated (largely via aggressive M&A) into vast end-to-end stacks owed by Oracle, IBM, and to a lesser extent Microsoft and SAP. As the market evolved these IT giants generated so much cash (remember tech is a low capital intensity/highly cash generative industry) that they could buy out smaller competitors on a whim. This led to an epic consolidation as a plethora of horizontal specialists (e.g. Sun for servers, Siebel for CRM, PeopleSoft for ERP apps) were consolidated into these giant single-owner tech stacks.

Oracle has been particularly aggressive in pursing this strategy. Since the historic hostile bid for PeopleSoft in 2003, there has been an unending stream of multi-billion dollar acquisitions. First Ellison cleaned up the detritus of the software industry, including blockbuster deals for PeopleSoft, Siebel, BEA, Hyperion. Then in 2010 he turned on the hardware market with the acquisition of Sun, at the time a declining stalwart enterprise servers.

The move into hardware heralded an important competitive shift. Historically SAP has been Oracle's biggest bete noire, but the shift into hardware meants its focus increasingly turned to taking on IBM. Indeed if you listen to their quarterly results calls (worth it, if only to be entertained by Ellison's hyperactive rants) its clear they they are talking about SAP less and less and IBM more and more.

This is where HP comes in.


Why HP is a great strategic match with Oracle (on paper)


Hardware is the reason Oracle would do the deal

Look back at the stack chart above - Oracle are very strong in databases and apps but for all their hot air about Exadata/-lytics/-logic IBM still spanks them in the grimy world of big iron server hardware. Acquiring HP would be a crucial boost in Oracle's push to take IBM on in hardware servers. Sun got them a toe in the water but was always a laggard in this market. In contrast IBM and HP and #1 and #2. 

The chart below shows HP's revenues and profits by division. Servers & storage are in purple. Actually its only HP's fourth-biggest profit driver. But this is the asset which Oracle prizes above all.



If Oracle really wants to make in in hardware, it needs HP. Given the slow-moving nature of enterprise hardware (hands up any corporates who still have a Fortran box running their basement...), this isn't a market where Oracle can grind its way into the top two by organically taking share. HP is the only game-changer still out there.

Services and Software are nice-to-haves

Services too (the old EDS business) is an area where Oracle lags behind the mighty IBM Global Services. This is probably less of a priority for Oracle - historically they have gotten shops like Accenture to do their dirty work. One area it could be useful is if the move towards cloud computing demands more experience running hosted services - EDS's experience in managed services could be helpful.

There are also some nice assets on the software side - again not game-changers given the relative size of Oracle's business, but assets with a degree of scarcity value. Ironically Autonomy is the most prominent here. Under the hood they have good technology and their expertise in unstructured data complements Oracle's strengths in relational databases.

Vertica also has expertise in columnar databases which fits with Oracle's strength in row-based databases. This is particularly useful as in-memory/columnar structures are flavour of the month at the moment. Having this would strengthen their case against SAP's HANA offering. Finally Mercury is a market leader in software testing tools; a neat little play to capture developer hearts and minds.

PCs and Printers will go

Its unlikely Oracle will have any interest in PCs and Printers (50% of revenues and 41% of profits). These would clearly be earmarked for disposal. This should be easy to achieve for the Printing business - historically the jewel in the crown for HP. In addition to being nicely profitable, the recurring stream of consumables revenues should be attractive to a financial buyer. PC's will be more tricky - but in a cutthroat business where scale matters an existing competitors like Lenovo might be interested in using it to bulk up its market share.

To sum up: On paper, HP undoubtedly puts Oracle into a much stronger position versus IBM.


Why Oracle can make the deal work (in practice)


Of course on paper Sony's strategy to combine film studios, gaming consoles, laptops and mobile phones was a great strategy. And look where it got them.

The most important question isn't "does this make sense", it's "can Oracle make it work".

A couple of thoughts here.

HP is undoubtedly a badly managed business

It's difficult to argue that HP's execution in recent years has been anything other than worst-in-class - something reflected in its lowly stock market valuation. Simply removing this Lemons-in-the-C-Suite-Discount (like a Conglomerate Discount, but juicier...) should be worth a good 20% on the shares.

More seriously though, when I analyse a "turnaround story" at a distressed company there are two things that can be wrong - either the portfolio of assets can be wrong or the execution can be wrong. I would much rather take bad execution over a bad portfolio any day. Improving a company's portfolio involves switching in and out of assets which takes a long time and gives plenty of scope to blow-up in the meantime. Improving execution involves switching personnel which can be done much more quickly.

As I said earlier, aside from the hard-to-sell PC business I think the portfolio of assets at HP is right (or at least right for Oracle). It's the execution that's the problem. That, to me, is an encouraging sign (sic).

Strong merger execution... Helped by a dash of Hurd

If there's anyone who knows about how to gut and fillet and acquired business its Oracle. Starting with PeopleSoft in 2005 they have unmatched institutional experience in how to integrate and turn around acquired assets. Their most spectacular success was Sun where they completely turned around the margins in the hardware business and made an acquisition no-one thought likely a smash hit. They will be hoping they can do the same thing at HP.

Of course Oracle's secret weapon is Mark Hurd, Oracle's Co-President and HP's former CEO. Given his five-year stint he will know where all the skeletons are buried, and undoubtedly have a big say in whether to do the deal.

And if the deal goes through he's the right man to make it work. At HP he was known as a brilliant executor, although lacking in vision (arguably many of HP's problems lie in the fact that he failed to move the portfolio on from legacy hardware when he was in charge). But at Oracle Larry Ellison takes case of the vision thing (and then some). Hurd's inside knowledge at HP and operational chops can be deployed where they matters most - integrating the merger.

Oracle have the financial resources

At its current lowly valuation (0.4x EV/Sales, 3.5x forward earnings) I don't think anyone will argue this will - on the face of it - be an expensive deal in valuation terms (we can get into whether those forward estimates are correct another time!). But can Oracle finance a bid.

In short yes, and then some. With gross cash of $16.8bn Oracle could finance the deal at the drop of a hat. If they paid a 20% premium for HP it would cost them $29.4bn and take them to 0.95x net debt/EBITDA. That's well below the 2.5 - 3.0x level which is seem as comfortable for a software company (i.e. would also leave Oracle plenty of firepower for further acquisitions). See chart to right for the back-of-the-fag-packet M&A math:


Remember for Oracle, its always personal


The other thing to mention, of course, is that for Oracle's controversial CEO, business is always personal. Larry Ellison's career is littered by endless feuds: With Tom Siebel, his former star salesman who upped sticks to found Siebel Systems. With Craig Conway, the PeopleSoft founder who labelled Ellison's hostile bid "atrociously bad behaviour from a company with a history of atrociously bad behaviour". But most of all with HP.


When HP fired Mark Hurd, Ellison labelled it "the worst personnel decision since the idiots on the Apple board fired Steve Jobs many years ago". When HP bought Autonomy, Oracle said Mike Lynch "has a very poor memory or he’s lying" about an earlier attempt to shop it to Oracle. And don't forget that the current HP Chairman is ex-Oracle President Ray Lane, who Ellison fired in 2000.


And of course as soon as Mark Hurd was a free agent, Ellison signed him up and made him co-President.

If there's one think Ellison (and Hurd) would love, it would be to buy HP, fire the board, and make the business work.

He'd love it if he beat them, love it!




Why wouldn't Oracle do the deal?


Of course M&A speculation is cheap. It's easy to talk about big deals, hard to do them (come on Apple, why haven't you bought TomTom yet?? :-p ). Putting the other hat on, why shouldn't Oracle do this deal?

Will regulators shut down the deal?

One big stumbling block would be if the deal can pass the regulators on both sides of the Atlantic. A PC / Printer spin-off would be a convenient smokescreen, but IBM would undoubtedly be screaming (big) blue murder at the prospect of Oracle and HP's server businesses ganging up.

I think Oracle's strategy here will be to try to redefine the market. This is a neat trick they did when acquiring PeopleSoft/JD Edwards. At first sight it was clearly an anti-competitive move as it would reduce the market for large-enterprise ERP software to a SAP-Oracle duopoly. What Oracle argued though was the market was much broader than that and vendors such as Microsoft (actually an also-ran in ERP) should be considered.

I suspect they could pull something similar here. IBM / HP is a small market but if you consider all the cloud vendors offering search/storage options (e.g. Google, which builds its own servers, or Amazon EC2) then the market suddenly gets a lot bigger (and muddier).

Is the merger integration task too big?

Larry Ellison has never had an issue with lack of ambition, but HP is an order of magnitude bigger than previous deals. There is clearly massive execution risk around HP's business. Whether this is too much for Oracle to chew is the big uncertainty. Arguably you could have had the same about previous blockbuster deals like PeopleSoft, but Oracle made them work.

I think one point in Oracle's favour is that its main profit driver - maintenance revenues from databases - is very separate from the HP businesses. This means that even if HP blows up in their faces, cashflows from the database business will pour in regardless. This means that despite the size, this is not a bet-the-farm deal.

Its worth putting the size of the potential transaction into context. this table shows Oracle's $1bn+ acquisitions ranked by size. HP would be three times the size of Oracle's biggest previous deal, PeopleSoft. But also look at the size of the deals relative to Oracle's market cap. HP is three times bigger, but so is Oracle's market cap. In terms of relative size its in the same ballpark (probably smaller once you strip out the PC and Printing businesses). So HP is big, but not as big as you think.

Will the merger dilute Oracle's operating margins?

Oracle is proud of its 40%+ margins, and rightly so. However naysayers point out that HP's single-digit operating margins will dilute Oracle's profitability. With Sun Oracle answered its critics by aggressively cutting costs and driving margins up; while they may hope that they can do a similar job here, HP is a lot bigger (and a WHOLE lot messier).

I actually think this criticism is back-to-front. The important thing to realise is that high margins are not a good thing in-and-of-themselves. You can have high margins because you are cutting back on future investment and cash-cowing your business; you can have low margins (e.g. Salesforce.com) because you are investing like buggery to exploit a growth market.

Rather high margins are good because they general correlate with a company's competitive position. A company with deep competitive moats and the ability to price its products at a premium generally earns high margins. A company in a commodity business generally has low or no margins.

In short, a company has high margins because it is in a good competitive position. It is not in a good competitive position because it has high margins (NB also the same logic applies to Michelin Stars and restaurants, IMHO).

As I said at the start, I think owning HP's assets makes Oracle's competitive position stronger rather than weaker. I suspect Ellison will be thinking along similar lines.


Does Oracle want to be in hardware?

To me the most serious objection to the merger is this: Does Oracle actually want to be in the hardware business?

It's worth referring back to what I wrote about cloud computing. As you get deeper into cloud computing models, the cloud vendor does more and more of the work, and disintermediates anyone below them in the tech stack:


Given that hardware is pretty much at the bottom of the tech stack, then that's bad news for anyone in the Server business. At best you only have one or two customers for your servers (the big cloud companies) rather than thousands of brainless corporates. At worst the big cloud companies start to build their own servers.

So to me the biggest question is this - does Oracle believe the world is moving towards cloud computing and if so would they rather sit back and let Amazon and Google kill IBM's server business rather than having to do it themselves?

If the answer is to this question is "yes", then Oracle will not buy HP.

However here's another perspective: This cloud driven disintermediation doesn't only kill HP's server business. It also hurts Oracle's database business. Same logic applies - it you move towards a Platform-as-a-Service or Software-as-a-Service model then the cloud vendor runs the data management part. So no more need to buy an (expensive) Oracle database.

So its Innovator's Dilemma 101. Oracle have a vested interested in keeping customers off the cloud, or at worst pushing them towards a basic Infrastructure-as-a-Service model where they still need to buy an Oracle database. It's interesting to note some of their offerings such as the Exalogic "Cloud in a Box" (a contradiction in terms if there ever was one!). This seems to be pushing customers towards buying an integrated on-premise hardware appliance rather than entrusting their data an external cloud vendor.

If that's Oracle's strategy then HP fit's right in.

Thursday, 22 November 2012

Autonomy on trial: What I saw in the Autonomy Wars

Another break from the Post-PC/techie world. As I'm sure you've noticed there has been something of a kerfuffle around HP/Autonomy this week. I have to confess I have some first-hand knowledge of the company, so I thought I'd report on what I saw at the time:


Autonomy strikes back from the dead


Mike Lynch: Making the news for all the wrong reasons.
Autonomy is one of the most contentious companies I've covered as an equity analyst. The market was always in two minds whether it was a real innovation-driven tech story (a rarity on this side of the pond), or an M&A-led roll-up with a healthy dash of questionable accounting. CEO Mike Lynch always believed he was cleverer than the rest of us, and with his PhD in mathemetical computing, millions in the bank and blue-sky pitch about Bayesian inference theorem. And who were we analysts to dare argue?

His coup de grace was to squeeze a $12bn bid out of HP which was rich by even the rarified standards of tech M&A (11x sales; 24x EBITDA). And note this wasn't just any old bid - HP paid up in cash (hint to CFOs: If you're a distressed buyer and the seller has an information edge, probably best to share the downside by paying stock), and the deal was forced through with exquisite timing despite the concurrent defenestration of its architect, Leo Apotheker. Once Autonomy disappeared into HP's gaping maw we assumed it was a done deal. Mike had finally proved, with his $800m payout, that he was cleverer than the rest of us.

Of course on Tuesday Autonomy struck back from the dead, prompting a $8.8bn write-down at HP and furious accusations of accounting improprieties.


The case for the prosecution


In a nutshell HP is alleging three things:
  1. Low-margin hardware sales (c10-15% of group revenues) were booked as software licence sales.
  2. Licensing deals with resellers were used to bring forward revenue from future periods.
  3. Licensing deals with resellers were used to create revenue where no ultimate end-user existed.
(By way of background, I previously wrote about the benefits of a classic software business model here. Some of the stuff discussed below relates to that)

A few things to note.

Higher software revenue impacts profitability

Booking low-margin hardware sales as software has two impacts on Autonomy's financials. Firstly it inflates gross margin, as hardware typically has a lower gross margin (20-40%) attached to it than software (80-90%). However bear in mind that it in the long run it does not change the overall operating margin of the business, as costs associated with the hardware will still be taken further down the P&L (apparently here in the sales & marketing line). Software investors tend to focus on operating margin much more than on gross margin, as the majority of costs in this business model lie in S&M and R&D.

There's a catch though. One way this misallocation could affect profitability is if the phasing of the costs for software is different for the costs of hardware. For example if you sell a hardware box the cost of manufacturing that box is going to be booked as a cost at time of sale. However if you sell software the R&D cost associated with that might be capitalised and taken over the life-cycle of the product. On, say, a five year view the impact would be neutral but it reporting more software sales mean higher margins in year 1 and lower margins in year 5.

Software licence growth is a big deal for your P/E rating

Secondly showing higher licence growth is beneficial to the valuation (e.g. P/E ratio) the market attaches to a stock; investors tend to prefer software businesses showing fast-growing software revenues as that is seen as a lead indicator for growth elsewhere in the business (particularly in ultra high-margin maintenance revenues). Or to put it another way, if Autonomy started to show licence declines, the share price would have gotten trashed.

This is serious.

Channel stuffing seems strange at a software company

As are the accusations over reseller sales. Historically Autonomy would sell its software via both its direct sales effect and via resellers (typically IT Services companies or systems integrators). HP's second accusation is effectively that it engaged in "channel stuffing" - selling more inventory to resellers than they were selling on to end-users. In effect this means products which wouldn't be sold to end-users until next quarter could be booked as revenue this quarter.

Note that channel stuffing can be legitimate. Hardware companies, for example, report sales into the channel as revenue, not to end-users (e.g. Apple's reports a sale when it ships an iPhone to a retailer such as Best Buy, not when a punter buys it in a Best Buy store). They would typically engage in channel stuffing ahead of a busy period, such as the holiday season.

However there are a couple of funnies here. The first is Autonomy's own revenue recognition policies laid out in its annual report (see page 51)
The group enters into OEM and reseller arrangements that typically provide for fees payable to the group based on licensing of the group’s software to third party customers. Sales are generally recognised as reported by the OEM or reseller and is based on the amount of product sold.  Sales are recognised if all products subject to resale are delivered in the current period, no right of return policy exists, collection is probable and the fee is fixed and determinable.
The key phrase is "Sales are recognised if all products subject to resale are delivered in the current period...". If that means delivered to the end customer then Autonomy shouldn't have been booing channel sales as revenue; its not completely clear if this is the case, but the fact the clause also mentions right of return policy (again something which would be attributable to the end customer) implies that it is.

The other strange thing is that discussion of inventory and channel stuffing as a whole is highly unusual for a software company, simply because there is no physical product to stuff into the channel. Software companies sell licences to software code, typically downloaded or delivered on a 5c DVD. If Autonomy really was selling high-margin software it is very strange there would be enough product to legitimately stuff into the channel to have a meaningful impact on results.

However it gets worse.

Fictitious revenues is the cardinal sin (but quite easy to do)

The third allegation is the most serious - that deals were created with resellers to create revenue where no ultimate end-user existed. That is more than channel stuffing - that is outright fraud. In the great scheme of accounting shenanigans, manufacturing revenues by creating fictitious customers is a) the cardinal sin and b) surprisingly easy to do in a software company where there is no physical product to manufacture and ship.



The evidence: Seven things I observed in the Autonomy Wars


At the moment HP hasn't shown us the direct evidence which underpins their accusations. However over the years at Autonomy there was a great deal of circumstantial evidence that something was amiss. Nothing that could be proven in a court of law but a number of things which said "this doesn't quite smell right".

1) Low deferred income & high accounts receivable

See this blog article for a good snapshot of the situation at Autonomy. In a nutshell receivables (money owed for services already rendered and booked as revenue) were high and deferred revenues (money received for services not yet rendered and booked as revenue) were low. This was an inversion of the normal situation at software companies where receivables were typically low (cash paid upfront for licences rather than being collected later) and deferreds high (cash collected upfront for maintenance and support yet to be rendered - SAP is a great example of this).

2) Mixed cash conversion

Cash conversion is the proportion of accounting profit (net income) converted to cash profit (operating free cashflow). This sort of relates to the first point as high receivables generally mean low cash conversion. Normally cash conversion is very high (as I said in my earlier blog post, software companies have little physical plant or inventory tying up money so are high cash generative). At Autonomy, if my memory recalls (I no longer have my old model with me, alas) it was mixed. Sort of in the 70% range (I think). Not the worst I've seen but not what you expect from a top-class software model.

Note that there can be legitimate explanations for weak cash conversion. In particular if a business is growing fast (which Autonomy claimed it was) it would be reasonable for capital to be committed to support growth, either for vendor financing or to support a sales & marketing push. However if it continues to be weak when growth slows, particularly, that is a warning sign.

3) Unusually high operating margins

The third thing that was a little strange was Autonomy's high operating margins, typically 40%+. A classic software business model is generally capable of doing 20-30% operating margins no sweat. 40% is possible, but normally only in mature businesses with large cash-cow installed bases and lower marketing costs (Oracle and Microsoft are classic examples). Autonomy claimed to be having it both ways - but growing fast but also producing mature-company margins. I can't think of another software company which was reporting a similar growth/margin profile. Meg Whitman's comments that Autonomy's underlying margin was actually 28-30% sounds a lot more like reality.

4) An acquisitive track record

Autonomy was a perennial acquiror. It was a classic "roll-up", conducting a series EPS-boosintg acquisitions (Interwoven, Verity, Zantaz etc) each time growth appeared to be slowing. This had several impacts on the numbers. For one thing the consolidation of the balance sheet of each target (and the taking of merger provisions) obscured the numbers, making it very hard to track true organic growth.

For another it enabled Autonomy to acquire new customers to cross-sell into - costs which would have flowed through the P&L as sales & marketing costs if the customers had been recruited organically. There is nothing illegitimate about this, but I always thought that to reflect the true nature of the business Autonomy's margins should have been looked at including acquisition of goodwill (typically taking 500bp of of that 40%+ operating margins) as it was effectively a S&M cost.

The other funny thing about Autonomy's M&A was that they were remarkably quick at integrating acquired products into their IDOL platform. Without fail they would happily report a couple of quarters after acquisition that all new products were integrated into their suite - this is surprising given the complexity of the engineering task. As this Forbes article alleges the reasons was that products weren't actually integrated.

5) A persecution complex with analysts

The fifth strange thing was their bizarre relationships with analysts. Autonomy's various run-ins with critical analysts were well documented even before the HP deal. From my recollection I cannot recall seeing a company so obsessed with what analysts thought of it. In particular each quarter there would be a "review of analysts models" slide which, though not labelled as such, was seen as tacit guidance. Autonomy was the only company to take this step, rather than simply including a formal guidance statement.

I think there was something of a vicious circle to Autonomy's relationships with the analyst community. The more people wrote bearish notes on Autonomy the more the company would circle their wagons and the more bearish the bears would get. This wasn't helped by Autonomy's quarterly reporting cycle (unusual for a UK company). Given the volatility of quarterly results (especially for a smaller companies) there was always going to be some "funny" in the numbers each time for people to jump on. Sometimes this was legitimate, sometimes this was just noise. Of course if Autonomy had reverted to a more sensible half-yearly reporting structure that would have just made people howl that they were hiding something!

At the end of the day  good companies are generally ones which look after their business and then let the share price take care of itself. Autonomy seemed to take the opposite view.

6) A dangerous internal culture

The sixth worrisome sign was the internal culture of the company. Autonomy struck me as having a dominant CEO with little formal constraints on his power. CFO Sushovan Hussain did not strike me as someone who, when push came to shove, would stand up to Mike.

Also, like many software companies, there seemed to be a Darwinian sales-driven culture (see the anonymous comment at the bottom of this Reuters story for (what may be) a eye-popping account). That is not to say that sales-driven cultures = accounting fraud, rather that sales-driven cultures tend over-promise on the topline, and be incentivised on a rising share price. This creates fertile conditions to try and cover it up when sales (inevitably) fails to deliver and threatens to derail the equity story.

7) A strangely static tech pitch

Autonomy's technology pitch: "I know more Greek
symbols than you. Now please buy my software"
The last thing was Autonomy's technology pitch, which was basically "We have a black box which revolves around Bayesian Inference and Shannon's Information Theory. It searches stuff". The funny thing wasn't the pitch though - black box companies aren't great (Warren Buffet memorably never invests in anything he doesn't understand), but they do exist and flourish. Just look at Google (hint: I doubt its search algorithm relies much on tracking html linkbacks to websites anymore).

The funny thing was that the pitch never changed, right from when I first came across Autonomy in 2000 to when it was finally taken out. Now imagine a major tech company who's pitch hasn't changed in 12 years. You can't. There isn't one. Twelve years ago Apple was a desktop computer company with a sideline in media players. Now its a phone company with a sideline in desktop computers. But Autonomy never changed.

Now none of these factors were a killer in and of themselves - I've seen them all occur in isolation at many well-run and highly profitable companies. However together they were all a bit... Strange.



The case for the defence (and other logical fallacies)


Of course Mike Lynch isn't the sort of guy to keep quite about this. He was busy making the rounds of TV studios yesterday putting his case. In a nutshell:
  1. He admits there was some hardware reselling involved, but this was openly disclosed and only c2% of revenues.
  2. The Autonomy numbers were audited by Deloitte and subject to due diligence by KPMG plus a horde of associated bankers. If there was something going on they would have spotted it (amusingly, Meg Whitman has been making the same point to justify why she wasn't responsible, except saying if there was something on they should have spotted it).
  3. Autonomy was fine when it was bought and has been wrecked by mismanagement post-acquisition, hence the write-down.
  4. HP is using this as a smokescreen to hide problems in its own business.
Thinking about these, I think Lynch's first point has some merit. However the others are logical fallacies, plain and simple.

Bundling hardware is legitimate - the question is how much was going on

I think Mike has a point about hardware sales. Autonomy did talk in the past about bundling software and hardware, particularly with its IDOL Search Appliance, a $1m+ box which combined Autonomy software on a dedicated, high-speed server. Given the numbers Lynch has talked about I think this product is what he is alluding to.

Bear in mind that bundling hardware and software is a perfectly legitimate practice - it's what tech companies call selling a "solution". Everyone does it to some degree. Arguably Cisco, for example, is simply a software company which bundles its programs on generic low-margin router hardware and sells them for a premium. Similarly SAP has been blowing its trumpet for the last two years about HANA - its bundling of an in-memory database on a commodity hardware server.

It sounds like the debate isn't that it was being done, but the magnitude. If hardware sales were 10-15% of revenues as HP alleges, that would not be something I can remember then talking about before.

His other arguments are, however, red herrings.

Throwing Deloitte under the bus - the fallacy of the Appeal to Authority

With regard to the due diligence whether it was spotted or not by Deloitte, KPMG or the man on the moon is a reflection on their competance, and has no bearing on whether it actually took place. This is a logical fallacy known as the Appeal to Authority: "Deloitte says its so therefore it must be so".

HP's subsequent behaviour - the fallacy of the False Dilemma

With regard to what HP did or did not do to Autonomy after acquisition again that is not the issue. The question is what happened before HP bought Autonomy. HP's (undoubted) management ineptitude is another matter. This is a logical fallacy of the false dilemma: HP wrecking Autonomy post-acqn, and Autonomy have dodgy accounts are not mutually exclusive events.

HP's smokescreen - the fallacy of the Appeal to Motive

Finally saying HP is using this issue as a smokescreen is a logical fallacy known as the appeal to motive, where you impugn an opponents reasons rather than his reasoning.

As I said before we do not have the full evidence, but I don't think Lynch's case adds much to the defence argument. Anyhow let's see what HP come up with. And let's not underestimate HP's unending ability to shoot itself in the foot (on that note I actually saw someone using a Palm Pre the other day. Wonders never cease!).

(PS if you want to understand more about formal and informal logical fallacies, I can thoroughly recomment Masen Pirie's How to Win Every Argument: The Use and Abuse of Logic. Essential reading for anyone who's ever been involved in an online flame war!)


Lessons to be learned


So what are the lessons to be learned from this mess? Very early days but here are the things that jump out at me.

The dangers of shorting bad companies
Be careful shorting dodgy companies when there is a bid out there. This sounds sort of counter-intuitive (surely you'd want to sell the bad companies?), but don't forget that up until this week if you had bet against Autonomy on the back of these you'd have had your face ripped off. Every time the bears got too dominant the company would pull out (manufacture?) a blow-out set of results or another acquisition to muddy the waters. And eventually they found (what they thought) was the ultimate get-out and found an even greater fool (HP) to sell the business to.

Ironically the right investment thesis on Autonomy (the shares) as opposed to Autonomy (the company) was "buy the stock, because Mike is clever enough to pull it off".

Another good example was actually a former competitor of Autonomy's, Norwegian company FAST Search & Transfer. This was another one that always had questions asked about its numbers (culminating in an accounting restatement in 2007). However in the end they got a $1.2bn bid from Microsoft before the whole story could come out (I sort of remember MSFT taking a write-down on that one too, but a quick scan of the 09/10/11 10-Ks didn't throw anything up).

Another blow to Europe's tech hopes

It hasn't been a good few years for European tech. With the implosion of Nokia and Alcatel-Lucent we now have very few global tech leaders. Off the top of my head SAP, ASML, ARM and perhaps Dassault Systemes. Capgemini in IT Services (does that count as "tech"?). Most of the mid-sized names are slowly getting picked off - in the last year or so Autonomy, Logica and Misys in the UK alone.

What's more worrisome though is that there are few companies coming through with the to potential to become $10bn (or even $1bn) tech players. Most of them sell out before they get to that stage. I was sad when Autonomy was bought out, because at the time it had the best shot of any of them at making it big. And it would be particularly galling if accounting issues were proven, after the examples of FAST and iSoft in the last few years. What is it, investors may ask, about European software companies and dodgy accounting?

HP are a complete bunch of lemons

There are a lot of I-told-you-so's flying around this week, but the plain truth is there was reasonable doubt over Autonomy before HP came in. The seven points I listed above were all transparent to everyone before HP turned up with a bid at 11x sales. What was even more galling was that after the defenstration of Leo Apotheker they had a golden opportunity to walk away from the deal (the only barrier being a trifling break-up fee) but instead pressed on with it.

Even so given Autonomy's history you would have thought they would have hired the SAS to do the due diligence. At the very least they should gotten a team of forensic accountants in and pulled all the historic customer contracts. Now that's no guarantee (contracts can be faked, as we found out at the recent iSoft trial), but it should have least given an inkling of the proper licence/hardware split.

In this case, I'm afraid, there is no excuse.

Monday, 19 November 2012

A GOOD way to do Bring Your Own Device...

Continuing my series on Post-PC / Enterprise vs. Consumer IT, I want to look at the trend towards Bring Your Own Device. As a recap - previously I wrote about how Consumer and Enterprise IT have historically been very separate worlds in terms of both type of product and how its sold. I then talked about how this means that very few vendors have been able to bridge the gap between those worlds.

However as part of the shift away from traditional PC architectures towards a cloud/Post-PC world I believe these two different worlds are now starting to converge. This is going to have massive implications for how we consume IT and how tech companies make money out of it.

I now want to explore the two ways in which vendors are trying to bridge the gap - firstly by running remote services on pure consumer devices via Bring Your Own Device. Secondly by evolving new categories of dedicated crossover products - Post-PC devices.

Let's get going...


What is Bring Your Own Device?


Bring Your Own Device (BYOD) is the catchily titled idea of letting employees access corporate IT and services via their personal computers and smartphones. But BYOD takes that a step further by letting workers directly consume enterprise IT services like on their personal consumer devices.

This has received a lot of attention, but bear in mind this is nothing new. After all we've been logging into our office machines from home for years. Back in 2002 JPMorgan were even nice enough to pay for broadband for my entire house - something my three other housemates were enormously pleased with. What's different is that the rise of personal smartphones and tablets has put a BYOD-able general compute device in a much more accessible position for employees.


Positives:
BYOD makes this a
thing of the past...


    • Better device: We get to use our personal iPhone for work email. Compared to a standard-issue Blackberry this has the advantage of being a) smaller and sleeker b) not making us look like a corporate dinosaur and c) being capable of running Angry Birds.
    • Less device congestion: This saves us having to lug around ridiculous combinations like personal smartphone + work mobile + work Blackberry. This also stops you  looking like a complete mug at the airport x-ray machine (although as an alternative you could just get a SCOTTEVEST with built in iPad pocket...).
    • It saves your employer money: Also as you supply the device your employer saves money, not only on the capex bill for the intial device, but also the cost of ongoing hardware support for said device (remember I said before that support-maintenance is where the big bucks are in enterprise IT).  This is particularly attractive, of course, in the current belt-tightening environment - in essence by having you supply the device they are getting you to pay them to do you job. :-x

    Negatives:
    • Security/lack of control: This is the biggest issue with BYOD - enteprises spend billions of dollars locking down their machines and ensuring they are secure. BYOD opens a whole can of worms in terms of add complexity and thus security risk. The answer is usually some sort of walled garden or sandbox which restricts what data resides on the consumer device.
    • Limited functionality versus native: The downside of a sandboxed environment is that it tends to limit functionality, either in terms of denying it direct access to the hardware (e.g. sensors, file systems) or making software slower because of additional computing overhead from the sandbox.
    • Consumer hardware constraints: One point I made in my first post is that enterprise hardware is built-to-last whilst consumer hardware is built-to-break. There are a number of trade-offs in terms of product reliability which are undesirable for an enterprise road-warrior. The most important one for me is limited battery life - even devices with best-in-class power efficiency will not last a whole day with heavy data usage. That is a major problem if you are on the road and your iPhone is your only link back to base.
    • Data/contract constraints: Consumer devices are also tied to personal consumer contracts - particularly for data. This present issues around quality of service (not all users have the same operator/coverage or be permissioned to use all services) and cost (e.g. is users are unlikely to use data when travelling abroad unless they get reimbursed for stiff roaming fees). 
    • Platform risk: Another difference between enterprise and consumer IT I highlighted is the lack of a long-term roadmap in consumer IT. Consumer IT companies like Apple and Twitter can make significant changes to their product architecture with little or no warning. For an enterprise IT user used to having years of product roadmap this is unacceptable. Imagine even Apple changes the API permissions on iOS and your sales guys could no longer access their CRM system. Even if a quick fix were implemented it could take months to test and roll out - during which time you couldn't perform basic business functions. Yeah...
    So far, so good. But how does this work in practice? As an example I want to look at Good Technology. Firstly because they one of the most successful standalone BYOD vendors, and are doing some very interesting things around developing a platform (I LOVE platforms). Secondly because, despite their success in the banking industry I've seen very little written about them in public.



    Good Technology - the lucky company



    One of Visto's earlier consumer-focused
    products; the tech equivalent of the crazy
    old grand-aunt you never talk about.
    Like most good tech stories Good Technology's story it involves a good slice of luck (several, in fact).

    The company was founded as Visto in 1996 by a bunch of ex-Javasoft employees. For years it puttered along offering push e-mail, burning cash, and suing anyone who infringed its patents. Think Blackberry crossed with a patent troll, minus the hardware business. Historically its focus was on consumer email but, to be frank, the business was going nowhere fast.

    Then it got its first slice of luck. At the time it was suing Motorola for patent infringement (as it had done with RIM and Microsoft). And at the same time Motorola was also looking to sell non-core assets such as Good Technology, an enterprise-focused email provider it had bought for a cool $438m for just a year earlier. It looks someone put put two and two together, settled the litigation and threw Good Technologies into the deal to boot. The deal was so good (no pun intended) that after closing the acquisition in early 2009 Visto renamed itself after the target.

    Acquiring Good gave Visto, which had always been consumer-focused, a much stronger position in the enterprise market. But then again that wasn't necessarily a great place to be - Blackberry obviously dominated enterprise email with its corporate-friendly NOC architecture, and mobile leader Nokia was hot on its heels after its 2006 acquisition of Intellisync.

    But then it got its second slice of luck - just as Good started to push (again, no pun intended!) into the enterprise market it founds its biggest competitors RIM and Nokia being decimated by the onset of the iPhone. However while they remained tied to the inferior hardware and unable to offer credible enterprise email on iPhones, Good could.

    So what does Good do?


    Good's BYOD armoury



    Good email on iPad. What the Playbook should have been...
    Good offers two key products. It's bread-and-butter is its push email solution Good for Enterprise. Effectively this lets you access your corporate email, calender and intranet web browsing on a completely secure sandboxed app on your iOS, Android or Windows Phone 7 device. You simply download the app from the relevant App Store, login in with your pin and off you go.

    This means that everything you can do on your Blackberry in terms of getting push email and operating within the corporate firewall can be done on your smartphone.

    The architecture isn't rocket science. Basically they have their own servers embedded both sides of your firewall to provide a secure link for your data. They then forward the data over an encrypted mobile connection to the Good App which is run in a secure container on your smartphone. Data stored on the smartphone is, of course, encrypted as well:


    It's pretty much the same as what Blackberry did all those years ago - just substitue "Blackberry NOC" for "Good NOC" and "Blackberry Enterprise Server" for "Good control/proxy server" and you could be in Waterloo, Ontario.

    The difference is that while Blackberry's email services are only available on its hardware, Good will give you clients which run on Android, iOS and Windows Phone 7. This means as the end user you don't need to worry about ensuring compatibility/security with all these devices. Good will handle that for you.

    Good's second product is its more interesting one, an app platform called Good Dynamics launched just over a year ago. This takes the same infrastructure used for Good for Enterprise, but exposes it to third party apps. This means that an independent software vendor (ISVs) can build at app which runs on an iPad but plugs directly into a customer's internal app servers via the same secure pathways which the Good email service uses (obviously Good will charge for this, most likely by taking a cut of the ISVs sales and then charging the customer a stiff premium for the control/proxy server).

    Much like the Bloomberg App Portal I discussed last week, this offers small software vendors a way to plug into a heavy-iron enterprise IT systems in ways they wouldn't have been able to do on their own. In return Good receives both the direct financial benefits, and also the network effect of having its service (hopefully) before the go-to platform for mobile apps.

    Apps based on Good Dynamics are already up and running - check out this link for a list of ISVs or simply fire up iTunes and search for "Good Technology" in the app store. Here are a few examples:
    Roambi lets you take pointless charts on the road!

    • Box: Allows users to share share files with each other. Also offers security & mgmt features such as remote-wiping of files.
    • Splashtop: Remote desktop client which lets you plug into your computer at work via your mobile.
    • Roambi: Analytics platform which lets you pull data from your business intelligence system back at base and display it on your iPhone. (NB - sounds a lot like the mobile analytics stuff SAP has been doing with the Sybase Unwired Platform)
    • Breezy: Cloud printing app which lets you to print documents to any networked printer.

    You get the idea... Nothing earth-shaking at the moment but a lot of potential if they can get the platform right.



    How big is Good Technology?



    Good has had strong momentum with its core email/calender/browser app over the last few years, particularly amongst banks. You can see this in the chart below which shows device activations split by industry. According to the company they now sell to 4,000 organisations worldwide, including over 50 of the Fortune 100 US companies.

    Of course all such statistics should be taken with a pinch of salt but I've heard first hand of a number of big Wall Street banks who are users - these guys have clearly got over the hump of credentialising themselves with corporates.
    Source: Good Technology Device Activations Report, Q2 2012









    They also seem to have a jump on the competition at the moment - as I said I've heard of several banks using Good but haven't heard of anyone using an alternate solution. At the moment they seem to be in the sweet spot of being bigger than any other fast-moving startups (e.g. Enterpoid's Divide platform or Android specialist 3LM), and faster-moving than any bigger established vendors (e.g. SAP's Unwired platform - a clear competitor for Good Dynamics - or Citrix).

    Note: Number in blue are hard data from annual reports.
    But how big are they? Unfortunately financial data is hard to come by, but its clear from what's out there they are a force to be reckoned with.

    Let's start with Motorola. Remember Motorola paid a (not inconsiderable) $400m+ for the business in 2007. Not a bad starting point. Then two years later they sold it on to Visto. They didn't disclose how much Visto paid them, but you can do some interesting detective work around Motorola's 2009 annual report.

    Footnote 2 on page 87 discloses that MOT recorded a gain of $175m on disposals in that year. In that period they sold two assets - Good to Visto and their Printrak biometrics business to Safran. Safran's 2009 annual report says they paid $181m for this (p82). We know that at the end of 2008 Good Technologies was carried at a book value of roughly $300m (they paid $438m and took a write-down of $123m on the asset in 2008). So even if we assume Printrak had been held on the balance sheet at zero cost, the gain on disposal implies that Visto paid roughly $300m for Good.

    PS Yeah I'm showing off my forensic accounting skills here. And yeah I'm probably completely wrong due to exogenous factors (patent litigation settlements?) :-p

    Note: Numbers in blue are hard data from annual reports.
    NB the Motorola report also discloses $19m of revenues from the two disposals in Q1 (Good was sold end-Feb, Printrak sold end-Apr). Safran reported €32m ($44.5m) of revenues for the remaining 9 months of Printrak in 2009 which implies a $14.8m run-rate for the Q1 reported by Motorola. This implies $4m of revenues for Good in Jan-Feb implying a $25m annualised run-rate. Note of course this was before the whole iPhone/BYOD schtick took off, so I wouldn't say that's representative of the current business. Plus there's also the revenues Visto had before it bought Good - consumer push email (probably negligible) and patent royalties (likely more sigificant, and very high margin).

    So how big is Good Technology now? To be honest haven't a clue. But if I had to hazard a guess I would say somewhere between $100 and $1bn of revenues (probably the lower half of that range). Pass me a pin please I think there's a donkey I need to affix a tail to... :-x



    Larry Ellison's next acquisition?



    I think the broader point to make is this: Good Technology is not some fly-by-night startup. It's got a set of assets which people have been prepared to pay triple-digit millions for in the past, and since then its taken significant share in an explosive market. I would be very surprised if this was not a hot IPO candidate in the couple of years.

    What's much more likely though is that they will be bought out by a larger enterprise software vendor. Its just a matter of whether this happens before or after the IPO (my bet is before - in this fast moving market no-one can afford to wait). Good Technology is owned by VCs - they will sell for the right price.

    There's already been scuttlebutt about McAfee kicking the tires (dumb idea in my view as that would tie them into Intel at a time when the core smartphone market is going all ARM). The more likely acquirer is one of SAP, Oracle or IBM - i.e. a big-iron enterprise software vendor which doesn't own its own smartphone ecosystem (i.e. not MSFT).  My strongest hunch is that they end up going to Oracle - Larry Ellison has an obvious gap in his armoury on the mobile front, particularly vis-a-vis SAP which made a smart move buying Sybase's assets. Something like the Good Dynamics platform would plug that very nicely.


    Why I don't think BYOD is the answer


    Okay after than brief jaunt into the BYOD-osphere back to the program. I'll be frank - I do not think that BYOD is the answer. I think at best it's an interim solution while tech moves towards a genuine converged device (the Post-PC device) which runs cloud-based consumer and enterprise apps side by side.

    There are big issues I have with BYOD which I'm not sure even Good has grappled with.

    The first is that architecturally speaking its a kludge, a piece of middleware which sticky-tapes a window through the enterprise firewall onto you consumer device. It a short-term patch rather than a long-term answer. What you basically have is the same old enterprise spaghetti-ware back at base, except this time you've layered a few hundred more not-quite-thin client apps on the smartphone side to crunch the data Good has fetched for them.

    I think that's a compromise which reflects the fact that mobile networks are (still) not fast enough and ubiquitous enough to run genuine cloud apps straight into a secure mobile browser. But as networks continue their exponential improvement (hey we've just gotten LTE in London!) you will see the need for this patchwork solution fall away.

    The second is that there is a great deal of platform risk associated with Good's efforts. Take the Good Dynamics platform for example. It reminds me a lot of what Facebook is trying to do to encourage developers to have "social apps" which run on iOS but share data via Facebook. The problem with this model is that if Apple decides that Facebook or Good's platforms are freeloading (or competing) with its own APIs all they have to do is change the terms of service and ban those platforms. That's bad news for Facebook and Good, but that's horrific news if you're an enterprise which is accessing critical IT versus the Good infrastructure.

    That is a risk no sane CIO will want to take.

    Okay that's all for today (its 4pm and all I've had to eat today is a boiled egg). Next up I want to expand on why a genuine Post-PC device is the solution to the Consumer / Enterprise divide. A bientot!

    Friday, 16 November 2012

    The Hacker Way (More Cookbooks Than Sense!)


    A fun bagatelle for a Friday. On my off days I run a Cookbook blog. Not a vast amount to do with tech but occassionally, just occassionally, the two worlds collide. So I thought I'd cross-post the review I put up today of Jeff Potter's fantastic Cooking for Geeks: Real Science, Great Hacks, and Good Food.

    Here's to the Hacker Way!


    One thing to Like about Facebook


    Down to his last 11 bil...
    For those of you who follow the stock markets, Facebook's recent IPO hasn't been its finest moment. Since debuting at a heady valuation $104bn, the company is now worth 42% less than it was in May. I understand poor Mark Zuckerberg is now down to his last $11bn. Lawsuits are already flying.

    But if one good thing did come out of the whole mess it was Zuckerberg's Founder's Letter, which was included in the initial IPO filing. In it he laid out his vision for Facebook and the culture which brings it about. Just as Google used its 2004 Founder's Letter to set out the mantra "Don't be Evil", Zuckerberg believes in "The Hacker Way".

    Setting aside your view on whether Zuck is a privacy-snatching scumbag (I tend to sit in the "yes" camp), there's much to admire here. As he says:
    The word “hacker” has an unfairly negative connotation from being portrayed in the media as people who break into computers. In reality, hacking just means building something quickly or testing the boundaries of what can be done. Like most things, it can be used for good or bad, but the vast majority of hackers I’ve met tend to be idealistic people who want to have a positive impact on the world. 
    The Hacker Way is an approach to building that involves continuous improvement and iteration. Hackers believe that something can always be better, and that nothing is ever complete. They just have to go fix it — often in the face of people who say it’s impossible or are content with the status quo.
    There's more, but in a nutshell the Hacker way is questioning, meritocratic and "can-do" attitude which is always trying to push the boundaries. Which believes "Done is better than perfect", and that "something can always be better, and that nothing is ever complete".

    So what's this got to do with cookbooks?

    Well the answer is Jeff Potter's slug of culinary hacksomeness: Cooking for Geeks: Real Science, Great Hacks, and Good Food.



    Don't ask what. Ask how and why


    This isn't your usual celebrity cookbook. Jeff Potter doesn't have a posh restaurant or a michelin-starred diffusion chain (although he did get a TV gig on the back of this book). He's a old-fashioned IT geek and food nerd who decided one day to write a book.


    And he didn't go through your usual publisher either. Rather take his cook to a culinary powerhouse like Artisan, Quadrille or [a curse on all their houses] Phaidon, Potter went to O'Reilly Media. This is a specialist tech publisher best known for publishing haute-geekologie texts like The Cathedral and the Bazaar (the canonical gospel of the open-source movement) or gripping blockbusters like Learning PHP, MySQL, JavaScript, and CSS, 2nd Edition (and yeah I'm sure if I read it this blog would look a lot better!).

    And finally he doesn't think like your usual cookbook writer either. As he says:
    At our core, though, all of us geeks still share that same inner curiosity about the hows and whys with the pocket-protractor crowd of yesteryear. This is where so many cookbooks fail us. Traditional cookbooks are all about the what, giving steps and quantities but offering little in the way of engineering-style guidance or ways of helping us think.
    What you get is a book which doesn't just follow the recipe, but wants to understand where the recipe came from, why it works and how it can be improved. That is that Hacker Way.

    Thinking not only about what works together, but why
    it works together (click image for full table)
    How does he do it? The book is laid out in three main sections. The first section deals with the stuff you should know before you turn on the oven: What sort of cook are you? What is your basic kitchen setup? How does physiology (and psychology) of taste work and why do flavour combinations come together? This is probably the weakest section of the book, but a necessary evil.

    The second section is where he really gets going, analysing the key Variables which affect cooking - time, temperature and air (many chefbooks are full of hot air, but this is the first one which devotes a whole chapter to it...).

    But its in the final two chapters where Potter really kills it, as he addresses the more, er, "creative" things you can do in the kitchen. He splits this into two chapters - one on chemicals ("software", as he calls it), and one on equipment and gadgets ("hardware"). This contains the stuff most recognisable from the Heston/El Bulli/Noma world of molecular gastronomy. With a vengeance.

    But that's not all. Potter also gives dozens of recipes to demonstrate the principles. Note this isn't primarily a cookbook - the recipes standalone are distinctly uncheffy (although I am quite taken with the Calamari Crackling on p202). But what they do is practice what he preaches, by introducing startling new angles on old favourites. A chocolate cake is microwaved in 30 seconds flat. Duck confit is made without any duck fat. A Tiramisu recipe is repurposed as an engineering time/activity chart (via Cooking for Engineers)...

    A new way to Tiramisu...

    But that's not all. The text is also broken up by over twenty interviews giving expert insight on a variety of topics. Food science demi-god Harold McGee opines on Solving Food Mysteries. Le Bernardin patissier Michael Laiskonis chips in on Pastry Chefs. And don't miss Jeff Varasano's eye-popping digression on Pizza (if you haven't heard of him before, this is a man who's iconic pizza recipe runs to over fifteen thousand words). So as well as Mr Potter's wisdom you basically get a culinary boot camp thrown in for free.


    Great hacks


    But it's the hacker mentality that's at the heart of this. And this is a book full of great hacks.

    Hacking is a mindset more than anything else. As Zuckerberg said, its the result of combining constant questioning with continuous iterative improvement. Potter also throws in the idea of "functional fixedness" - mentally restructuring your world so you use your tools in ways their designer never dreamed of.

    This can be something as simple as slapping a few rubber bands on the each end of a rolling pin to allow you to roll a pizza dough out to a uniform thickness, or roasting peppers in a toaster. Or it can be as wild as clipping the lock off your oven and short-circuiting the electronics so you can use its 800c cleaning cycle to bake pizza (it worked, but Potter had to upgrade the oven door to missile-grade PyroCeram glass to keep the heat in).

    This book is full of great hacks. If you don't feel like overclocking your oven, he explains how to make a Lego Ice Cream Maker. Or if a $450 Sous Vide Supreme is out of your price range he gives step-by-step instructions about how to lobotomise a slow-cooker with a thermocouple to create your own home-made sous-vide rig.

    Julia Child eat your heart out.

    But what's also refreshing is the hacks aren't just there for shock value. There are also simple things. For example Potter shows you how to calibrate your oven with a bowl of sugar (sugar melts are 177c, giving a precise reference point for oven temp). He outlines how to mill your own flour. And he sagely points out that the most overlooked but useful thermometer in the kitchen... is nothing more complicated than your hand.


    Real science


    The hacks go hand in hand with exposition. Everything Potter does is underpinned by hardcore food science (I'd expect nothing less from an engineer and a nerd). And this is a great book on food science.

    The middle section, on Variables, gives one of the clearest explanations I've seen about how temperature affects food. And more important it isn't only how hot the food gets, but how long it stays hot. The idea of a time-temperature curve, and how it affects different cooking methods, is beautifully laid out in Chapter 4:



    And he doesn't shy away from the nasty stuff. There's a whole section on foodborne illness for example, helpfully split out into sections on "Bacteria" and "Parasites". He gives great advice on how to avoid Bacillus Cereus and tapeworm, although unfortunately to nail both of them you need to both freeze your food and heat it above 60c. Tricky.

    (And while not quite food science, but he also throws in a brilliant game-theory inspired cake cutting algorithm to make sure no-one complains about getting short changed.)

    The highlight of the book though is the last two chapters. As I mentioned already, Chapter 6 deals with "software" (chemicals and additives) and Chapter 7 with "hardware" (food gadgets FTW).

    The section of food chemistry goes through all the usual suspects you've seen popping up on A Heston Blumenthal TV show, with a clear explanation and practical examples. Potter is careful to put everything into a clear context.

    Take colloids for example. While they may sound like a species of alien parasite, in fact they are simply a mixture of any two substances - gas, liquid, or solid - uniformly dispersed in each other but not dissolved together. Basically a suspension of A in B, or as he helpfully summarises:

    Attack of the Killer Colloids...
    There. Now you know. Chocolate is a Colloid.

    If you don't know your Methylcellulose from your Maltodextrin then this is the place to come (Methylcellulose melts as it cools. Maltodextrin melts in the mouth). But what's also great is that Potter doesn't get carried away with his rocket science. He makes the very helpful point that using chemicals in food is nothing new, and backs it up by showing how salt, sugar, acids and alcohol are equally important in food science (Bacon-Infused Bourbon anyone?).

    What a shockingly good recipe!
    The last chapter on Hardware is the one with the really fun hacks - the overclocked pizza oven and DIY sous-vide machine all feature here. But there is also a comprehensive twenty-page teach-in on the techniques behind sous-vide cooking ranging from "standards" like 48-hour low-temp beef brisket to cute applications I haven't seen elsewhere, like using sous-vide to temper chocolate (one of the trickiest jobs in the pastry kitchen). Plus there's a bit of stuff on rotary evaporators, foam guns and anti-griddles, but I guess that's pretty much par for the course.



    Better than Modernist Cuisine?


    Of course when you have any book which deals with food science the elephant is the room is Nathan Myhrvold's five-volume, 24 kilogram opus, Modernist Cuisine (the only item in my collection that works better as a bedside table than a cookbook). While Cooking for Geeks covers much of the same ground, at 412 pages versus 2,438 for MC it's hopelessly outgunned in terms of depth.

    But the funny thing is I think that Cooking for Geeks is actually the better book on food science.

    You see its the Hacker Way in action. Modernist Cuisine represents Myhrvold's set-piece assault on the subject, where he brute-forces the problem with sheer weight of resources. To write his book he set up a fully staffed lab, including a hundred-ton hydraulic press, a rotary evaporator and an ultrasonic welder.

    In contrast Jeff Potter had two feet of counter space plus a 2" x 4" board hanging across the sink. So rather than throwing money at the problem he falls back on his wits and his hacks. It reminds me of the (apocryphal, alas) story about NASA spending millions of dollars designing the absolute perfect Space Pen, and the Russians just using a pencil.

    Reading them both, I actually find Cooking for Geeks gives a simpler, clearer and above all more fun explanation of what makes cooking tick. Our Nathan may have billions of dollars, dozens of experts and an autoclave, but Jeff has "Real Science, Great Hacks and Good Food".

    I know which one I'd rather have...


    Afterword: Strategy consultants could, I imagine, have all sorts of fun with this analogy of plucky agile newcomer vs. lumbering giant. I'm definitely on the side of the underdog here, not least because in his day job Nathan Myhrvold doubles as CEO of Intellectual Ventures, one of the more egregious patent trolls currently blighting the tech world. Grrr don't get me started... J