LiteBytes from Lustratus Research

SOA success, and what causes it

I was recently pointed to an articlein Mainframe Executive magazine written by David Linthicum on the subject of "Mainframe SOA: When SOA Works/When SOA fails". I think the friend who suggested I read it was making mischief, knowing my views on the subject of SOA and guessing (correctly) that this article would wind me up.

In summary, the article says that SOA is a large and complex change to your core architecture and working practices and procedures, and that the success or failure is dictated by questions such as executive buy-in/resourcing/funding/skills, and not technology selection.

"The truth about success with SOA is that it has little to do with the technology you want to drag into the enterprise to make SOA work, and more to do with the commitment to the architectural changes that need to occur"

I have two problems with the opinions stated in this article. The first is to do with changing attitudes to SOA, and the second with the technology comments. 

Let me first state that I am well aware that if a company wants to adopt an enterprise-wide SOA strategy designed to take maximum long-term benefit from this new way of leveraging IT investments, then this requires all ofthe areas brought up in the article to be addressed - skills, management buy-in, political will, funding and a strategic vision coupled with a tactical roadmap. I have no beef with any of this.

But I would contend that the world has changed from two years ago. The financial constraints all companies are experiencing have more or less forced the long-term strategic play onto the back burner for many. Some analysts actually like to claim that SOA is dead, a statement designed to be controversial enough to gain attention but to some extent grounded in the fact that a lot of companies are pulling back from the popular SOA-based business transformation strategies of the past. In fact, SOA is absolutely not dead, but it has changed. Companies are using SOA principles to implement more tactical projects designed to deliver immediate benefits, with the vague thought of one day pulling these projects together under a wider strategic, enterprise-wide SOA banner. 

So, as an example, today a company might look at a particular business service such as 'Create Customer', or 'Generate Invoice', and decide to replace the 27 versions of the service that exist in its silos today with a single shared service. The company might decide to use SOA principles and tools to achieve this, but the planning horizon is definitely on the short term - deliver a new level of functionality that will benefit all users, and help to reduce ongoing cost of ownership. While it would have been valid a few years ago to counsel this company to deliver this as part of an overarching shift to an SOA-oriented style of operations, today most companies will say that although this sounds sensible, current circumstances dictate that focus must remain on the near term.

The other issue I have with this article is the suggestion that SOA success is little to do with the technology choice. Given that the topic here was not just SOA but mainframe SOA, I take particular exception to this. There are a wide range of SOA tools available, but in the mainframe arena the quality and coverage of the tools vary widely. For example, although many SOA tools claim mainframe support, this may in actuality simply be anMQ adapter 'for getting at the mainframe'. Anyone taking this route is more than likely to fail with SOA, regardless of how well it has taken on the non-technical issues of SOA. Even for those SOA tools with specific mainframe support, some of these offer environments alien to mainframe developers, thereby causing considerable problems in terms of skills utilization. It is critical that whatever technology IS chosen, itcan be used by CICS or IMS-knowledgable folk as well as just disributed specialists. Then there is the question of how intuitive the tools are. Retraining costs can destroy an SOA project before it even gets going.

For anyone interested, there is a free Lustratus report on selecting mainframe SOA tools available from the Lustratus store. However, I can assure companies that, particularly for mainframe SOA, technology selection absolutely IS a key factor for success, and that while all the other transformational aspects of SOA are indeed key to longer term, enterprise-wide SOA there are still benefits to be gained with a more short-term view that is more appropriate in today's economic climate.

Steve      

Pragmatism is the theme for 2009

I have just returned from a couple of weeks around and about, culminating in presenting at the Integration Consortium's Global Integration Summit (GIS), where I presented the Lustratus 'BPM Sweet Spots' paper. One message seemed to come out loud and clear from the conference - pragmatism is the watchword for 2009.

There were two other analyst presentations apart from the Lustratus one, and I was surprised to see that both presenters pitched a message along the lines of 'you will never succeed with SOA/Integration/BPM unless you get all the strategic planning and modelling for your enterprise done first', combined with a suggestion that the presenter was just the resource to ask for help! This contrasted sharply with my own presentation of choosing tactical targets for BPM rather than going for a strategic, enterprise-wide, fully modelled approach.

I was wondering if I had read the mood wrong in the marketplace, but then the eight or so user case studies all proved to be tactical strikes for specific business benefits rather than the more extensive strategic approach more common a year or so ago. It was nice to be vindicated - it looks like 2009 really IS the year of pragmatism and short-term practical considerations.

Steve

The forgotten SOA benefit - Visibility

There has been a lot of chatter recently about measuring SOA ROI - take a look at Loraine Lawson's recent blog for instance. or Gartner's results of a UK-based survey of SOA adopters. However, one of the benefits that I think a lot of people miss, or do not attribute enough importance to at least, is Visibility.

Basically, the visibility story goes that with SOA, since you break up operational components into discrete business services, then it becomes easy to monitor entry and exit to these services and hence business operations flow. This gives a clear picture in business terms of execution and performance - not just what is happening, or how many times, but HOW business is being carried out.

Gartner did touch upon visibility, 

