It must be the time of the year to introduce new acronyms (or maybe I am just noticing more that have been around for a while). Oracle is touting Extreme Transaction Processing (XTP) as a technology capable of dealing with the ever increasing data volumes which are predicted in most industries. The prize market is actually financial services where, as I previously wrote about in my Lustratus blog, the volume of market data is predicted to increase by 900% by 2012.

The business needs associated with this data deluge are not only storage – and in some cases storage is not relevant as the data has only transitory value. The greater value is in identifying the anomalies or unusual combinations that may correspond to the financial opportunity or a potential fraud. Oracle is clearly trying to address both the traditional transactional processing requirements and these new requirements which are more usually solved with Complex Event Processing tools.

As Oracle’s Dave Chappell puts it, XTP allows “transactions to occur in memory and not against the backend systems directly due to the need for extremely fast response rates, but still including transactional integrity” Fair enough.

However, he goes on to say something that Streambase and Apama (two CEP engine vendors) among others may be surprised to hear:

“Usually, a complex event processing engine is something that can also capture, correlate and apply decision rules to look for specific patterns in events over time and look for exceptions. However, there are certain applications that operate on streams of event data that is so voluminous that typical backend solutions or storage solutions just can't handle it.”

The whole purpose of CEP engines is to provide real-time analysis of massive event streams. My understanding is that to do this they precisely by avoiding using the backend solutions which Dave refers to. Which makes Dave's remarks rather confusing.

Stepping back however, it is clear that this announcement further demonstrates the growing interest among vendors in the potential value of the data deluge problem being solved. Whether the demand for these solutions will grow and break out of its traditional niches (algorithmic trading in financial services and some specialised security applications) is not yet clear.

Ronan

Posted by rbradley in CEP • Financial Services • Product news | Permalink | Comments (0) | TrackBacks (0)

Faced by the uphill struggle of justifying SOA to business managers who find the benefits of SOA hard to understand let alone quantify, it is tempting to link it to other areas of technology innovation which are (we hope) easier to justify. I have previously blogged about the attractiveness of the enterprise mash-up and impact on the infrastructure associated any wide-scale adoption of such mash-ups.

The announcement from Abode about the latest version of its RIA platform reminded me that the issues are not only associated with the ‘back-end’. In particular, the RIA space is developing fast but is still immature. The world has certainly moved well beyond the appearance of Google maps and AJAX. (Of course, AJAX was always a confusing term in that it gave the impression to outsiders that there was a well-defined piece of software rather than a general approach to creating RIA.) However, the RIA space remains an incredibly busy space as can be seen from the list of 25 different RIA frameworks listed here . This diversity reflects a great level of innovation which is good in the long term. And it is fair to point out that RIA is a wide definition – some of the 25 are focused on specific types of applications such as the Ruby on Rails for developing database backed web applications while others such as Tibco’s General Interface are clearly intended for use with enterprise middleware at the back.

This poses the challenge for the enterprise architect of which horse or horses to back. The easy answer that I have heard is that it doesn’t matter: RIA is supposedly easy to replace and are often used to create opportunistic applications (quick to create with short life-spans). If you change your mind (the story goes), simply rip and replace with another RIA. Equally, (the story continues) it doesn’t matter if one department goes for one RIA and another a second.

I remain unconvinced. Yes it is true that it is easier to replace an RIA than to replace infrastructure software such as message queues. To stretch an analogy, if switching message queuing is like a lung transplant, then switching RIA might be grafting back a finger – while I definitely wouldn’t like the first, I wouldn’t volunteer for the second either. What is being ignored is the cost of replacing or maintaining in parallel RIAs based on old tool-kits and new. What is also being ignored is that the users of these applications are the sensitive business users who will not appreciate the disruption of their favorite tool which follows on from switches in strategy.

All of which means that we need to look at the RIA options with a great deal of care: The opportunities and benefits are certainly considerable. However as with other bets on early markets, there are significant downsides as we inevitably make the wrong choices from time to time.

Ronan

Posted by rbradley in Mash ups • Product news • SOA Predictions • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

For all the claims of some OSS enthusiasts, OSS came to the SOA game a couple of years later than the closed source vendors. Coming in later has its benefits of course: the needs are clearer and the late comers benefit from the experiences of the early innovators. This 'second mover advantage' is particularly strong with SOA as the market has developed quite slowly. This slow growth stopped the early innovators on the closed source side from getting any sort of market dominance.

Most of the OSS SOA solutions have up until recently focused on the base infrastructure required for first generation SOA projects (I say most as Bosteq for one took a different tack by focusing on the major 'higher level' problem: developer productivity). What has been lacking or weak with the OSS offerings has been the enterprise level capabilities such as management and application connectivity which are essential for any widescale deployment of enterprise infrastructure software.

Alex Fletcher's blog on RedHat's ambitions for its SOA strategy highlights two recent partnership announcements which shows RedHat is the latest OSS SOA vendor to start to address these gaps: Partnering with iWay on enterprise application connectors and with Hyperic for management.

iWay has become the standard port of call for most if not all SOA vendors needing an enterprise application connector story - I say story because while end-users like to know that such connectors are available, they do not necessarily end-up buying them. For RedHat, it presents some interesting issues: iWay is not an OSS vendor - and hence the customer is forced into a hybrid model of OSS and closed source. While this may not be a problem (IONA follows a similar model within its own family of closed and open source products), it seems to be a major disparture for a company such as RedHat so closely aligned with OSS.

The Hyperic relationship is also a little me-too as it follows the path already followed by MuleSource. In this case there are no 'religious differences' as Hyperic is also OSS. And me-too has some obvious advantages for the users: It is better if vendors converge onto one solution as any widescale SOA deployment is bound to include multiple SOA platforms which need to be managed as a whole.

