Message-driven SOA – what goes around?

Starting from when I was running IBM’s MQSeries business, in the 1990s, I learnt a big lesson about seeing things from the user point of view.

We had a great messaging product, and it started the EAI (Enterprise Application Integration) market rolling. Soon, vendors were pitching the wonders of business integration through an all-encompassing EAI framework….and users started moaning about it being complicated and too hard. Vendors brushed off these concerns and just shouted louder, and I was an evangelist in this….and then I started actually listening to users. I remember pitching for all I was worth on the strategic value of EAI, and then a user saying to me, “Steve, we believe you. But we can’t get there in one jump – at the moment, what we really need is to hook this application up with that one, that’s all”.

For a moment my strategic eye was offended. How could you take this wonderful, clever, strategic software and then just hook two applications together? What a waste! But of course, I then learnt the practicalities of life, and the imperative to focus on the business need. If the business needs Application A to talk to Application B, then that is what it will fund, and that is what it wants to achieve. Sweeping frameworks are all very well, but for most companies practical considerations come first.

Now I am having deja vu, all over again. I believe in SOA – I am an evangelist. I can see the huge benefits it promises as a strategic platform for business agility, business visibility and cost-efficiency. And yet, talking to users it has finally sunk in that while some of the more lucky companies have the funding and resources to go the whole hog with SOA, there are a large number of users who ‘just want to link A to B’, but want to do so in a way that is consistent with a goal of enterprise-wide SOA some time in the future.

The new Lustratus report, free from the Lustratus web store, discusses a more tactical approach to SOA – “message-driven SOA”. It points out that even for those companies who are terrified by the prospect of having to work out their process implementations and flows, change the way they work and deal with business transformation issues, there is a way to leverage SOA ideas in a tactical, simple way that is at least a step on the road to overall SOA adoption. Message-driven SOA is almost a reprise of the tactical use of messaging in the 1990s, but with an SOA spin on it. So, message-based flows loosely couple applications and programs together, delivering the benefits of business integration without necessarily having to get tangled up in full-scale process re-engineering and modelling. And yet, the reuse concept of SOA is also leveraged, together with the ability to expose these message-based integrations as SOA services.

Message-driven SOA may not be the answer to every problem. As a rule of thumb, it will be most attractive for integrations that are primarily of the application-to-application kind, where human interaction is limited and tasks are of short duration. But it is well worth a look to see if this simpler approach to getting tactical SOA benefits might be useful.


Will Intel’s attack on appliances work?

At the recent Gartner SOA show in London, I was surprised to see a stand from Intel.

Turns out Intel are striking back at the burgeoning SOA Appliances market. The Intel claim is that its ‘software appliance’ performs at least as well as Appliances, and is therefore a better option.

The Intel argument is based on the fact that when you buy an appliance, you are locked in to the platform eg the box. So, as time passes, your appliance misses out on latest hardware or chip developments since it is hard-wired. In contrast, if the same performance can be obtained in pure software, then this has the advantage that it can be moved onto a platform with more power if needed, or as platforms are upgraded it can benefit. And Intel claims that its sexy software can match or exceed appliance speeds because it is so highly optimized.This optimization is apparently all around the XML parser. This makes sense in the SOA Appliance space because most SOA Appliances are seployed to deal with high volumes of XML conversions. The Intel claim is that it has a super-slick parser and that is how it can beat the Appliance.

This certainly throws up a new consideration when looking at the case for appliances, but of course it should be remembered that performance is not the only reason people buy them. Off-loading from the production platforms is another reason, and not having to worry about the platform management is another (install, config, etc). However, the Intel argument is a good one. Perhaps the biggest worry I have, however, is that whatever one company has done in software, someone else can do too, and unless it is patent protected, there would be nothing to stop an appliance maker coming up with a super-fast parser, and then putting it into microcode. It seems to me that in the end hardware will always be faster than software.


Whoa WOA!

Sometimes I get tired of being the guy in front of the train waving my flag and hoping I can stop or divert it.

I get called old-fashioned, blinkered, boring, misguided and a whole range of other names not suitable for printing here – but at the risk of getting another postbag of objections, I want to raise my flag again with respect to WOA (Web-oriented architecture).

