• This is a really good move for IBM as it establishes IBM as the de facto leader in Cloud integration
• This gets IBM some really good mid-sized clients and a mid-sized client-friendly business model
• Cast Iron offers significant value to IBM’s customers by radically simplifying the process of integrating cloud-based apps like SalesForce.com, google docs and a host of others either with eachother or with “non-cloud” apps like SAP.
• The number of different API’s and, indeed, API approaches adopted by different SaaS and Cloud players makes it a real pain to integrate them – Cast Iron makes it possible to link SAP with SalesForce.com in seconds rather than days or weeks
• While this is an excellent addition to IBM’s integration portfolio, it has also added (yet) another way to specify how two applications interact which places the onus on IBM to help customers decide which approach/technology to use

This is a really good move for IBM as it establishes IBM as the de facto leader in Cloud integration

Cast Iron Systems was originally founded as a web-EAI company and has recently repositioned as a cloud integration company. The company offers a combination of middleware, tooling and adapters that allow a range of cloud and non-cloud applications to interconnect.

IBM has been working on addressing the integration challenge presented by the explosive growth in the number (and adoption) of SaaS applications so will have been well aware of the the value that buying all of this technology already built – and pretty widely deployed.

This gets IBM some really good mid-sized clients and a mid-sized client-friendly business model

Looking at Cast Iron’s client list, it’s clear that the company has enjoyed a deal of success in the mid-market – which is the segment that is most actively adopting SaaS in anger, so in acquiring the company IBM is gaining an important foothold in a very important part of the market for SaaS and cloud.

