Don’t be afraid to ask for SOA help

While the number of SOA success stories grow, there are a lot of companies that are finding SOA a struggle.

As often happens when something gets heavily hyped, managers are almost embarrassed to admit that they are having trouble. But the truth is that for many, getting outside help may be the best way forward and end up giving great returns.

There seem to be three common SOA ‘failure’ scenarios.

  • This SOA-based project is blowing its schedule/budget/SLAs
  • We are diligently implementing SOA, but we just aren’t getting the returns we expected
  • Everybody agreed SOA was a great idea, but now nothing is actually happening

It is easy to feel that these scenarios must reflect badly on management or technical efforts, since other companies seem to have succeeded with no problems. But in fact, it is perfectly natural to find SOA difficult. In essence, SOA is REALLY different – it is a different way of working, the tools are different, programming is different, design is different…..and so on. However, an important corollary of the success of SOA in other companies is that there is a growing pool of knowledge around SOA procedures and best practices. Already, there are some professional services organizations that have embraced all this accumulated knowledge and developed service offerings specifically designed to unblock the SOA logjam – getting projects moving again, finding why the SOA strategy is not delivering, and clearing up any organizational or procedural blockages.

Companies should not feel bad about asking for help. It really can be worth it, even if there is an initial investment hit. And fortunately, once IT and business professionals get the hang of SOA, they wont need the outside help, so the cost hit does not have to be an ongoing one. The key is to make sure companies choose the right partner. This is a subject that is discussed more in a recent Lustratus Report, “A little help goes a long way”, that can be downloaded for free from the Lustratus web store.


Alerts vs Notifications – moving to a business focus

I have been doing some research recently on how the world of alerts has changed, and I am now a convert in the alerts vs notifications debate to the notifications team.

The change of terminology is not just cosmetic – to me it really represents the difference between a technical perspective and a business one, and the business one embodies so much more value.

My own memories of alerts stem from systems management tools, where if a monitor detected a problem an alert was sent to the operational bridge or perhaps some other node for action. This is a simpe answer to a technical problem – “I need to let someone know that something has happened, so they can work out what to do (if anything)”. But from a business perspective this is pretty damn inadequate. This ‘fire and forget’ approach of raising an alarm and then walking away is no good if there is a business reason to CARE about what might be done.

Notification is a different word – most dictionaries talk about alerts as ‘warnings’. In contrast, the Oxford dictionary describes notify as meaning to ‘inform or give notice to (a person)’. In other words, notifications are more about an exchange of information as opposed to turning on a warning light.

So what does this mean in real terms? Is this just a grammatical argument? The answer is – not at all. Notification software suppliers are focused not on just getting a warning out, but communicating with the ‘right’ individual to get some action to happen and tracking activity to resolution. Good notification software has to not only get the message to the target in the appropriate way, such as email, SMS text, fax or voicemail, but also has to be able to ‘close the loop’ in the whole process of reacting to the detected event. For example, what if the target person is not available? Can calendars be consulted? Is there a way to implement an escalation process? Can the recipient of the notification communicate status back? Is there a way for the notification to be officially closed when resolved?

If real business value is to be obtained from notifications, it is imperative that the whole notification process can fit into the overall operational workflow. For anyone interested in more about this subject, and the necessary functionality to make closed loop notifications work, Lustratus has just published a report, “Closed Loop Notification Software”, available from the Lustratus store.


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.


Time for the emergence of SOA-Lite?

In a recent post, I was reflecting on the buzz about WOA (web-oriented architecture) – this subject has come up as a possible way to deliver something similar to SOA but in a more lightweight fashion.

Now, as I discussed in that post, I have problems with WOA. But it led me to thinking… it time for SOA-Lite?

A common software industry phenomenon is the advent of a Lite version of a technology, based around the 80/20 principle. That is, products start to emerge that may only do 80% of the functionality of the original market entrant, the cost and effort required to deploy the Lite version tends to be 20% of the original.

In the integration space, take the example of message brokers and ESBs. Message brokers were developed to provideĀ  comprehensive functionality to satisfy the widest possible range of market requirements, but were typically difficult to deploy and cost a fortune. Then ESBs emerged, providing a subset of the functionality but at a greatly reduced price and with considerably less implementation work required.

This is a natural evolution, driven by market acceptance models. The first users of a new technology tend to be the visionaries who are big enough and ugly enough to make a success of the technology, but they are also going to be very demanding functionally. However, as adoption moves to the more pragmatic buyers, focus switches to getting the basic functionality at the cheapest cost and the minimum of effort.

Maybe SOA is reaching this point. Companies have had great success with SOA, but many would admit it has been hard going. Many smaller or more pragmatic companies are looking forward at SOA with a mixture of desire and dread, reluctant to dip their toes in the water. So maybe this is the ideal time for SOA-Lite to emerge. SOA, but done as simply and easily as possible at the cost of some of the more esoteric or high-end functionality. One aspect of SOA-Lite, for example, might be to rationalize the number of tools required for development, composition, deployment and operational support. Most vendors offer excellent tools to model processes, to design and develop services, to deploy them and to monitor operations. But these are usually all different tools, each requiring its own education. The concept is that since SOA will be deployed everywhere, you will need to most powerful, role-based tools to handle it.

