So Oracle got Sun – but why?

I guess I am missing something. Maybe I’m just dumb. But I don’t understand why Oracle bought Sun – unless it was just so Larry could stick two fingers up to IBM.

Am I the only one? The Oracle marketing material has a number of claims as to why the purchase makes sense. In an open letter, the Oracle President points out that

Oracle can now ensure continued innovation and investment in Java technology for the benefit of customers and the Java community.

Hmmmm. As long as SUN was bought by someone, eg IBM, this would have happened anyway. All Oracle has done is take on the cost of doing this for the good of the industry. It couldn’t turn Java into a more proprietary platform because that would destroy the brand. So that doesn’t explain it.

And again,

Oracle plans to engineer and deliver an integrated system—applications to disk—where all the pieces fit and work together

OK – so Oracle plans to sell Solaris boxes with Oracle DB and middleware software preloaded. Well – yes, but is this going to work? IBM’s figures yesterday confirmed that hardware sales have taken a beating so far this year, with customers looking for more cost effective options. As people look at virtualization, or using a cloud, is the outlook for server sales that convincing? And if Oracle sees this as a crafty way to get Oracle DB licenses into new customer sites, this is a real stretch – one of the hardest things customers ever do is decide to migrate between DB suppliers. Admittedly, SUN Solaris is the most popular operating system for Oracle databases, so there may be some new sales to be made making things better integrated for Oracle/Sun clients, but I can’t believe this is too extensive.

But perhaps this points to the real reason for the acquisition. SUN was losing money hand over fist, and could have been in danger of running out of steam….and while any purchaser would look after Java, they might not be so friendly towards Solaris. To reiterate the position, in Oracle’s own words in its open letter

The Sun Solaris operating system is the leading platform for the Oracle database

Was the real reason that Oracle couldn’t risk Solaris losing its vitality, or even worse falling into enemy hands? Was this, in fact, a purely defensive move, forced on Oracle by IBM’s stated interest in SUN? This seems the most likely reasoning to me.


IBM 1Q09 results implications

When I posted last week on looking ahead to the IBM first quarter results, I put my head on the block by stating that I felt the results would hold up pretty well.

The formal results were announced yesterday, and I am pleased to say I live to look into my crystal ball another day, at least when discounting the effects of swinging currency markets.

Firstly, I had suggested that the IBM services arm would probably benefit from users wanting to cut costs and looking for help to do it. In fact, IBM claims that overall signings were up 10% at constant currency, and up 27% in the larger projects category. This bodes well for future revenue recognition as these projects flow through. I had also pointed to the desire for quick hit benefitsdriving the IBM WebSphere-based SOA offerings such as BPM, and indeed while overall IBM software was down 6% (up 2% at constant currency), WebSphere revenues grew 5% (14% at constant currency). My forecast was that hardware would take a bit of a hit, but that this shouldn;t damage the overall numbers too much. Once again this seems to be borne out in the IBM announcements, pointing to a 23% drop (18% at constant currency) of its Systems and Technology segment where the hardware products live. However, overall this had little adverse impact on IBM’s overall figures as predicted because IBM has swung its business model much more heavily in favour of software and services now.

Looking ahead, these results can only be good news for IBM, even though revenue at common currency was down 4%. From a global market perspective this should also prove encouraging to other IT vendors, particularly those with investments in the high-growth enterprise middleware area and those providing advisory professional services. However, companies reliant on hardware revenues will probably suffer most.

The final interesting point was that IBM claims it is sitting on $12B cash in hand….I wonder what it plans to do with all that money at a time when assets are cheap and it has just missed out on SUN….


Looking ahead to IBM 1Q09 results

IT market watchers are eagerly awaiting IBM’s 1Q09 results, to be announced in the next few days, anxious to see how IBM is finding the current global market conditions.

Putting my own neck on the block, I suspect the results will look pretty good despite the economic downturn. There are a number of reasons for this.

Firstly, Lustratus is seeing a lot of users looking for professional services assistance in reducing IT costs and increasing flexibility and agility. This is pretty natural in a downturn. Doing more with less is obvious, but also companies are looking to expand their customer bases into new markets with new offerings as quickly as possible to shore revenues up, driving the need for better agility and adaptability. This plays into IBM’s hands with its extensive services experience, so services revenue could well hold up OK.

