Lustratus LiteBytes

Archive for the ‘Uncategorized’ Category

Over the past two years, a little Canadian company called Teilhard has been suing IBM, Microsoft, SAP and many others over a data exchange patent it acquired from JuxtaComm, but all parties have now settled.

I have occasionally blogged in the past on this case, regarding a patent from a company called JuxtaComm (now owned by Teilhard which is in turn owned by Shopplex.com) on a ‘System for transforming and exchanging data between distributed heterogeneous computer systems’ (US patent number 6,195,662). Legal activities were leading up to a November 2009 trial date. Many people have contacted me recently to try to find the current status, since there is little information available in the public domain and what is available in the blogosphere seems terribly polarized one way or the other. In answer to these frequent contacts, I thought I would post an update.

Firstly, the trial is off. All parties reached mutually acceptable settlement agreements, and these agreements included protection for all parties from future legal action. It should be noted that no information has been released by any party yet on the terms of these settlements. Settlements are exactly what they say – the dispute has been settled between the parties, for good. The only other point to note is that settlement amounts reflect the confidence and risk for each party in continuing to trial – therefore settlements can be large or they can be small or even zero. It all depends how strong each party thought its case was, and how much each was prepared to risk in terms of legal costs and potentially unexpected trial outcomes.

Secondly, as part of the pre-trial legal process, the judge involved formalized definitions for the terms involved in the patent, for example ‘script’. By choosing unusually wide-reaching interpretations for these terms which programmers would find highly eccentric, the result was that the patent applicability was increased dramatically from what it had originally covered, that is ETL (extract/transform/load). In the ‘script’ example, for instance, while the defence argued that a script was “a series of text commands’ that were interpretively run sequentially by the script processor”, the judge decided that a script meant “a group of commands”! However, the reason this is important is that subsequent to these definition rulings, the US patent office is now re-examining the patent for validity based on the new definitions. This work should be finished in the new year, and will have a bearing on future legal actions against new perceived infringers.

The big question to some, particularly those who own shares in the private Canadian company owning the patent now,  is how big or small the settlements are. As I said, this will be determined by a combination of risk, confidence and desire to avoid burning legal costs unnecessarily. On the plus side for the patent holder, the judge’s definitions strengthened the case substantially, making it far more wide reaching and therefore widening the impact on potential infingers. On the negative side there were an awful lot of examples of software that seemed to do the same thing as the patent describes which predated the patent, although in legal terms this sort of prior art does not necessarily invalidate the patent or law suits, apparently. But in the end, the truth is no-one knows whether settlements were huge or miniscule.

The only trustworthy sources for this settlement information in my view would be any formal announcements from any of the parties involved. For example, if a company has had to make a large payment for settlement, then depending on how much this payment is as a percentage of its turnover it might be legally required to make a statement about it in its SEC filings. Similarly, if the patent holder announces any substantial dividends then that would be another indication of settlement sizes, since the patent-holder makes very little revenue in software sales and therefore any significant profit would have to have come from patent settlements. Perhaps the next six months or so will make things a little clearer, but don’t hold your breath; as a private company, the only people Shopplex.com is required to keep informed is its own shareholders – it is not required to make any statements at all to the wider public.

Steve

I was recently doing some research into the latest state of play in the Enterprise Service Bus (ESB) market, and decided to take a look at Microsoft’s ESB – or rather its pretend ESB.

I had never been sure about Microsoft and SOA- it tends to focus instead on BizTalk and the Microsoft world. However, recently I have heard a lot of encouraging noises from Microsoft about its belief in SOA, and how it sees BizTalk as a key component in an SOA architecture for application design and deployment. But I must admit I had not realized that Mircosoft gave any credence to the ESB concept.