But think from the pragmatic viewpoint. Looking for a quick win to justify investment, how about offering a single environment for service creation, composition, deployment and even monitoring? How about making pre-packaged decisions about definitions and configurations to make the whole job easier? Will this approach work with every SOA scenario? No – of course not. But will it work for most? Probably, at least basic ones. And once users are starting to build up confidence in SOA, with a few quick successes, there is no reason that a full function suite can’t be brought in at a later date.

So, will we see SOA-Lite offerings this year? Some of the larger vendors might not be too keen initially, since this might damage their revenues, but in the long run the result will be a bigger SOA pie for all vendors to share.


What is an SOA Service – reprise

It looks like there is still some level of debate over the definition of an SOA service, according to the excellent Loraine Lawson’s recent post.

This was a topic covered in detail in a free Lustratus paper in 2007, entitled ‘What is an SOA Service?’ (catchy title). Now, I haven’t read the referenced article in Loraine’s post, but it seems a good time to take one more stab at this at a reasonably non-technical, simplistic level. I like to look at SOA not in isolation, which can result in the person with the loudest voice claiming the right definition, but in terms of its place in the evolution of IT.

People started with programs. Because they were hard to understand, particularly if you hadn’t written them yourself, structured program was introduced including things like subroutines. Then people realized that if these subroutines and other programs were put together in an encapsulated fashion, with clearly specified inputs and outputs, they became like little black boxes that could be used to build a bigger program – these reusable components were called Objects. But now users started to have multiple platforms and application environments, and the need arose to be able to get these components to talk to each other, so messaging was introduced to provide a communications pipe, usually asynchronous in nature to provide more flexibility. A value-add layer on the communications pipe dealt with issues of different components being based in different environments, for example, and EAI (Enterprise Application Integration) was born.

But all this was still at an IT level, and for years business executives had been pushing for better business alignment of IT. So the next development was to move the IT components onto business boundaries as opposed to technology ones, through SOA (service-oriented architecture). This helps provide a business-oriented view of both design and operations. Of course, being an evolution, SOA retained a lot of the other developments discussed above – so an SOA service is not only business rather than technically oriented, but is self-contained with clearly described inputs and outputs, reusable and accessible from anywhere through a communications pipe (often an ESB, Enterprise Service Bus) that offers value add services such as transformation and routing.

So, in summary, an SOA service

  • represents a clearly defined business operation
  • Is self-contained and reusable
  • is accessible from anywhere
  • responds to well-defined inputs with well-defined outputs

I realize this is a gross simplification, but I hope it is helpful.


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.


IBM events make an impact on SOA

IBM certainly seems to see SOA as a key initiative, if its annual SOA show is anything to go by.

The IBM Impact 2008 even in Las Vegas attracted more than 6000 attendees, and they can’t all have gone just for the weather! But the most salient aspect of the event as far as I was concerned was the ‘event’ support – not the army of people ensuring the party ran smoothly, of course, but the addition of the WebSphere Business Events product.

Event handling has always been possible with WebSphere, but it was messy. Triggers could be set on different queues, and conditions could be detected in various ways, but the whole thing was pretty technical and complex. However, IBM’s new product, based around its acquisition of AptSoft technology, delivers exactly what business users are looking for; the ability to write business rules in their own language that can control operations.

One of the key characteristics of SOA is that it breaks monolithic application stacks into individual services, each executing a discrete piece of business functionality such as ‘Get Customer Details’ or ‘Book Delivery Date’. In addition, information flowing in and out of these services is cleanly architected in a standards-based fashion, and is therefore easily accessible. But this opens up a magnificent opportunity to deliver business control over operations through the use of business rules that implement corporate policy by changing execution and flow.

For example, if a bank wants to offer students the opportunity to make payments from their accounts with no charge, a business rule could be written that says ‘If account holder is a student, then skip the charge calculation step’. This is a simple example, but with the addition of a correlation capability IBM has ensured that much more complex rules can be put in place. Consider the type of rules needed to mitigate the risk of fraud, for instance, where multiple conditions from a range of different systems would need to be assessed to detect suspicious activity patterns.

The key is that these things can be achieved with the use of business rules that the business analyst can understand. This makes change quicker, and reduces the risk of misunderstandings between the analyst and IT technical staff.

With the addition of WebSphere Business Events support, IBM SOA has finally grown up. I guess the next step could now be a comprehensive BAM solution……we can but hope.


Breaking the SOA logjam

One of the 2008 forecasts in the annual Lustratus look ahead is that SOA decision-marking has become fractured in most companies, with clashes between architects / IT who ‘get it’, and business-oriented budget holders who don’t.

In fact, this problem is turning out to be so severe that it is causing SOA adoption to stall at many companies – although enterprise-wide decisions may have been taken to adopt SOA, projects steadfastly refuse to enact this because of the extra costs, at least initially.

The roots of the difficulty here are twofold: understandable cynicism and the need to reach critical mass of SOA deployment before benefits start to show. However, there may be a light on the horizon, as discussed in more detail in the Lustratus Whitepaper, ‘Justifying SOA to the Business’, available for free from the Lustratus webstore. For business audiences, it may be that the enhanced business visibility offered by SOA could be a compelling benefit to justify the extra investment, and this visibility becomes apparent immediately the project is complete – there is no need to wait for critical mass to be achieved before seeing the benefit.

Hopefully, this angle of attack may succeed in breaking down the SOA adoption log-jam, enabling companies to flow smoothly to widespread SOA adoption.


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!