lustratus LiteBytes

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

Lots of companies have spotted something they like in SOA, but the next problem is, how to get approval for SOA investment.

This is a real problem – SOA has many different appeals, but apart from the reasonably concrete promise of cost reduction through code reuse and removal of rednundancy, most are somewhat intangible. Worse still, the benefits may be difficult to prove and will take time to accrue. And on top of this, it may be hard to establish a clear link between SOA and major business initiatives to get the necessary priority on the investment.

Somehow, over the years, the old “it’s the right thing to do, boss – honest!” approach seems to have lost its effectiveness. Tiresome CIOs and CFOs seem to want to see actual results – this year…..darn them!

So, IT staff are becoming quite smart about the tricks to get SOA in. This blog entry covers one of them – the viral approach.

Viral SOA sounds like something nasty that you might catch if you don’t wash your hands. But in a way, the idea is to let the company ‘catch’ SOA without really being aware of it. So, to get the pieces of the SOA Ecosystem in place, companies will slip different components into funded projects. For example, if messaging is not in place, a JMS could be introduced as part of a CRM project, to facilitate communications between regional sales offices and the corporate system. When new application components are needed, these could be written as web services, and perhaps an ESB could be brought in as a way to link them up at some nodes. A repository that is used to hold configuration information could be extended to start holding metadata related tot he various components.

Once the ecosystem is more or less in place, as new projects are developed the functionality can be built into hopefully reusable services – in essence slipping in SOA services in on a one-by-one basis. This is where (with luck) the virus really starts to multiply, until it is a fully fledged SOA strategy. The idea is to start showing proof-points for the SOA concept in isolated cases where some of the viral SOA implementation is starting to make new projects quicker, reduce maintenance costs etc. Also, the viral approach has now reduced the entry barrier to SOA by sneaking in a number of the licensed components and necessary skills.

Of course, this is not the only way of getting SOA in – more later…

Steve

Steve’s spotted the announcement of Interop Vendor Alliance…

…(also covered here)– which appears to be about interoperability the Microsoft way: how to get your software to work better with Microsoft’s. And to be fair most large vendors think like this anyway – just most wouldn’t have the nerve to say it so publically.

So what is this really about? If you look at the web-site right now, you will see a lot of case studies and solution descriptions about using Active Directory to manage non-Windows assets from Linux to Mac to Oracle to DB2. All of which sounds rather like a variation on the familiar Microsoft embrace, extend and extinguish strategy (as outlined in the US Department of Justice report on the browser wars). So, is the strategy to embrace interoperability in order to extend Microsoft’s dominant position on their own platform into providing higher level services that span both Microsoft and other platforms? Dominance in a higher level service then enhances the value of using the complete stack as the service will no doubt work best on the Microsoft platform.

Of course given the vaguest of mission statements and the newness of the alliance, it really is too early to make a judgement. What would I like to see? To be honest, I am not sure I see any need for this alliance – except as a website which focuses on all the various standards related activities Microsoft is already engaged in to improve interoperability.

Furthermore, its very existence reinforces the perception that Microsoft stills sees the world as binary: Microsoft and not-Microsoft. This is, of course, an attitude which fundamentally works against smooth interoperability. It is only when Microsoft accepts the reality that it is only a major player in a heterogeneous world will that attitude disappear and interoperability issues hopefully dissipate at the same time.

Ronan

As Steve noted in his last…

…post, ESB vendor Fiorano has just announced a component gallery. I should start by saying that I do find the notion of a marketplace for components attractive and as a concept it has been around for a long time. However, it has never taken off in any previous guise for any but the most technical components.

In the first instance, I think that the blocker is related to the generic SOA reuse issue that has been discussed here and elsewhere: Even within an organization you need to marshal all your technology and organizational resources to achieve reasonable reuse levels. When you try to create a business level component for reuse outside of the organization the problems are much greater again.

The second reason is around the business model: it is hard to make money selling enterprise-style components for $4k off the web. There simply isn’t the volume to support the necessary development and marketing spend. Clearly in the case of Fiorano, this is leveraging an existing business model and therefore may generate some attractive incremental revenue – which brings me to my third point.