With an element of hope I delved into Microsoft’s ESB stuff – only to be disappointed to discover it is not an ESB product at all, but ’ESB Guidance’, a collection of samples, templates and artifacts to deliver ESB functionality. In essence, Microsoft does not yet acknowledge the existence of the ESB class of product, preferring instead to take the old IBM line of a few years back pretending that an ESB is a style of implementation rather than a product. However, I thought, this doesn’t really matter as long as Microsoft offers ESB functionality, however it packages it.

But then sad reality dawned. Microsoft ESB Guidance is not even supported. It is a collection of samples and pieces offered on an ASIS basis, take it or leave it. Use it if you like, but don’t come to us with any issues or problems. How disappointing. See the Microsoft Guidance notes -

The Microsoft ESB Guidance for BizTalk Server R2 is a guidance offering, designed to be reused, customized, and extended. It is not a Microsoft product. Code-based guidance is shipped “as is” and without warranties.

So, it looks like Microsoft isn’t really on the ESB bandwagon yet. The new release of BizTalk Server this year may introduce a ‘real’ ESB, but at this point in time Microsoft appears to be paying lip-service to SOA compliance, but not actually doing much about it.

Steve

Could 2009 finally be the year BPM comes into its own? My own opinion is – YES!

This may seem a bit odd – after all, in previous years I have been a bit hesitant about BPM adoption, finding instead that many users were working on lower level integration problems first and then ‘backing into’ BPM. On top of this, with all the trading uncertainty around surely no-one will be rushing to BPM?

In fact, Lustratus thinks that the current economic environment is EXACTLY the right time for BPM. My worries in the past have been to do with people trying to move completely over to a BPM model. This requires a heck of a lot of effort, thought, maturity in process engineering and resources, and can take some time to generate a payback although the eventual gains are admittedly great. However, the current economic situation is forcing people to be much more pragmatic, and it is here that BPM really starts to deliver.

Lustratus recently produced a paper discussing the Lustratus BPM Sweet Spots - five potential targeted uses of BPM technology sorted in terms of speed of return, ease of implementation and overall benefit. A number of these sweet spots represent quick ways to improve a particular process, increasing automation and hence providing the opportunity to reduce people costs. It is this improved efficiency and productivity that attracts companies in the current economic downturn – anything that makes use of what is already there but cuts the staffing bill is almost a no-brainer. In addition, the visibility BPM brings with it into process execution is of enormous use when trying to implement responsible risk and compliance management measures, something greatly desired in the current circumstances.

So, 2009 should be the year when companies turn to BPM – but note the distinction of pragmatic, targeted BPM as opposed to grand BPM strategies that will make everything better ’sometime’.

Steve

It’s that time of year again, and Lustratus has just produced its annual predictions for the software infrastructure marketplace.

The Lustratus Insight containing the 2009 predictions is available free of charge here.

As might be expected, the predictions this year are heavily influenced by the current economic downturn and projections that it will continue throughout the year. It may be surprising, therefore, that one of our predictions is that there will be a hiatus in the open source (OSS) marketplace. At first glance, this seems counter-intuitive. After all, if companies are desperate to cut costs, then surely open source products that have no license fees must be an attractive option? Wont this drive OSS demand in 2009?

The Lustratus reading is slightly different. While it may be true that on the face of it having free software would be great in today’s constrained environment, the problems stem from the nature of OSS combined with the likely mandates under which companies are operating at the moment - that is the need to reduce staffing wherever possible.

Most open source software is by its very nature collaborative, and this tends to lead to software that is made available in kit form – that is, although the open source software may offer a framework or the basis for the desired functionality, it is expected that the user will put effort into customizing and extending the functionality for his or her own needs. Typically, therefore, embarking on an open source initiative involves a heavy investment of IT resources, at least at the beginning. Now while this will result in lower license costs, the problem is that in today’s climate companies are shying away from anything that requires anything more than minimal resource investment. Users are looking for products that work out of the box, or more likely are trying to generate more value from what is already in place.

As a result, Lustratus believes that although interest will remain in OSS, new OSS projects will be put on hold until economic conditions relax.