Which makes both announcements positive steps for RedHat. However, they still have a long way to go before they are ready to win the 50% of the market which Alex points out is their strategic goal. And in my opinion they must greatly accelerate their moves to make their platform enterprise grade if they are to have any chance to achieve that goal by 2012 as is their stated aim.

Ronan

Posted by rbradley in Market Trends • Product news • SOA Predictions | Permalink | Comments (0) | TrackBacks (0)

As the title of this blog is "Roads to SOA" (for the moment at least), I though it was worth noting two anniversaries which relate to two of the most significant factors in the implementation of SOA: The Open Source movement and XML.

Over the last 3-4 years in particular, Open Source has been one of the major feature of SOA technology landscape and looks like only becoming stronger as OSS projects mature and IT budgets get squeezed in the economic downturn. Denis Byron also celebrates the anniversary and provides some excellent counterpoints to the more outlandish OSS claims in general. To quote Dennis: " I can't quickly think of any (never mind "many") "business computing category" in which open source software is a leader". In the context of SOA, OSS is a major feature - although it is not a leader as yet.

XML is also 10 years old - I almost felt like writing 'only' as XML is so much part of the fabric these days it is hard to imagine a time before it existed. Over the 10 years, XML turned out to be a giant leap forward by allowing data formats to be defined independently of technology in a way not attempted before and launched countless bodies to define XML standards for industries from telecoms to financial services to travel.

In 'celebration', Tim Bray published a long piece on the people and early history which Tim Anderson both summarises and criticises for Tim Bray's hostility towards Microsoft (a common feature of the OSS community as well of course). Criticism is hardly surprising when Tim Bray makes the delightful remark that "Mick [Microsoft in his semi-allegorical history] is a domineering, ruthless, greedy, egotistical, self-centered, paranoid bastard.".

Tim's views on Mircosoft's attitude to standards are clearly heart felt. However, having been involved with standards processes over the years - I am not sure Microsoft is necessarily that much more 'evil' than other companies which attempt to manouver the standards process to aid their commercial goals. Also having lived through the CORBA/DCOM wars in the 1990s when Microsoft was not part of the process, it seems clear to me that XML benefitted more from Microsoft's involvement more than it would have benefited from being pure and free from Microsoft which no doubt would have followed a different track and created a competing standard.

Ronan

Posted by rbradley in SOA concepts | Permalink | Comments (0) | TrackBacks (0)

SOA Governance is a term that I am having an increasing level of discomfort with. The reason for my discomfort is the large gap between what certain vendors and some analysts define as SOA Governance and what the end-users I talk to define as SOA Governance.

Specifically, some vendors and analysts focus primarily on the software tooling such as registries and repositories (and even somewhat surprisingly on management). Most end-users, excepting those recently indoctrinated, interpret it to mean the definition and 'human' enforcement of policies associated with effective SOA roll-out and maintenance. This is hardly surprising – end-users assume that SOA Governance is going to be related to governance first and enabling tools secondly. While SOA does present significantly different governance challenges, it starts in the same place as 'traditional' governance: definition of governance policies and processes for creating and evolving these policies. Todd Biske seems to of a similar mind-set when he writes in his excellent blog:

“I’ve said it before, and I’ll say it again. Governance is about people, policies, and process. Tooling really only comes into play when you start looking at the process portion of the equation. I don’t want to dismiss tooling, because it absolutely is an important part of the governance equation, but if you don’t have the people or the policies, tools won’t help.”

If you wonder why I am getting hot under to collar on this one, this is why: The focus on SOA Governance tools does not help most organizations deliver on SOA governance. In fact it is a distraction as the best tools in the world cannot deliver the organizational and cultural changes necessary and may lull the organization into a false sense of complacency.

Ronan

Posted by rbradley in | Permalink | Comments (1) | TrackBacks (0)

When everybody starts to agree that something is bound to be the next big thing, I get jumpy. When people start ramming the Business word in to create a new acronym, I get really jumpy. Complex Event Processing has been getting hype for a while and now IBM (according to Joe) has committed the crime:

“IBM wants to take the technical allusions out of the term itself, referring to it as “Business Event Processing.” The renaming to BEP makes sense, since I doubt if a concept that starts with the word “complex” is going to win a lot of converts.”

However, I don’t disagree with sentiment that CEP could be the next big thing. It has been considered and used a little to deal with the general increase of data volumes in some industries (financial services being in the “lead” as I covered here ).

However, there is potentially much more opportunity in the SOA context as IBM seem to recognize. As the volume of network traffic related to SOA increases, the need increases to monitor, manage and react to anomalies. Anomalies which could correspond to simple human error, to unexpected loads and even to illegal or fraudulent behaviour. Detecting an anomaly may require looking into an event, detecting specific sequences of events or any arbitary combinations of the above. CEP provides a good approach to detecting subtle anomalies occurring in massive message flows in real-time. While you could have used CEP (if it had existed) in the pre-SOA world, it would not have made much business sense: SOA potentially divides many more business processes between applications (into the SOA layer) and also increases the total volume of messages. The combination makes the total value of the messages in the SOA layer significant and therefore controlling the SOA layer becomes as important as managing applications.

The caveat is how quickly and in how many organisations if at all will this level of SOA deployment occur. I remember talking to a senior architect in a US bank last year who was pro-SOA but would never consider shifting the centre of gravity of business processes out of applications. Hence he would never need the sort of CEP control layer capability that I was proposing.

Time will tell – as with most “next big things”, it will take longer and be less massive but CEP will certainly be discussed and used in increasing levels throughout 2008 and beyond. And no, I don't think many people will call it BEP any time soon.

Ronan

Posted by rbradley in CEP • Mash ups | Permalink | Comments (0) | TrackBacks (0)