Secondly, one thing users ARE looking for at the moment seems to be quick hits – do something that isn’t too costly and is not a major architectural shift to get a fast return. As I have blogged about before, BPM (Business Process Management) and Business Events processing offer two areas that fit beautifully with this need – and note this is not the BPM where a company sets about rewriting all its processes, but instead BPM targeted on fast return, pragmatic sweet spots. Both BPM and Events will tend to drag in SOA requirements (although again at the pragmatic rather than ‘change the world’ level) which is another strong area for IBM. Although other companies such as Oracle and SAP offer technology in these areas, the advantage of being able to link the products to services engagements from IBM’s massive services arm to help aim the investment most effectively is a big one for IBM. Given that IBM also has a large portion of software revenue on ‘contract’ basis, this means the software revenues should hold up well too.

Hardware may have taken a bit of a ding in 1Q09, but this is unlikely to do too much damage to the overall numbers.

So, a reasonable set of results to come from IBM? We shall see…..


Ultramatics works with IBM to defuse SOA security threat

Ultramatics has just announced SOA SafeGuard product, which is designed to shut one of the major SOA security holes – the opportunity to inject virus and other malware threats through XML file sharing.

This is good news for SOA implementers, but also introduces an interesting new stress point for IBM. Back in 2007 I was on a podcast where I identified the five SOA security traps, one of which was the XML problem. To summarize, most virus and other threat detection solutions look at the datastreams coming into the system and identify threat signatures that indicate the presence of some noxious code, but unfortunately they cannot see inside the XML wrapper, so to all intents and purposes the contents of any attached XML file are invisible. This offers the opportunity for malicious agencies to pop in some nasty code into the XML content and smuggle it through the security gates to the enterprise. Of course, it is not immediately obvious how this would help, in that getting this code executed might not be so easy, but hackers are smart….therefore it is best to close this exposure.

One way to close the window is simply to forbid any XML file sharing, but since industries such as healthcare now more or less rely on this to conform to industry standards and regulations, this is not really practical. The new Ultramatics product claims to be able to protect from these types of intruders. It runs on the IBM DataPower XI50 Integration Appliance, providing a hardware-based shield that can see into the XML files and weed out anything unpleasant. This solution will be very valuable to many SOA companies worried about security.

But there is something else interesting in the product details. The datasheet for the product says it can be used (in conjunction with IBM’s MQSeries) to:

Create a SOA ESB that can perform routing, transformation and protocol mediation functions

This is intriguing. Of course, the idea of an ESB appliance is not new, but the interesting point is that IBM is supplying this capability through the Ultramatics product…..I wonder if the other IBM ESBs, WebSphere ESB and WebSphere Message Broker, see this is encroachment?


A practical approach to Open Source (part 4)

So far, these posts have covered user benefits of OSS, risks and the need to understand the various different OSS business models.

This final post in the series looks at tips for getting benefit from OSS implementations.

The first point to remember is that even though OSS software is ‘free’. its adoption needs to be planned carefully. This is even true forthe lowest risk area of personal productivity tools, surprisingly. Most people think this is the easiest OSS area, and are happy to let OpenOffice or Firefox or any of the multiplicity of user tools be loaded….but this can lead to trouble. Remember that one characteristic of OSS is that because it is free, there is no need for a user to gain purchasing approval, and hence adoption can be uncontrolled. If it then turns out that the new software introduces an incompatibility with other systems, this can be a nightmare. Make sure that adoption is controlled and that every employee is aware that OSS software purchasing should go through the same governance procedures as commercial software, even if it doesn;t cost anything.

This leads to the next point. In fact, OSS software is never free. The LICENSE may be free, but there are users to train, developers to educate, support to be arranged, risks to be evaluated and countless other tasks. Indeed, at the OSS infrastructure level as opposed to end-user productivity tools area, most OSS offerings are of the ‘framework’ type where the user is left having to do extensive development and customization before the software can be used productively. So, to succeed with OSS it is necessary to evaluate the business case taking all these resource and service requirements into account, even if license costs are 0.