Steve

Five or ten years ago, this sort of question would have been unthinkable, but now mainframe users are increasingly facing a choice between whether to use Linux on System z or z/OS to host new mainframe workloads.

These new workloads may be the result of a consolidation project, or simply taking advantage of flexible architectures like SOA to utilize spare mainframe capacity, but the decision is not an obvious one in either case.

On the one hand, long-time mainframe guys will say that z/OS has grown up with the mainframe and therefore must be the best choice. But IBM has done a lot to its version of Linux for the mainframe, and Linux bigots will be quick to point out that the license costs will be cheaper and there are strong advantages in standardizing on a portable and flexible operating system enterprise-wide. Worst of all, given the polarized nature of IT in general, the decision makers find it hard to get unbiased advice on such a divisive question.

In the end, the answer to the question of whether z/OS or Linux on System z is better is not surprising – “it depends”. This subject is discussed in much more detail in a free Lustratus report, “Choosing the right SOA platform on IBM System z”, available from the Lustratus web store. While this paper focuses particularly on developing or moving SOA workloads onto System z, the analysis applies to any new mainframe workload. Summarizing the arguments in the paper, the major differences that affect the decision are that Linux is designed to offer a common environment across many platforms, and is thus less attuned to individual platform capabilities by definition, and that whereas Linux has been designed for the ’server’ model where it is used to operating one type of workload, z/OS has been built to handle multiple subsystems from the start.

The common environment aspect of Linux offers flexibility, helps to drive license costs down and leverages widely available skills. The multi-system capabilities of z/OS combined with its close linkage to the System z platform offer the greatest exploitation of System z facilities. But as always the devil is in the details.

Steve

I was reminded how easy it is to get marketing completely wrong today when I saw (on UK television) an advertisement for New York Bagels.

Bagels are not as heavily embedded in the UK psyche as in the US, I admit. Brits think of them as something you see people eating on US cop shows and sitcoms, often in New York. So what did the marketing company do? It spent the entire time showing the British market how delicious bagels could be … and then finished with a picture of three packs of New York bagels.

The point here is that the advertising company had missed its mark. Yes, there was a need to educate the British audience, but we know so little about bagels that it seems the advert is for ‘bagels’ as opposed to a particular brand name. When it refers to New York bagels, I and many Brits like me thought that that was the name of the food – like you might say Scottish salmon. My reaction was to pop down to my local store and by ITS OWN brand of bagels – the advert said ‘eat bagels’, not ‘buy New York bagels’. I guess in the US the advertisement or should I say commercial would work OK because the audience would be very familiar with bagels and realize the New York Bagel is a brand name.

So the marketing failed at one of the first hurdles – it had not attuned the message for the target audience.

In the software world, marketing is often extremely poor. I have always thought the main reason is that software companies have often grown around a particular technology, run by technology people, and to these people it is completely obvious why someone should buy its products – because they are technically wonderful! However, the same general marketing principles apply – you must know your target audiences, understand your key value proposition and how you are positioned in the software firmament and what your competition are up to. But a short look at marketing for virtually any software offering will quickly show this is rarely the case!

Lustratus uses its REPAMA Strategic Marketing analysis tools with clients to look at how products are being marketed, and the results can be quite eye-opening…so in order to increase awareness of this topic and further understanding, Lustratus has started a new blog to discuss issues around software marketing and its effectiveness. While this will be of obvious interest to software marketeers, I recommend it to buyers of software too – it is always useful to see how potential suppliers are tuning their messages and what markets they are really interested in.

Steve

Eric Knorr commented in InfoWorld a couple of days ago on Forrester’s latest market adoption estimates for SOA which showed much lower rates of adoption than the same survey suggested a year ago.

In my opinion, the key problem is probably not SOA adoption itself but problems with surveying end-users about hot technology areas.  This is an area that I have recently covered in an insight called Interpreting Market sizings:  It is a serious issue for organisations attempting to figure out what the real market take-up is and when or even if they should follow a particular technology trend.