I read Dion Hinchcliffe’s excellent article on WOA, discussing whether WOA was the future for SOA. The argument was essentially that SOA has not delivered the expected benefits, but WOA can. Essentially, WOA is all about arranging information in terms of resources that are accessed through HTTP in the same way as URLs. You have GET, PUT, POST and DELETE commands just like in most message-based SOA solutions. The resources are manipulated by components such as browsers etc, and it is the responsibility of the component to understand the representation and state changes of the information.

I have no problem at all with this – sounds great. My problem is the suggestion that this is the future of SOA – the implication that in some way SOA has failed and WOA, close cousin that it is, is the natural evolution. I have a couple of major grumbles here.

Perhaps the biggest is that WOA is all about a connectivity / integration architecture – a technical network really. The fundamental change with SOA from what people have done before is that SOA services are on business boundaries, not technical ones. Hence a SOA service is something that makes sense in business operations terms – eg Get Customer Details. Perhaps the implication is that in WOA the resources are also synonymous to business ops, but then how are they defined when the responsibility for understanding their representation and behaviour lies exclusively with the browser or other component accessing them?

Another particular gripe I have is that whereas SOA is based on a messaging bus to do the transfers, such as an ESB or a reliable messaging pipe like WebSphereMQ, in WOA all comms are done using HTTP, presumably with reliable delivery being provided through WSReliableMessaging ha ha. In fact, doing once and only once delivery of messages is really hard, and as we all know from the number of times we receive duplicate emails or none at all, HTTP is not brilliant at it. As for WSRM, as is often the case with standards developed to try to counter a dominant market de jure standard, the lowest common denominator approach required to get agreement across a range of parties renders the standard very questionable in terms of maturity.

Apart from that, I applaud WOA. As an analyst I am always delighted to see a new idea come to fruition, particularly with a new buzz word that has to be explained. After all, that is how analysts makes their businesses work! And to be serious, I see real value in WOA – but if people start looking at it as a replacement for SOA then I think users are in for a shock.


Secure mainframe SOA-in-a-box

I was reading the announcement from Layer7 about its ‘SOA-in-a-box’ for IBM mainframe users, and a number of things struck me.

First, I am SO PLEASED to see someone remembering that CICS is not the only mainframe transaction processing environment in use today. A significant number of large enterprises, particularly in the finance industry, use IBM’s IMS transaction processing system instead. With the strength and penetration of CICS in mainframe enterprises, it sometimes seems like these users have become the forgotten tribe, but investments in IMS are still huge in anyone’s numbers and it is a smart move to cater to them. I am sure that the fact that this solution serves IMS as well as CICS users will be a big plus.

The other point that struck me was that I have felt for some time that, with the security/intrusion detection/firewall/identity management market seeing such a shift to security appliances, it was time vendors thought of piggy-backing functionality onto these platforms. Of course, one reason for having an appliance is to provide a dedicated environment to address issues such as security, but in truth these appliances are rarely used to anywhere near capacity. Therefore it makes a lot of sense to optimize the use of the available processing power rather than slavishly locking it away where it can;t help anyone.

Finally, I have to admit my first reaction to this announcement was to worry about how good connectivity would be to the mainframe. Dealing with mainframes is an arcane area, and I was not aware that Layer7 had any special expertise or credentials here, but I see that GT Software is apparently providing the mainframe integration piece. This makes me a lot happier, since this company has been dealing with mainframes for 20 years. In fact, Lustratus did a review recently on GT Software’s Ivory mainframe SOA tool, which is apparently what is included in the Layer7 box.

Anyway, on behalf of all those IMS users out there, thanks Layer7!


Is ‘Stealth SOA’ the only choice?

Some of our recent research at Lustratus has given me the opportunity to talk to a lot of end user companies trying to get going with SOA, and a range of different roles within these users spanning all the way from the programmers to business people.

As a result, I am beginning to wonder whether the only option for SOA implementation is the Stealth model.

Leaving aside those visionary companies who are able to write off large investments on the latest new idea, or on a belief, most companies are forced to take a pragmatic view. As outlined in the Lustratus 2008 forecasts, there is a definite fracturing of SOA-related decision making between the archtiect bodies that see the value clearly, and the business-driven projects that own the budgets but do not see the need to include SOA costs in their business cases. When you think about it, this attitude from the business side of the house is not unreasonable – after all, what does SOA mean to a business unit? The discussions often go like this.