"Improved Efficiency in Business Processes Execution - Isolating the business logic from the functional application work enables a clearer view of what a process is, and the rules to which it adheres. This can be measured by lower process administrative costs, higher visibility on existing/running business processes, and reduced number of manual, paper-based steps; better service-level effectiveness; quicker implementation of process iterative or of variants of the same process for different contexts."
 

However, the Gartner focus was only on visibility as it relates to execution efficiency. In fact, SOA-based visibility offers another benefit which, in today's tough times particularly, can be a real big hitter for executive management. It enables management to see how process are being executed - in other words, it provides the ideal tool to monitor compliance against a growing raft of regulatory requirements across just about every industry. In order to demonstrate that your systems comply, it is necessary to be able to see what they are doing and how they are doing it. This is what SOA delivers.

So how does improved compliance management fit into the ROI picture? True, it is very hard to attach a dollar amount to compliance - however it certainly matters. With the amount of public and political scrutiny of corporations today, it is absolutely imperative that executives can show they are faithfully adhering to regulations and guidelines. Failure to do so will not only risk severe penalties, but also probably lose them their jobs! Now THAT's a compelling business case....

Steve

Does Microsoft ESB Guidance have a future?

As one might have expected, Microsoft tried to ignore the Enterprise Service Bus (ESB) movement for a long time, but eventually it had to do something to answer demands of its customer base looking for SOA support. Its response was Microsoft ESB Guidance, a package of

"architectural guidance, patterns, practices, and a set of BizTalk Server and .NET components to simplify the development of an Enterprise Service Bus (ESB) on the Microsoft platform"

Let's be honest. This is a typical Microsoft 'fudge'. Microsoft ESB Guidance is not a Supported Product, but is instead a set of guidelines and one or two components. It is a Microsoft Patterns and Practices offering - in other words, you are on your own. This may be fine if you are a Microsoft development shop, but far more worrying if you are real business user with extensive Microsoft presence. It has a lot of the disadvantages of Open Source, but you still have to pay for Bizt Talk etc..

So what does the future hold? Will trying to bring the Microsoft server world into the SOA domain always be a matter of risk and going it alone? Will Microsoft productize Microsoft ESB Guidance? Are there any alternatives other than just consigning the Microsoft platform to run in isolation on the fringes of the enterprise?

Fortunately, the Microsoft model may actually be working here. I do not believe Microsoft will ever productize ESB Guidance - after all, they have had two years and are still maintaining there are no plans to do this. However, what this position does do is it encourages opportunists to jump in and develop products based around the Microsoft technology and guidance materials. An example is Neuron-ESB, from Microsoft specialists Neudesic. 

So, while Lustratus strongly cautions users about the effort, cost and risk of using Microsoft's own ESB Guidance package, the idea of utilizing a Microsoft-based supported ESB product from a specialist vendor is much more attractive. Of course, whether these new Microsoft-based ESBs are any good is yet to be seen....

Steve 

Why do so many SOA adopters moan about low reuse levels?

I was reading a recent post from Joe McKendrick the other day on measuring SOA success, and it reminded me of a related issue - that of measuring services reuse. SOA adopters often moan to me that despite having implemented SOA and deployed many services, reuse rates are down at the 1-1.2 level - in other words, virtually no reuse. They seem to want to pick a fight with me because as an advocate of SOA I have often pointed to reuse as one of the more measurable benefits. After all, achieving a high level of reuse is a clear indicator to business executives that efficiency is increasing, since the implication is less development is required to do new things.

I am starting to get pretty short now inthese conversations. I wish, wish, wish that people would heed my previous advice - don't think of SOA delivering reusable services, think of it as a great tool for SHARED services. Obviously reuse will come through services being shared - so what point am I trying to make? The problem is people are choosing to build 'reusable services' with SOA and assuming that others will start reusing them. It is the old 'Build and they will come' philosophy. This rarely works - it is worse than a scatter-gun approach. If users instead think about what services would be good candidates for being shared first, and then develop these as SOA services, reuse levels will definitely improve.

So, when getting started with SOA, don't encourage everyone to start building code into services and hope that reuse will come as if by magic. Start off by deciding on the logical services to build that will be shared - things like get customer history, or create new customer. Then go ahead and build these shared services candidates, and see reuse levels climb....hopefully making it easier to justify your SOA investments to the business.

Steve

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 datasheetfor 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?

 

Steve  

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. 

Steve 

Increasing payments fraud highlights rules-based processing benefits

The recent AFP report (Association for Financial Professionals) on payments fraud in 2008 makes grim reading for financial institutions, especially compared to the previous 2007 one. 30% of respondents said they experienced more payments fraud attempts in 2008 than 2007, and incidence accelerated throughout the year with 38% saying that fraud increased in the second half of the year, probably due to worsening economic conditions.

From an IT point of view, this just reinforces the need to have systems that are easy and cost-effective to change. Lustratus developed a detailed report in 2008 about the shift in the area of IT payments processing solutions, where it outlined the key elements of the new, '2nd generation' approach to payments processing as follows:

"...the 2^nd generation payments processing model needs to be based on the following key design points:-