Coming back to the article, Eric states that:

“SOA sounds great, but boy, is it hard. Especially on a wide scale, because doing it right generally requires rethinking how IT is organized.”

While I have some sympathy with the author’s sentiment, but Eric’s view really relates more to when and whether you decide to go for the wide scale big bang approach as opposed to the more achievable incremental build up.

More importantly, the evidence for this statement is the discrepancy between the 14% of respondents surveyed last year who said that they would implement SOA in 2006 (not including the 39% who already had) and the 2% who actually had a year later.  This is a great example of the “Everybody’s doing it apart from me” effect.  Asking aspirational questions about what we hope to do next year will always give misleading and optimistic answers. It is as true for healthy eating as it is for SOA!  This effect is particularly strong with anything that is generally considered a hot topic (like SOA).  This is of course not to say that the respondents didn’t genuinely think they were going to do a SOA project.  But must-do projects appeared and other projects extended and then the wished-for SOA project was never got to.

What does all of this mean?  It probably does mean that SOA take-up is slower than the more wild claims – no surprise there.  It probably also means that people aren’t doing SOA as fast as they would like to – things always take longer anyway.  However, it almost certainly doesn’t mean that there is a radical slowdown in actual adoption.

Finally… It is good fun to knock this survey and others (such as the one last year which claimed that 90% of companies would have exited 2006 with “SOA planning, design and programming experience” based on a sample of a massive 120 respondents).   However, as I said at the start, the whole area of market surveys is a serious topic as it distorts perceptions both at the start and later on when more general adoption does happen.  All of which means, with surveys – buyer beware!

Ronan

IONA announced today that it had acquired for an unspecified amount of cash…

…C24, a small UK based business focused on data transformation and validation primarily for the financial services sector.

I should upfront admit to being a former employee of IONA, a current IONA shareholder and to know some of the guys at C24. And I should stress that (of course) none of those facts are the reason why I am writing about this news! Rather what it is significant is that it reflects the inevitable and growing focus on data (from modelling to transformation to validation) by SOA vendors which in turns reflects the growing importance of data management in deployed SOAs.

As Peter Zotto, CEO of IONA put it during the conference call about the announcement:

For CIOs, it [SOA] is all about three things: Data, data and data.

This is particularly the case in investment banking where profits are now driven by an ability to handle ever more complex derivatives for the hedge funds. This is the industry that C24 focused on and it is the industry that is driving the interest in data centric protocols (such as FpML), data transformation and validation in the SOA world. On this basis, the acquisition makes sense for IONA in servicing its investment banking customers today.

However in the longer term, the requirement is likely to spread into other industries: As SOA links applications and organisations in new ways, it exposes the big issue of how to map between the multiple data models and formats. And so the capability to ensure that this is done quickly and reliably will become essential for SOA-based infrastructure in any vertical where performance and data complexity occur such as government and telecommunications.

Ronan

Reactivity, a hardware XML gateway vendor,…

…has been snapped up by Cisco for what seems like a seriously large amount of money. Following on from IBM’s acquisition of DataPower in 2005 for a similarly large amount of money, it is clear that a high stakes game is being played here. High stakes because in both cases it would appear that the price paid makes little sense on the basis of the revenue these company’s may have been generating from sales.

The game started in 2005, when Cisco made a lot of noise as it launched Application-Oriented Networking (AON), a strategy to make the network smarter by adding functionality previously associated with middleware vendors. Rather than attempt to go straight into competition with the middleware vendors, Cisco correctly identified the enterprise edge (branch offices) as poorly served by existing middleware products. Hence, Cisco talks a lot about the service-oriented network architecture and focuses on the 40% of enterprises which it points out are branch offices. In line with this focus on the wider enterprise network, AON is very much a network virtualisation play. The underlying concept with AON is that you can easily deploy middleware like capabilities close to where you need it as part of your Cisco-based network infrastructure rather than in central hubs which are potentially far from where the functionality is needed.