Cast Iron also supports a more mid-sized business-friendly way of doing business (low entry cost, and a range of pricing/charging options that IBM is very likely to replicate elsewhere.

Cast Iron offers significant value to IBM’s customers by radically simplifying the process of integrating cloud-based apps like SalesForce.com, google docs and a host of others either with eachother or with “non-cloud” apps like SAP.

It would be disingenuous to write this announcement of as “IBM Buys some adapters” – but even if it were just that,  the coverage is pretty impressive – with adaptors in place for Salesforce.com,  Oracle CRM On Demand, Google Apps, NetSuite, and others as well as adaptors for  SAP,Oracle EBS,PeopleSoft, JD Edwards and Siebel as well as several others on the non-cloud side of the fence.

The number of different API’s and, indeed, API approaches adopted by different SaaS and Cloud players makes it a real pain to integrate them – Cast Iron makes it possible to link SAP with SalesForce.com in seconds rather than days or weeks

Having waded through the docs for the google API set, Twitter’s, PayPal’s and SugarCRM’s (to name a few), I can tell you with personal experience that it’s a real pain. While all of the API’s are essentially service oriented, they’re all documented differently and all implemented differently. They’re also subject to change. Managing the integration of one of these apps with one that you’ve either developed yourself or that you run on your own systems is “a bit of a pain”, doing it with two is “gnarly” and doing it with more than two starts to become really annoying.

You don’t quite appreciate how much of a pain it is till you see someone demo Cast Iron’s solution to the problem – SAP to SalesForce.com integration was demoed, live, in under five minutes.

Really… it took less than five minutes to have SAP injecting new clients into SalesForce.com. That’s less than 300 seconds!

While this is an excellent addition to IBM’s integration portfolio, it has also added (yet) another way to specify how two applications interact which places the onus on IBM to help customers decide which approach/technology to use

There is a minor caveat – IBM has now got “another” integration technology to offer customers, who are already perhaps a little spoilt for choice when it comes to picking places to drop that integration logic. Unwary clients could find themselves doing really unpleasant and gnarly things by writing custom transformations or business rules within the Cast Iron tooling (which even allows clients to write custom logic in Javascript) . IBM needs to make it clear that the Cast Iron technology is really, really, useful in the context of COTS to Cloud integration but that there may be better places for describing complex business rules and transformations.

This morning Glyn Moody retweeted this article, it seems that  maker of “Downfall” , Constantin Film Distribution has taken steps to oblige the likes of YouTube to take these parodies down on the grounds of copyright infringement.

First, I’ll have to admit that part of me is little uncomfortable about a film extract depicting a man directly and indirectly responsible for the deaths of tens of millions of people being used for comedy purposes. But I’ve had it pointed out to me that, culturally, it might actually be part of the healing process to depict this evil evil creature in a darkly comic light. Besides, there’s plenty more publically accessible content that is a whole lot more distasteful out there.

Next I’d add that I don’t think these clips do infringe, since in most cases they represent less than 2% of the original I would say that they represent fair use. But I am neither a Lawyer nor a Texan judge, so my views on IPR law aren’t overly special.

Whatever the law, and whatever the dubious tastefulness of these parodies, Constantin film is making a mistake in blocking these parodies. If Constantin were smarter, they’d have promoted them, hell if I were the company I’d have found a developer to build an app that made it easier to create the parodies and hosted it on my website.

This bad call on Constantin film’s part neatly presents the division between the people that “get” the notion (and power) of the creative commons and those that don’t.

Evidently Constantin film is a “don’t”.

Todd Lapin acknowkedges that his little’un is already iPhone savvy – but still… I found this video awesome.

Edit save reload,
tab to the error console
Javascript sucks so

(Gary Barnett 4.00 AM 30/March/2010)

This morning Apple’s homepage looks like this :-

Apple's home page on 18th March 2010

This is a powerful and touching tribute, and one that says something to me about Apple too.

I’d like to express my condolences to Mr Yorks family and friends.

Oh yes, my blog was hacked. So, an afternoon of trying to figure out what happened has culminated in a frech install and a restore – Thank goodness for backups eh!

Essentially :-

• It is silly to equate the PC market with the handset market
• Err… So “Unix” won did it? Now I thought Linux wasn’t Unix….
• So windows was successful because it provided a platform for other people to make money..and Apple has provided a way to help developers make money, and ensures consumers don’t install rubbish on their phones and that’s bad?
• WinMo isn’t comparable to Android – but Java is and that hardly created an exciting apps ecosystem
• Oh and Symbian is open sourced because its backers know it’s dead

It is silly to equate the PC market with the handset market

They are not the same – the handset is an appliance, the PC is not. Handsets are more readily likened to games consoles. So it’s immediately pointless to draw conclusions from the history of the PC market and apply them to the handset market.

Err… So “Unix” won did it? Now I thought Linux wasn’t Unix….

When Eric says:

And isn’t it entertaining, boys and girls, how thoroughly Unix won? Both OS X and Android are Unix underneath.

My second most immediate response was “Err…. actually the Android is based on Linux, which really is not Unix – but then you should know that? So are we all now going to say Linux is Unix ? Unix FAILED – it broke into different factions (initially dozens) and then we saw a slow consolidation then along came Linux which effectively wiped the board of all but a couple of Unix variants (And IMHO – AIX and HP-UX are the only two Unixes that have any legs on them). It’s important not to rewrite history by deluding ourselves that Linux = Unix and that that’s all good. Because it misses the fantastically important point that the success of Linux is that it does some very low level stuff, really well and there’s no point in differentiating your product on the basis of how pointer references are hashed in some obscure part of the kernel.

The success of Linux lies in people agreeing that having choice at the kernel level isn’t all that interesting.

[My first most immediate response was - "Don't patronise me you....."]

So windows was successful because it provided a platform for other people to make money..and Apple has provided a way to help developers make money, and ensures consumers don’t install rubbish on their phones and that’s bad?

Here’s the thing – Windows was successful because it provided a means for other people to make money – true. But SO HAS APPLE!!! The AppStore would not have the massive number of apps if Apple hadn’t provided a very clear mechanism through which people could publish and monetize their software.

WinMo isn’t comparable to Android – but Java ME is and that hardly created an exciting apps ecosystem

It’s not really fair to compare WinMo and Android, first let’s look at WinMo vs J2ME. Which was more successful? Well the numbers would indicate Java… it’s running on a hell of a lot more phones than WinMo, let’s face it. But again, – Has J2ME created a vibrant apps marketplace? No – because device vendors didn’t want to support an open market place – 1) because they wanted to control everything 2) they had genuine concerns about stability 3) App portability across phones is a nightmare