·         An extensible, service-oriented approach featuring plug-in capabilities

·         Enterprise-wide, consolidated and centralized, real-time visibility and control of all payments processing activities, from anywhere to anywhere, based on a generic, standards-based payments model

·         A business rules-based architecture governing payments processing functionality 

And, of course, the continued provision of reliable, efficient and repeatable payments handling as provided by 1^st generation systems "

The two key features that apply to thispayments fraud example are the extensible approach with plug-in capabilities, and in particular the rules-based concept. The idea behind having a business rules-driven payments processing infrastructure is that when changes are needed in the way payments are handled, these can be implemented quickly, safely and verifiably with rules as opposed to having to change program internals with all the associated implications. For example, rules could be used to enforce the use of separate accounts for handling checks or ACH payments, or having different accounts for every different payment type. In addition, rules when combined with events processing can provide an easy way to detect out of line situations and raise a red flag.

Payments fraud is only one of many examples of the need for systems to be able to respond quickly to change - and rules-based processing combined with an extensible, service-based approach to delivering functionality provides the ideal environment to tolerate that change quickly, safely, cheaply and effectively.

Steve  

TIBCO 1Q09 earnings (part 2)

Last week I was speculating on TIBCO's 1Q09 results and its challenges in 2009, and of course the final results have now been released. I have had a lot of interest in the original post and requests to do a follow-up once the figures were out, so here we go. However, please remember that these are only my personal opinions - I am a market expert, not a financial one!

Revenue declined 9% year on year, although perhaps half of this decline might have been currency fluctuations, and through smart cost cutting measures TIBCO has actually improved profitability. However, from my perspective the most important information was that new license revenue fell to 44.8M from $57.7M in the same quarter the previous year - a 22% fall. Services and maintenance was flat at $88M.

The fall in new licenses is quite dramatic, and certainly not attributable to currency. Of course, this may reflect the generally poorer conditions, but it will now be extremely interesting to see how some of the other SOA and BPM players do in their first quarters - for example, I was discussing Pegasystems yesterday, and in 2008 it showed a 50% increase in new license revenue - it largely sells BPM software. Its 1Q09 results will be an interesting yardstick for these TIBCO results. 

TIBCO is proving to be very reliant on its messaging / SOA products, only 21% of revenue coming from its business optimization segment, and that shows how dependent it is on its traditional strength in messaging, but as I said last week this area is coming under threat and has forced TIBCO to adopt an appliance approach to try to defend its position. However in the 1Q09 period TIBCO says it did not make any major appliance sales. Anyway, although I am not familiar with TIBCO's commercial arrangement with Solace Systems, its partner in the appliance deal, I have to believe that TIBCO will no longer be able to count on all of the revenue stream from the appliance. I can see no alternative but for this segment of TIBCO's business to fall. it is not surprising that TIBCO is desperately trying to broaden its industry vertical coverage as fast as it can.

Apparently the company is actively looking to make more acquisitions. This could either be to fill in gaps in its overall solution, as its management claims, or could it be to provide non-organic revenue growth to bolster its figures?

I have to confess that personally these results have left me feeling a bit queasy about TIBCO's future. We should know more when we see some of the other 1Q09 performances in the SOA space, but I did not see anything to make me think TIBCO is surging back...

Steve 

Pegasystems points the way forward

There is a lot of chatter in the blogosphere at the moment about whether SOA (service-oriented architecture) has run out of steam - whether companies have stopped investing in it, got disillusioned with it or cast it aside for the latest new thing.For me, this is a silly discussion - SOA is about a way of doing things more sensibly, just as structured program was many years ago. It is really all about architecting system design around the concept of a pool of shared services, and cleaning up the linkages between different programs and applications.

So on this basis SOA is not dead, but an active and important architectural underpinning of a number of different initiatives, many of which have been rolled into the 'SOA' term - things like BPM (Business Process Management), SaaS (Software as a Service), Business events management, BAM (Business Activity Monitoring and many others. But has the failing world economy stopped the whole SOA family juggernaut in its tracks anyway?

The answer Lustratus picks up from its clients is a resounding NO. BPM in particular seems to be seen as a powerful way to respond to the needs of operating in an economic recession. Indeed, Lustratus pointed to BPM as a shining light in its forecasts for 2009. Validation of this claim is evident when looking at the performance of Pegasystems a major provider of BPM solutions and technologies. Pegasystems is an important indicator of BPM health because it is one of the few remaining pure-play business process software vendors left. In its recent annual results announcement earlier this month, it showed a revenue increase for 2008 of over 30% to over $200M, and importantly a 50% increase in new license revenue. It is in such good financial shape that it has even just announced a quarterly cash dividend! Admittedly it is only paying 3 cents a share, but in these times this is not to be sneezed at.

Of course, these results in isolation may not be conclusive. After all, the Pegasystems rise in sales might simply indicate it is stealing market share from its rivals. However other big BPM players such as IBM are also claiming strong performance in the segment, so it is much more likely these figures shine a light on the way forward for users as they struggle to do more with less, and get a better level of control and governance over their processes.

Steve