The next tip is think ahead. Ask yourself why the software is free. Is it because the software community, out of the goodness of its heart (!), wants to share its bounties with everyone for free, or is there some other game plan at work? A number of OSS projects have come about from users wanting to find a way to defray their costs of supporting their home-developed code base. Projects such as AMQP and Swordfish srping to mind. The issue here is that if the particular project never really gets popular acceptance, then  future updates are at risk of dying off if the original authoring company changes direction. Other OSS projects are offered by vendors having a ‘full-function’, priced version of the software. Remember IONA’s Artix / Celtix ESBs? Artix was the commercial product, and Celtix the OSS version. Every time IONA added new function, it tended to put it in the commercial one first, and only backfitted it to the OSS version if it didn’t get wide acceptance. So, be aware that if you go with an OSS project you may have to take a commercial license in the future.

Watch out for projects that claim massive acceptance but which in truth are only supported and used by a small minority. A typical trick to watch for is claims of ‘Millions of donwloads’. This is really weak – remember that if something is free to download, every student in the world is likely to download it at least to play with. Only a timy fraction of these downloads would even move to a point of trying to actually use it.

The best tip of all is to wait for clear signs that a particular OSS project has gone mainstream. So, Mozilla Firefox is so well-known as a browser, with so many users, that it is a reasonably safe bet. LINUX has huge industry support, and rich backers such as IBM. There is no way it would ever be allowed to fall behind in the technology stakes, and because of its wide acceptance there are hundreds of companies in the LINUX ecosystem now offering support, services, training and other OSS LINUX add-ons. However, If you really want to be a trailblazer, then go ahead with unproven projects…but just go in with eyes wide open.


A practical approach to Open Source (part 3)

The third post in this short series looks at the need to understand the business model surrounding the OSS offering being considered.

One of the defining qualities of OSS is that, at least at a basic level, the produt can be licensed at no charge. This immediately raises the question of how sustainable the model surrounding theOSS project is. The fundamental question is, who is going to keep the code base up to date? Who will apply fixes, develop new function, offer support, provide documentation, etc?

There are a number of different types of OSS project, and each has different business model implications that affect its likely success and future longevity. At its heart, the OSS movement really got under way based on an ‘anti-commercial’ theme, where programmers wanted to share their skills and use software that was developed ny them, for them. This is fine as far as it goes, but as people’s interests change, the exposure is that these developers will move on to something new and the original OSS project will wither away. In the rare situations where th problem is overcome, there is usually a viral element to the project’s success, like in the case of Firefox for example.

The next model is where a commercial company is set up around the OSS project. Usually, these companies sell services around the OSS project such as documentation and training, as well as offering commercial licenses to cover support, or verified and tested versions of the OSS code base. The success of this approach will depend on whether the OSS users are prepared to cross the ‘free software’ line and accept that there will still be costs incurred. A big problem here, however, is how extensive the support offered is. The worst threat is that OSS projects often use other OSS offerings to fill out capabilities, and therefore either the commercial support organization has to become expert in all these code bases, or there will be gaps in the support.

The most devious OSS model is where a vendor sponsors an OSS project for its own advantages, regardless of the implications on the user. Typically, a vendor might take a base level of code and make it an OSS project ‘for the good of the community’, but instead of this project attracting other development partners it remains drive by the single vendor. Now, that vendor typically produces an ‘authentic’ version of the project which DOES have a license cost and maintenance fee. The idea is to get users on board thinking the product is free, and then hook them with the professional versions.

Finally, the best OSS model of all from a user point of view is where a number of large vendors decide it is in their interests to back a particular OSS project. This is the case with LINUX, for example, where vendors such as IBM have put in millions of dollars of investment. As a result, a whole ecosystem of LINUX-oriented companies have sprung up, and all of this ensures that LINUX users can have a degree of confidence in its future.


A practical approach to Open Source (part 2)

Following my first post in this short series, in which I looked at the benefits of going with an open source project, this post focuses on the risks that counterbalance those benefits.

The main risks for users to consider fall into four areas:

  1. Support
  2. Longevity
  3. Governance and control
  4. The 80/20 rule

The first is perhaps the most obvious risk of OSS. The principle behind OSS is that the code is developed by a team of interested parties, and support is often initially offered in the same light. So, problem resolution is based upon someone else giving time and effort to work out what is wrong and fixing it. Similarly with documentation, education etc – they all depend on someone else’s good will. Some proponents of OSS will point to the fact that commercial companies have sprung up that provide fee-based support for various different projects, but this has a number of big drawbacks. One is that this is fee-based and therefore impacts one of the open source advantages (free licenses), and the other is down to the nature of most OSS projects. OSS developers usually operate on a shared code mentality, and frequently use many other OSS components in their own solutions. While one of these groups might form a company to offer support contracts for the code they have developed, they usually have to rely on ‘best can do’ support for the other components they have embedded. All of this brings in a great deal of risk attached to using OSS. The one difference is where a company has decided it wants the OSS specifically because it gets the source and can now staff its own maintenance and support team.