All good strategic thinking in terms of Cisco’s strengths and an apparent gap in the market. Except that after an initial burst of interest, the buzz around AON disappeared pretty fast: As is reflected by the very fact that I felt the need to explain all of this because I am almost certain that few of the readers of this blog knew anything about AON. (And when I searched for AON on google, Cisco’s AON didn’t even make the first page.) However, this lack of visibility isn’t just about marketing dollars, it seems clear that commercially AON has simply not done what it hoped to do.

Which brings us back to the Reactivity announcement: Reactivity’s XML firewall and traffic monitoring technology will clearly help bolster (and quite possibly replace) AON’s existing technology.  And given AON’s focus, I don’t see this acquisition as particularly related to the mainstream SOA (or Web2.0) market as some commentators have suggested.

More fundamentally, I really don’t see that it will make much difference to the success of AON commercially in the short to medium term. This is simply because I struggle to see this market growing much for a number of years (5+). The primary reason I see the market so far out is that focusing on branches seems like a good idea, but it is a bit like focusing on the SME market: The reason why both are generally ignored by vendors is because branches like SMEs have less money and less ability to handle new technology: Branches simply don’t get the attention from the centre which has the power to allocate the budget required to buy this stuff and staff necessary to deploy it.

All of which means that if Cisco see this as a long term play in which Reactivity could be a stepping stone, well and good.  However if this is really meant to accelerate AON’s commercial success, expect another acquisition within a year as Cisco try again to reboot AON.

Ronan

The recent revelation of the secret work…

…on AMQP (Advanced Message Queuing Protocol) has got lots of people talking in the integration industry. Basically, the idea is that a bunch of folks such as JPMorgan, IONA and Cisco have got together to work on an open source solution for guaranteed messaging. Currently, the market for multi-platform guaranteed once-only messaging that underpins all of SOA and business integration is owned by IBM, with IBM’s WebSphereMQ owning in excess of 80% of the market according to IDC. The theory is that AMQP will commoditize the market and supplant MQ.

Now, I need to declare my conflict of interest up front – I ran IBM’s MQ business for its first three years int he market, and therefore my independence may be called into question. However, I believe I can take a balanced view, and the fact is that there are some significant problems with this AMQP idea, and I think these are serious enough to be given close consideration by anyone thinking of going this route.

The first, possibly minor, issue is that I personally was confused about the integration model being proposed, and I fear that it may cause companies to have to unpick their architectures. I am no expert. but from what I can read, AMQP is not just a messaging wire as MQ is. It also does other things like content-based routing. This is part of the functionality typically provided by ESBs and the like, along with other mediation functions like transformation. But AMQP doesn’t do transformation, so it seems to suggest a redrafting of architectural diagrams.

The second is that for this to be valuable, it needs to be multi platform. One reason for MQ’s success is that it can connect many different platforms, since it runs on them all. AMQP needs to do the same, and I am sure that technically it may be able to – BUT!

The problem with multi platform support is not how to do it, it is the testing! Someone has to invest in testing the product across all the platforms it supports, and the combinations that can be made up out of the base set. AMQP is open source – so who can afford this sort of investment? Is someone like Iona or Cisco committing this sort of test expenditure on hardware, resources and time? Or is the assumption that the user community will do this ‘on the job’?

Thirdly, guaranteed messaging is almost by definition the backbone of a company’s mission-critical operations. If they weren’t critical, then guaranteed delivery wouldn’t be so important. So, where is the AMQP ‘throat to choke’? Who do you run to when it fails, knocking out your key online systems? And going back to the testing question, who will invest in the huge expenses involved in stress testing and performance tuning to ensure it can meet the demands that will be placed on it?

AMQP is a great idea – but in my view it is doomed before it has got started.

Steve