You will get get business agility and flexibility – the ability to respond faster to market changes.

– Oh yeah? When? How much do I have to invest before this happens? When do we reach critical mass? How long do I have to wait? Prove it!

The P&L will improve because we will reduce redundant code and wont write so much new stuff.

– When? What is the payback time? Why have you guys been building duplicate programs anyway? And how does that increase my project budget now, to cover the extra costs you want me to include?

But it is all for the best – honest!

– Do I HAVE to use SOA? Can I do what my project needs without? All I care about is this project, its allocated budget and the returns.

The problem is that SOA actually asks the business user for a lot of faith, just like other major infrastructure changes fo the past. One way around this impasse that many users have started to employ is the ‘SOA by Stealth’ approach. The first step is to get the SOA infrastructure assembled – ESB, Registry etc. These components can sometimes be slipped into projects without arousing suspicion, usually by claiming that the particular project needs it. Breaking the infrastructure up this way avoids the problems caused by a sudden large investment. Then, as each project is done programmers try to gradually turn pieces of functionality into SOA services – as many as can be done without drawing too much attention and impacting the budget too much.

The idea is that eventually it will become possible for IT to assemble the evidence that SOA is actually delivering benefits, at which point it becomes much easier to convince project budget holders to allocate some investment to it. In other words, the hope is that once the boulder starts rolling it


Will TIBCO be next on the acquisition block?

So, now that BEA has finally fallen to Oracle, who will be next? My money is on TIBCO.

TIBCO Software has done extremely well since it came into existence from its origin as as Teknekron. Initially an EAI (Enterprise Application Integration) company, it quickly expanded to take on challenges such as Workflow, Business Process Management (BPM) and service-oriented architecture (SOA). More recently it added Business Intelligence and Analysis to its portfolio, strenghtened by the acquisition of Spotfire last year. TIBCO products are well-respected, and it has a strong and loyal customer base.

But with BEA going, and webMethods being taken out by Software AG, it is more or less alone as a pure-play middleware player left. In addition, anyone looking at the results for its 2007 fiscal year (ended Nov 30th 2007) will immediately realize that it is an attractive target. The question isn’t really whether TIBCO will be bought, but by whom.

Names being kicked about include all the usual suspects – IBM, Oracle, SAP….but I reckon that HP might snatch the prize. It missed out on BEA, but perhaps on reflection TIBCO is a closer match to its needs.


Will mashups mash up your infrastucture?

One of the forecasts in the Lustratus predictions for 2008 Insight, available free of charge from the Lustratus web store, deals with the emergence and adoption of mashups.

At this moment it is unlcear how fast mashups will be adopted, but Lustratus thinks that any serious adoption will place massive strain on enterprise infrastructures, causing the unwary to buckle and collapse.

Mashups seem great. The user is suddenly in a position to create his or her own page layout with all the business applications needed to carry out this user’s activities. A great productivity boost, perhaps, but what are the impacts on the enterprise? Basically, as Lustratus points out, every desktop becomes an application. Instead of an IT department having to worry about 10 or 20 applications, all of a sudden there are 100s or even 1000s. Worse still, while traditional IT-controlled applications are usually controlled fairly rigorously with procedures, policies and management practices, the world of mashups could well be more akin to anarchy.

Fundamental to a productive mashup will be the need to drive the different business services required by the particular user, and therefore services will suddenly become tools used by hundreds in many different ways. All of this activity could create huge traffic increase as well as a generally uncoordinated style of operations, causing major difficulties for the infrastructure software trying to hold everything together.

Well, OK, maybe this is a little negative – but the point is, enterprise architects and management should start considering these issues now. Trying to sort this out when the genie is out of the bottle will be a lot more difficult…..


Tight times ahead for software industy will favor innovation

As it comes to the end of 2007, the dreaded market outlook surveys are starting to appear (Don’t worry we will be putting out our own 08 predictions in the near future!).

According to IDC reported in Information Week, 2008 will show lower growth in IT spending than in 07.  In particular, there will be a lower rate of growth in the US (3%-4% compared to 6.6% this year).