Android is much more analogous to J2ME than it is WinMO – WinMO (arrogantly) tries to mandate device function while J2ME tries (valiantly) to provide device flexibility – at the expense of app portablity. Android is trying to do a very similar thing to J2ME, and will suffer the same challenges as a result.

Oh and Symbian is open sourced because its backers know it’s dead

The competitive dynamic between Linux/Android and OS X can be understood in the same way. OS X is playing a control game and Android a ubiquity one. We can expect the outcome to be the same: when the bazaar meets the walled garden, the walls will eventually come down, crushing the life out of the garden.

This is why Symbian is now open-source in spite of having no inheritance from Unix-land; its backers have figured out that a control strategy collects short-term gains over a ubiquity strategy but simply cannot compete in the longer term against open-source Android and open-source

Aww puhlease …. Symbian open sourced because it’s backers have figured out that OSS is the way to go??? Nah… Symbian was dying so they took a wild punt at OSS’ing it (As Sun did with Solaris) and it’s not helped Symbian (or Solaris for that matter).

The key weakness in Eric’s post (and position) lies in the assumption that the Andoid vs iPhone battle can be understood in the same way as the PC vs Mac battle  – and it simply can’t be.

Oh I should add that I am an iPhone fanboy, and proud to be so

So, here’s the short version:-

• iPhone vs Android isn’t coke vs pepsi, it’s coke vs virgin cola
• It’s disingenuous to say that the iPhone is for “Play” and the Android for “Work”
• Today the iPhone strikes a much better balance between the desires of consumers vs developers
• Consumers don’t care about “open” they care about “now”
• Multiple Android distros is BAD for Android, not good
• Flexibility and choice are attractive to developers but often a nightmare for consumers
• Multiple formats and screen sizes represent too much choice
• I’m not sold on “Open Google” in the way that many commentators are
• Its just not clear which will win, but right now iPhone is still well ahead

iPhone vs Android isn’t coke vs pepsi, it’s coke vs virgin cola

The first point I disagree with is that the comparison, for basic users, between the iPhone and Android is like Coke vs Pepsi. While I think there’s a good chance that Android will close the gap (I don’t think it’s certain as I’ll explain) right now the comparison is Coke vs Virgin Cola.

As Peter acknowledges, the iPhone app market place is dramatically larger and deeper. Although I’m sure that the Android marketplaces will continue to develop rapidly.

The Coke vs Cola analogy is interesting because we know that the essential ingredients (or features) of Coke and Cola are pretty much the same, Coke beat Virgin Cola on a host of levels that extend way beyond the simple features of the beverage but two of the reasons are particularly relevant -  Coke had brand (perhaps most important) and Coke had distribution. Android phones don’t have anything like the brand clarity of the Apple iPhone; Google is a fantastic brand, but that’s not the brand the device manufacturers are pushing, they’re selling their own brand – because they’re rightly worried about giving up their brand identity. The second issue, distribution, is also important. iTunes and the AppStore have a massive established base that right now is unrivallable.

It’s disingenuous to say that the iPhone is for “Play” and the Android for “Work”

I’m not convinced by the “style difference” that Peter says exists when it comes to apps for iPhone vs Android. To begin with, it’s a little disingenuous to imply that iPhone developers play on our baser instincts (by offering us porn) while Android developers feed our souls (by unlocking the power of the phone’s “inner” unix machine). There are many more business apps available on the iPhone (in addition to the games, and silliness) and indeed, my iPhone satisfies my inner geek immensly by giving me a VNC client, so that if my fingers were really tiny I could write this blog on my Ubuntu laptop via my iPhone – how cool would that be!!

Peter makes a sterling attempt to convince the reader that the ability to write your own ‘nix shell scripts is a boon for non-techies but I simply don’t buy the idea that “rough but workable tools” are for “all comers of the enterprise”.

Today the iPhone strikes a much better balance between the desires of consumers vs developers

Many developers hate the closed garden that Apple’s Appstore represents, and Apple seems not to mind giving them new reasons to dislike the restrictions that are imposed. But it’s a question of balance. Apple is trying to balance the provision of a great place for people to find nifty apps for their device, and the provision of a great place for developers to publish and monetize apps they sell. This isn’t an easy balance to strike, and Apple’s policy would seem to be to err on the side of the consumer rather than the developer.