Steve already commented on the very technical nature of the components listed. I would go further and wonder why these components are not already in the Fiorano box. Paying $4,000 for something as basic as allowing a single CPU machine (and since just about any machine you will use will be at least 2 CPU this is actually $8,000) to receive HTTP requests seems very high if I am already paying for what is clearly now a basic base product.

And finally, as was previously pointed out on this blog in connection with IONA’s claim to an extensible ESB, this ‘only buy what you want’ approach to introduces a level of complexity around what the product does way beyond the normal comfort level of purchasing managers. Unfortunately to some, it could appear that this approach is primarily about making the base price look attractive and then loading on the extras to solve any real business problem.

Ronan

I was reading about the new…

…Micro Focus Server for SOA, and I wonder if Micro Focus has missed the point? The company seems to target this product as the route to bringing COBOL legacy applications into a SOA environment. Indeed, I quote,

With Micro Focus Server for SOA, COBOL applications can be deployed as web services without requiring the purchase of any third-party software

Micro Focus seems to think that all that is required for SOA purposes is the ability to turn COBOL applications into web services. I guess this reflects the fact that the Micro Focus viewpoint is from the language side – therefore, the major challenge is to provide a container for the COBOL applications to execute in, with a standard, web services interface. But SOA is so much more than just a connectivity mechanism. A key issue with legacy integration, as I have discussed previously in this blog, is the ability to create the RIGHT SOA services – not turn any COBOL application into a web service. Orchestration is a must – otherwise the SOA will become quickly swamped by vast numbers of individual COBOL web services, causing performance and throughput to suffer and producing an unmanageable mess.

Micro Focus may be providing another way to address part of the legacy integration problem in an SOA, but what users need is a way to address all the SOA issues, preferably in one tool. So, the answer in my opinion is Yes – Micro Focus Server for SOA has indeed missed the point.

Steve

IONA has just announced its new release of Artix, the extensible ESB,…

…here. IONA always pushes this concept of extensibility as a good thing, but I am not so sure. Specifically, IONA says Artix is extensible because it is modular, and goes on to explain that this means there is a base cost and then functional plug-ins that can be purchased when and where they are needed.

Now, this has immediate appeal, I can see. There is something comforting about only paying for what you need, and only on the systems where this function is required. But IONA seems to have placed quite a lot of functionality in this ‘priced add-on’ category such as protocol bindings, security functions, reliability and scalability features and so on. The danger, it seems to me, is that as your functional needs grow across an ever-widening network of ESB nodes, the price may climb sharply, with the customer suddenly facing a much higher bill than originally thought.

So there are definitely pros and cons of this approach – but perhaps the con that worries me the most relates to the purchase approval procedures that seem to be usual today. Every purchase has to be justified and approved. In the ‘one package’ approach, this requires a potentially tough justification up front, based on buying a package of function, some of which may not actually be used at first. In a way, the modular approach should mean this is easier, because you are only asking for funding to pay for a function that is actually needed. But in practice, having to go through the approval cycle for each functional increase could well turn out to be prohibitive in terms of elapsed time and danger to sanity. At least with the other approach, all the pain is dealt with in one go.

I guess the jury is still out.

Steve

I spotted a recent announcement from Microsoft around its Enterprise Service Bus plans…

…here and here. For some reason, it doesn’t seem to be getting a lot of coverage, unlike IBM’s and BEA’s recent SOA announcements.

What I found striking was how Microsoft, unlike some of the other major players, seems to understand that SOA requires a different view not only of architecture but also about middleware. In particular, the “one stack to rule them all” doesn’t hold water. There will almost always be a need to implement your SOA across multiple infrastructures. This has been a long term view of mine: I can see little benefit for customers from replacement of deployed queuing systems, BI systems or anything else that works just to get the benefits of a single vendor/stack solution when there is no reason the ESB can’t sit along side these.

Microsoft clearly get this point as they announced with their partner, Neudesic, are packaging recommendations to assist ISVs in building ESBs which do of course incorporate Microsoft technologies (BizTalk, etc) but also as the CTO of Neudesic, Kevin points out:

The key here is that ESBs and SOAs won’t work unless the services span vendor wares and technologies

And then goes on to refer to using IBM’s WebSphere-MQ as part of a solution.

We will of course have to wait to see whether this openness lasts when they have completed the product roadmap and have their own complete solution!

Ronan