InformationWeek’s coverage highlights an interesting prediction: SaaS vendors may suffer more if the downturn is prolonged than license vendors as their fixed costs (infrastructure and support) are proportionately higher.  This may appear to be an ironic twist on the supposed resilience of the SaaS business model.  The downside of renewal business is that people may not renew or more likely downsize their commitment.  If SaaS companies do suffer, I suspect that it will be more to do with maturity than an underlying weakness in the model:  Recent SaaS entrants will need to get used to the business cycle and cut costs accordingly.

The article also reports the prediction of continued above average growth for Oracle.  I suspect that the other giants will also do well in 2008 as smaller vendors get squeezed between an increasing tendency among procurement to consolidate on a handfull of vendors and the downward pressure on software license pricing in general.  Start-ups in particular will be under pressure as there is likely to be a reduction in spending among the large banks resulting from the sub-prime issue and this is a sector that has traditionally fostered start-ups.  However, this sectoral tightening will simply reinforce the trend among start-ups to focus on the telcos and the government sector.

Surprisingly finally after all that doom and gloom, I am not actually pessimistic about the impact of a spending slow down if one occurs.  Tightened markets can also favor innovation over financial firepower:  As some customers become more interested in finding something different to get an increased return, those vendors who actually have something new and are capable of putting up with increased sales cycles will continue to sell and thus will be well placed when markets expand again.


Jitterbit kick-starts an OSS solution marketplace

An article in ebizq alerted me to Jitterbit’s just launched “Trading Post” for integration-specific solutions.

Jitterbit claims to the “World’s most popular Open Source integration platform” – which surprised me as I had not heard of them before.

The idea of setting up sites to enable the selling of software components is hardly new (although rarely successful) and of course sharing is precisely what an OSS community is supposed to be about. What is more interesting about the “Trading Post” idea is that

– It focuses on solutions: i.e. not just source code for the bits of the puzzle but also the patterns and knowledge essential to deliverying the complete solution.  And directs potential users to the services provided by “Trading Post” providers who can help to deliver the solution and

– It focuses on both application specific solutions (such as JD Edwards) and industry specific solutions.  Again moving the emphasis away from raw technology towards problem solving.

– It provides an interesting revenue opportunity for OSS service providers/vendors who often struggle to drive revenue from support/maintenance alone.  This is because it crisply defines the value they (as Trading Post providers) can give around specific solutions.

While just launched, it is already ‘pre-stocked’ with 50 solutions which demonstrates a certain amount of apparent momentum.  Perhaps it is a model other OSS vendors should take a look at…


So what exactly is SOA governance?

If SOA is all the rage at the moment, then SOA Governance is the most frequently used term related to it as far as I can see.

All the vendors, and many analysts, are talking about SOA Governance as the big issue, and tools are rapidly appearing to help with this governance issue.

I am wondering, however, if there may be an ulterior motive here. In business parlance, governance is an important word – it is definitely seen as more business than technical. So, is the word being hi-jacked by vendors keen to try to find yet another way to hook into the business world in order to secure the budget commitment to make product purchases? What is really meant by governance?

Governance seems to be all about defining expectations, controlling and granting powers, and measuring results. Funny that it is the root of the word Government, and a cynic might argue that these are three things that most Governments do NOT do well, but there you go. Anyway, in SOA tools terms this follows on to a number of different areas – project management tools / SLAs, security and management. Notice that these are implications at the tools level; some of the biggest aspects of governance are actually at the management process/procedure policy level.

If you now look at vendors claiming to play in the governance space, offerings typically fall into one or more of the following categories:

  • Technical management tools – administration, systems monitoring, statistics
  • Business management tools – SLAs, BAM, KPI management, dashboards
  • Security tools – user authentication, authorization
  • Project management tools – requirements management, policy enforcement
  • Planning/education/training services to build the relevant knowledgebase and skills

In my view, the outcome of all of this is that it does not help to keep preaching about SOA governance, unless you offer answers to all these areas. I would find it much more helpful for vendors to say that they sell management tools, or business monitoring, or professional services, or project management assistance. The problem today is vendors are so desperate to hook into the business community that everything is lumped together as governance.

Is it any wonder users are confused about what they are being offered, and how it fits to what they want?