LiteBytes from Lustratus Research

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.....is 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.

Steve 

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.

Steve

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.

Steve

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.

Steve

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.

Steve

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!

Steve

Now its IONA's turn to be acquired - by Software AG?

IONA has just announced  that it has received an unsolicited offer to be acquired by an unnamed company.  Over the last week there has been speculation that Software AG is the mysterious buyer.  Software AG buying would make some sense in that it is inline with its vision of building a major integration company through acquisition.  IONA does have an excellent customer base and an interesting SOA OSS play.  On the downside, IONA main business comes from the declining CORBA market and there would also be major overlaps on its closed source SOA side with the already crowded Software AG catalog post its WebMethods acquisition. 

However, alternative buyers are less obvious as it is a company in the middle of a difficult transition - attempting to replace its rapidly decreasing CORBA revenue stream with lower than expected growth in its open and closed source SOA product lines.  Which means that I am putting my money on Software AG being the acquirer.

Ronan

p.s. It is beginning to feel like this is becoming a finance blog - rest assured with only Tibco left out there, the current merger wave is bound to come to an end!

Workday buys Cape Clear – Where did the ESB market go?

Surprising news today – Cape Clear, the Irish ESB vendor, has been bought for an undisclosed sum by the Workday, SaaS start-up providing a range of enterprise applications. This is a significant event on a number of axes:

While the ESB as a term has grown in popularity, the new vendors touting ESBs have not grown at the same rate.  My former home, PolarLake, has repositioned itself to take advantage of a specific niche (Reference Data Distribution in financial services).  Now, Cape Clear has disappeared from the ’traditional’ enterprise middleware market to become part of a SaaS play. Other vendors continue to win ESB business of course, but it is fair to say that none have broken out into the major league as might have been expected 5 years ago when ESBs first appeared.

This is in fact more general than the ESB market alone: No middleware vendor of scale has emerged in recent years.  Instead, across the board the smaller middleware vendors are being squeezed between the industry giants with comprehensive software stacks and service arms on the one hand and OSS projects on the other.  The reason for the squeeze is also three fold:

• The increasing reluctance of end-users to take a chance on a smaller vendor:  The extremes of OSS or industry giants seem less risky.
• Consolidation in key industries such as financial services and telecommunications (key markets for new middleware vendors in the past) has reduced the number of potential customers and hence increased the competition in those markets.
• The increasing sophistication of the industry giants in dealing with new entrants:  A smaller vendor must face a wide variety of onslaughts from aggressive sales tactics such as the giving away of expensive software to the promotion of OSS projects allied with service delivery capabilities.

While both the concerns about vendor viability and the sales tactics used by the giants are entirely legitimate, one wonders about the impact on the overall rate of innovation in the IT industry.  The disappearance of Cape Clear must cause specific pain for existing enterprise customers now concerned about the future of the products upon which they depend.  However, one must wonder more generally what the impact longer term of the hardening of the markets against new innovators will be on all enterprise users.

Ronan

Why Oracle should buy Tibco next

Only a few months ago, I said that Tibco would not be bought and stated:

"With Tibco, there is no obvious buyer (as Oracle was with BEA) nor is there a neat fit into one of the majors (as BusinessObjects was with SAP).  Of the 4 listed by the "Analysts" quoted above, only IBM would make any sense.  And Oracle, except that it is busy trying to eat BEA."

I now wish to recant and disagree with Steve's view that HP will get the prize.  Now that Oracle has BEA, the next obvious target for it is Tibco and it should move quickly before IBM steps in.  Here are my reasons:

- Tibco has the only big league competition to IBM's WebSphere-MQ in the message oriented middleware space.  It is used widely in the largest financial services companies, telcos and beyond.  With Tibco combined with Oracle's database etc and BEA's application server, Oracle would have the fire-power to take on IBM's hold in these accounts.

- Tibco has developed its BusinessWorks integration product which plays in the SOA/EDA/BPM space.  This is one of the best development tools I have seen in this space as well as being mature.  Combined with Oracle's and BEA's reach, BusinessWorks could deliver in the SOA marketplace in a way that it can't with a standalone Tibco.

- It would only cost $1.4bn (plus a bit of course). :-).

And finally what both Oracle and IBM have shown is that in this market there is no such thing as buying a company too soon - if you don't buy, somebody else will.

Ronan

p.s. I don't have shares in Tibco.   

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.

Steve