Longevity relates to the support question. OSS projects need their driving teams of developers, and if for some reason these people decide to move onto something more exciting or interesting, the user could be left using a code-base that has noone left who is interested in it. This means future upgrades are extremely unlikely, and leaves the user stranded. A special case to watch out for here is those crafty vendors who start an Open Source project around some new area they are interested in, supplying a very basic code base, and then when enough users have bitten on the bait they announce that future development is going to be supplied int he shape of a traditional licenses software offering, while the original code base remains at a basic level.

The governance / control risk is a tricky one. The problem is that be definition anyone interested in a particular OSS project can download and use the code. A company might decide to use OSS for specific needs, only to discover that it has proliferated without control due to the ease with which people can download it. These downloaders may think they base is supported because the company has decided to use it in other places, but they may have downloaded different versions or anything. Related to this is the control of quality – as other OSS users develop updates, these are supplied back into the OSS project, but who if anyone is policing these changes to make sure they do not alter functionality or remain compatible?

The final risk area relates to the nature of people. The driving force behind any OSS project, at least in the early days, tends to be a fanatical group of developers who really enjoy making something work. However, anyone familiar with software development will be aware of the 80/20 rule – that 80% of the code takes 20% of the effort to write, and vice versa. The natural inclination for any OSS team is to do all the fun stuff (the 80%), but to tend to shy away from the really heavy-duty complicated stuff. So, areas such as high availability, fault tolerance, maintainability and documentation are the sorts of areas that may suffer, at least until the project gains some heavyweight backers. This can severely limit the attraction of open source software for commercial, mission-critical needs at least.

It is for many of the reasons given above that the area of greatest attraction for new OSS projects tends to be in the personal productivity area, where there are alternatives to mitigate the risks. So, Firefox is great, and has super usability features because it has been created more or less by users, but if something went sour with a latest level of the code the users could switch to IE without too much pain. Deciding to use OSS in a production, mission-critical environment is much more dangerous, and generally only acceptable when there is a cadre of heavyweight underwriters, such as in the case of LINUX. In this case, IBM would never let anything go wrong with LINUX because it is too reliant on its continued success.

Part 3 will look at this area more closely as it discusses the OSS project business model.


A practical approach to Open Source (part 1)

I am often asked about OSS (Open Source Software) – I am not sure whether it is because I have been somewhat outspoken in the past…

…or whether it is because users are not completely sure whether they can trust the marketing messages put forward by different OSS projects and their supporters and are looking for an independent perspective. However, I have decided to jot down a few thoughts around OSS, based on a practical and logical assessment. I have gathered these observations into four areas

  • What are the user benefits of open source?
  • What are the risks?
  • How does the particular open source project business model work?
  • What needs to be done to achieve the benefits?

This first post deals with the first area – what are the user benefits of open source?

I guess the most common one users bring up is that OSS is free! No license fees has got to be good, hasn’t it? Just one work of warning here – it is worth checking the exact terms for the specific OSS software to validate that it really IS free. Strange as it may sound, some ‘OSS software’ is NOT free of charge.

However, there are other potential benefits to consider. For example, some users find that having access to the source code is a benefit. This may be because the user can now make changes to customize the software so it is more effective for the company, or the confidence it brings that a failure can be resolved locally without having to wait for support organizations to respond. Once again, however, check the small print. Some OSS Software projects do NOT distribute the source, and others require any updates and new developments to be fed back into the project.

Another appeal of OSS is the fact that it can pool the ideas of thousands of technical minds across the globe. Hopefully this will mean that the code is usable and effective. Since these minds will also be available to check the code, it should also give a higher code quality. The caveat in this case is to make sure that the particular OSS project of interest really IS a broad community, and not just a small interest group or worse still a single vendor pretending to be pushing a widely supported OSS project.

Finally, there is the hoped for standardizing effect of OSS. That is, if an open source project takes off and gets wide industry backing, then all vendors are likely to find it easier to support because there is no hidden agenda of favouring a particular vendor. This can stimulate a much wider and more rapid acceptance of the particular code-based, resulting in it becoming at least a de facto standard if not one supported directly by standards bodies.

