LiteBytes from Lustratus Research

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

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

      Steve