So I find it difficult to beat Apple up for protecting the integrity of its appstore. It is possible, of course, to spin this by saying “Apple is cynically protecting it’s marketplace” but that would be a little bit like saying “Coke is cynically protecting it’s logo” or “The lion cynically killed the gazelle”. Of course Apple has to protect the integrity of the AppStore, and I’ve no doubt that there are plenty of parents across the globe who are delighted to see Apple moving against the smutty apps. I think Apple will need to adjust its stance over time, but right now there doesn’t seem to be a shortage of new apps in the queue for the app store.

Consumers don’t care about “open” they care about “now”

I’m not convinced that “open” ecosystems always produce more innovation than closed ones, but I certainly believe they’re more likely to. So I do believe that the relative openness of the Android platform offers greater potential for future innovation than Apple’s closed alternative, but the problem is that consumers don’t care. They wont pick an Android over an iPhone because it is based on a better moral framework, or because it offers a better path to choice and innovation, they’ll pick Android over an iPhone based on their current desires rather than their future needs.

Multiple Android distros is BAD for Android, not good

I also disagree with Peter when he says “it’s a java world”, and that the emergence of new android distros is a good thing. I agree that some folks are indeed “relentless tinkerers” – but the idea that it would ever be a good idea for an enterprise to put a nice custom interface on top of Android hardware is an absurd one for the vast, vast majority of enterprises. Yes, if you’re Fedex and you want the perfect UI for the 30,000 devices you give to your drivers, but for most organisations the  “tinkering” with the UI layer of an operating system should be punishable by death.

Flexibility and choice are attractive to developers but often a nightmare for consumers

In the early days of Linux the ability to control or modify absolutely anything was seen as a key selling point. But then the reality that only a tiny, tiny, minority of people actually do modify their o/s (Less than 1% of Linux users ever compile the kernel. I’ve compiled it 100’s of times – and have even successfully compiled it twice..).

My development experience does, however, echo Peter’s – TTHW (Time to Hello World) is a really significant factor in establishing developer affection for a platform or technology, and the openness of the Android platform does mean that TTHW is shorter than for the iPhone. If the world were exclusively populated by developers then the iPhone would be dead and we’d all be using Droids, although as one of my developers pointed out, if the world were exclusively populated by developers we wouldn’t need phones at all – We’d all be communicating via the WOW forums.

Multiple formats and screen sizes represent too much choice

Apple has the good fortune to know precisely what screen format and size it needs to address, but the Android O/S doesn’t – so the Android has to provide support to different device formats and capabilities. Again, I have to agree that this leads to greater choice, but I worry that it inevitably leads to too much of it. Writing Java Apps for phones is made so horrid and unpleasant precisely because of the differences between devices – so on one hand you have the school that tries to implement support for this, while on the other you have the (Microsoft) school that effectively mandates device characteristics – neither of which results in much success. As Peter points out in his blog there are already Android apps that will run on some devices and not others and we all know how awful Win ME phones are…

Apple, of course, controls both the o/s and device.

I’m not sold on “Open Google” in the way that many commentators are

Again, Peter points out some of the issues here in his blog, but takes a slightly more generous view of Google’s motives and likely plans. Google has shown (as per the Google Maps example in Peter’s blog) that it’s not as keen on “open” as some of its cheerleaders would have you believe.

Ultimately, it’s the ecosystem that will keep Google open, and (I believe) it’s the ecosystem that will force Apple to be more open over time.

Its just not clear which will win, but right now iPhone is still well ahead

If I really did know who would win, I wouldn’t be blogging, I’d be sipping a marguerita on my private island.

But my wild stab is this.