More to come – the next post will be about the risks of open source….


Vendors like to back standards – as long is it is in their interests!

I was reading Danny Goodall’s post on his strategic marketing blog about standards-based marketing…

….and it brilliantly illustrated a point that I think is often experienced in the software marketplace – some vendors rush to back standards and push them, but only to the point that they fit with their own goals.

The example Danny discusses is Sonic Software, part of software vendor Progress. Sonic is well known as the first software vendor to use the ESB acronym (Enterprise Service Bus), and did indeed peddle the standards message hard asDanny, the marketing guru behind Sonic’s early success, remembers:

All the while I was creating marketing programs that stressed Sonic’s commitment to standards and, by implication, I was de-positioning other vendors’ technologies as being the Devil’s spawn due to their reliance on proprietary features. “How,” we asked “would organisations ensure interoperability between their, and their trading partners’ infrastructures if they didn’t conform to the emerging standards?

Of course the standards message is very attractive to users. Buyers are keen to be able to ensure that not only can components interoperate without a lot of extra work, but also that vendor lock-in is weakened through the ability to substitute components from different suppliers, bringing prices down and reducing risk. Therefore, vendors that preach standards may come across initially as ‘good guys’. However, it pays to look more closely to find out how serious the vendor REALLY is about standards. In the Sonic case, while it talked a great story, the mystery was that its own ESB product was unable to run over any standard JMS-based messaging pipe for years. Instead, it used a proprietary interface that ensured Sonic ESB would only work over SonicMQ, the Sonic messaging pipe. This was a real problem for many prospects, because IBM’s WebSphereMQowns around 80% of the messaging pipe business and therefore prospects interested in an ESB were frequently looking to run it over their existing software. This restriction was arguably one of the key reasons Sonic lost its leadership position in the ESB market.

So why did Sonic take this line? Obviously, only Sonic knows, but a cynic would argue that it consistently refused to support the JMS standard in the early years to ensure that it could force the sale of its own messaging pipe. No matter that this meant the user often had to buy another one on top of the incumbent solution.

I am not picking on Sonic here – this is only one of many examples where vendors claim to be standards-based while not shrinking from proprietary solutions when in their own interests. And of course, it is entirely understandable – after all, software vendors are businesses too. To me, the important thing is that users keep away from the rose-colored spectacles. Standards are valuable, and vendors do provide important support, but there will always be compromises.


What software buyers are looking for in 2009

With the global downturn in full swing, there are a lot of concerns over how software markets will perfom.

However, one trend is emerging as a vital ingredient if software companies are to succeed, and those companies that have recognized it are already benefiting.

Software buyers in 2009 are finding an industry vertical specialization to be essential to support any investment justification. The problem for many users is that although the technologies and products available offer the same sorts of benefits as before, in order to get any purchase through the system it has become critical to have a strong business backing all the way. Nothing will move if a business sponsor is not pushing for it. Of course, investments have always had to be justified, and a business alignment is a key part of this process, but in the economic downturn this focus has moved from being part of the justification to being the overriding element. A business sponsor has to be brought on board right at the beginning if the particular project has any chance of success.

As a result, companies that do more than pay lip-service to describing business benefits are prospering. The software vendors that offer truly vertical solutions, tuned for particular industry needs and taken to market by field teams with the relevant industry domain knowledge, are the ones that are succeeding. One proof point is Pegasystems, who I blogged about a few days ago. Onereason that Pegasystems has maintained such strong growth in 2008 with its BPM offerings is a strong industry vertical sensitivity. 

Another excellent example is IBM and in particular its Information Management division. Information Management software is regarded as unsexy – although still important, it has tended to be neglected in the rush towards application-oriented strategies and initiatives. Enter a new IBM management team that has restructured the go-to-market approach for Information Management software to an industry-vertical one, generating models of particular industry challenges and processes, looking at the specific needs of these industries and carrying the industry-vertical business messages to prospective buyers. Whether serendipitous or the result of impressiveexecutive insight, this approach has almost exactly dovetailed with the software buyers’ needs for a more relevant, industry-related message in order to secure investment. The result is that IBM is claiming significant sales and successes in its information management software business segment, even in the current environment. 

Other software companies would do well to take note. If you want to sell software this year, you have to help your prospective buyers by going to market with clearly aligned business vertical offerings and messages.