• The Android platform needs to offer less choice, not more if it is to win.
• Apple will need to offer more choice not less if it is to extend its lead.
• There is an opportunity for Adobe to offer an easy to develop, app store enabled, Android client platform for bizapps (Air for mobile)
• If there were any justice in the world we’ll be writing most of our rich internet apps using HTML 5 in the near future (To paraphrase Captain Sensible – you gotta have a dream.

“Financial crisis,
Stalled too many customers
CEO no more,”
he wrote.

The article encouraged readers to come up with their own haiku, and here’s mine…

Absent strategy,
customers will leave
time to get hair cut

This post may be read to the strains of the wonderful Ella Fiztgerald singing “There may be trouble ahead”.

Having slogged through the marathon that was the Oracle-Sun announcement day, we’re left with two immediate impressions:
1.They took a heck of a lot of time to say so little
2.Oracle’s back to the future pitch, while nothing like as badly thought out as some people say, just isn’t going to cut it.

If you’re in a hurry, here are the headlines:

• The back to the 60’s mantra is both more and less nuanced than you might think
• But the integrated stack pitch simply isn’t well enough thought out
• There are two killer reasons why the “single stack” pitch fails: Innovation, and Focus
• Ultimately Oracle’s hardware strategy is simply not convincing enough
• Oracle’s software strategy is much more coherent but Sun brings a mixed bag
• The absence of a services story is the elephant in the room

We’ll be thinking, talking and writing in much more detail about this – so if you’re interested in knowing more, drop me a line – gary@bathwick.com

The back to the 60’s mantra is both more and less nuanced than you might think
Perhaps the most headline grabbing component of the strategy is the notion that Oracle is planning to emulate the IBM of the 1960’s by delivering a highly integrated stack from top to bottom.

Superficially this seems like total nonsense and no doubt the die-hard Oracle knockers will make much of this “backward thinking”. But you have to remember that when Charles Phillips presented the idea he added the caveat “…but built on open standards”. Oracle isn’t advocating a return to the tightly closed proprietary systems of the 60’s; the company is focussing on the “up-side” that came with those integrated systems – improved reliability, better integration, and a single source of support.

The problem with this guiding strategy is that it isn’t anything like as revolutionary as the sound bite might appear. Of course clients want things that are more reliable, offer better performance and deliver better economics (can you imagine anyone saying they want less?). This may be why IBM has been offering tightly integrated hardware and software bundles for a long time, even before it became necessary to describe them as “appliances”.

But the integrated stack pitch simply isn’t well enough thought out
The “integrated from top to bottom” story is superficially appealing, but doesn’t stand up to scrutiny particularly well.

Let’s begin with the “complete systems” chart above. Firstly there is a pretty compelling argument (made by IBM) that there is significant benefit from not having an apps business. IBM argues that customers gain by using a platform that supports the widest possible applications ecosystem – Apps vendors and clients then both gain the best infrastructure expertise and the best industry expertise. When it comes to industry expertise IBM can argue that it offers a breadth of industry expertise that spans a wider range of verticals and runs deeper into the infrastructure than Oracle and Sun’s (with the possible exception of telecoms where Sun really does have deep roots). We were also entertained by Oracle’s characterisation of SAP – they will no doubt be a bit surprised in Walldorf to learn that they don’t have any vertically focussed apps.

Oracle’s primary assertion is that it’s easier to deliver an innovative stack if you own all the components – a point made repeatedly throughout the briefing. In his opening pitch Charles Phillips said this:-

“If you have separate companies at each layer, one company building the DB, another building the storage etc it’s very hard to get those engineers to work together”

He then nodded towards the “big” problem when he said this:

“It’s hard to get those engineers to work together even when they’re in the same company – ask IBM, they know.”

We choked on our collective coffee at this; because IBM does actually know really quite well how challenging it is to get engineers from different groups to work together, because IBM has been doing it for half a century.

In short, Oracle claims that everything will be better in Oracle stack-land because all of the release dates can be synchronised, and integration can be “engineered in ahead of time”. Well, we wish them the best of luck with that; but, saying “we know it’s hard” and even “believing” that it’s hard are a long way from experiencing the challenges associated with coordinating so many different technology life-cycles. All joking aside, as Oracle discovers that this kind of integration really is very hard to do, the company might be well advised to go and ask IBM.

The final point on the ‘total stack’ approach is that some parts of it simply aren’t core to ‘engineering in integration’ – like storage. There’s a reason IBM backed away from manufacturing hard disk drives – If IBM felt that retaining its manufacturing capability would have given it a competitive edge it would have done so. Instead the company sold it, and created a very close partnership with the company that bought it (Hitachi).

There are two killer reasons why the “single stack” pitch fails: Innovation, and Focus
The single stack pitch fails for two key reasons – It doesn’t mean that you can innovate more quickly, and a “focus” on a dozen things nets out as no focus at all.

Innovation first. Oracle is promising to invest $4.3 billion on R&D in 2011 to cover the apps business, middleware, servers, processor design, storage, workstations, and network equipment. By comparison, IBM spent $5.8billion on R&D in 2009, on middleware, servers, processor design, and storage. In other words, IBM is spending $1.5bn more, on fewer things. Oracle won’t be able to invest as much in server design, processor design or middleware development as IBM, either from an overall budget, or a return on investment point of view. IBM’s R&D is already bolstered by partnerships with vendors like Hitachi (hard disks and semiconductors) and Sony (processors) which exist because they deliver far more innovation than IBM (or Hitachi or Sony) could deliver alone.

The further point is that coordinating development to ‘engineer integration in’ means that the whole will generally advance at the speed of the slowest, which will by definition slow innovation down.

Second, the question of focus. Oracle’s acquisition strategy prior to the Sun purchase was absolutely focussed on augmenting Oracle’s already successful applications and middleware businesses. The justification and value creation arguments were clear, and more importantly were focussed on something that Oracle was already very good at. The addition of Sun with its mixture of businesses (and particularly hardware) creates too many areas for Oracle’s senior management to think about – which argues against the ability to focus at all.

Ultimately Oracle’s hardware strategy is simply not convincing enough
While we’re prepared to believe that Oracle will do a better job than Sun did of making their businesses more commercially focussed (although that’s not saying much), we think that at best Oracle will buy a temporary reprieve for the hardware business, rather than preventing a decline that we see as inevitable.

There’s a real danger that Oracle will come to discover, between 12 and 18 months from now, precisely why IBM’s strategy was to walk away from certain elements of the hardware stack and, indeed, why IBM chose not to acquire Sun when it had its chance. In the meantime, IBM (and HP for that matter) will continue to provide a warm welcome to those clients who decide that while the Sun platform isn’t yet “burning”, there’s a distinct whiff of smoke in the air, and they’d rather be on a platform with a clearer more secure future.

One particularly interesting point is that Oracle stated that it’s not all that interested in the X86 market, which implies a level of confidence in Sun’s proprietary processors that the market doesn’t share. Sun cannot ship the volume that is necessary to maintain a viable processor family. A focus on “high value, differentiated products” can easily turn into “unprofitable but expensive niche” unless Oracle can find a way to bankroll the ongoing development of the Sun processor technology similar to the one that IBM found in its deals with the games console suppliers. IBM has shipped tens of millions of processors for games consoles, all of which form part of, and help to fund, the Power family of processors.

Oracle’s software strategy is much more coherent but Sun brings a mixed bag
While Java is the big prize, there are some niche technologies (the identity management technology for example) that add value to Oracle’s software portfolio. Much of Sun’s Java middleware is to be positioned as the reference implementation (which much of it originally was).

Given Oracle’s stewardship of InnoDB we think Oracle will most likely provide a good home for MySQL. But we’re not convinced that technologies like NetBeans are going to enjoy much attention as time goes on.

The absence of a services story is the elephant in the room
For a while now we’ve been characterising this decade as the decade when the power shifts from software to services. In simple terms the 1970’s and 80’s were the decades of hardware, the 90’s and the 00’s the decades of software and we’re now into an era where services holds sway.

It’s a simplistic characterisation of an industry that’s too complex to be defined in such a pat way, but it was interesting to hear the word “solutions” used over and over again by Oracle – as so many others have for the past 20 years – just as vendors like IBM are beginning to talk about “business outcomes”.

Yes, Oracle will be able to find customers that want to buy hardware, and even “solutions”, but the real money, particularly in the high end of the market, increasingly lies in the ability to help customers deliver business outcomes.

This is why, even before Oracle started talking about a return to the 60’s, we felt that the acquisition of a hardware company was basically a retrograde step, and that Oracle’s long term success would have been better served if the company had bought a services organisation. Of course, there’s still plenty of time for Oracle to do that. Watch this space.