I am delighted to be chairing what I believe is ebizq’s first Financial services specific live panel . The emphasis is on the word specific since so many of the topics ebizq focuses on are not only of great interest to financial services but also areas where financial services are in the driving seat: From Complex Event Processing to Open Source SOA you don’t have to dig too deep to discover financial services IT organisations deeply involved. That this is the case is hardly surprising: Financial Services (which is also of course a very broad term) is heavily dependent on IT to do everything from roll-out new products to support ever more complex and real-time interactions with counter-parties, service providers, exchanges and regulators.

Of course in the limited time available in a live panel, we aren’t going to try to boil the ocean. Instead we are going to discuss how SOA investments can be augmented to address the currently particularly hot issue of visibility and control. However, with the launch of ebizq’s financial services industry solutions tab , I hope and expect that this will be the first of many finance specific event on ebizq. On that basis, let us know the areas that are of interest to your organisation and your perspectives on the latest trends in FS IT.

Ronan

Posted by rbradley in Financial Services | Permalink | Comments (0) | TrackBacks (0)

Readers who lived in the UK in the 1970s will have been surprised at IBM's announcement of SMash. IBM’s SMash isn’t in fact a relaunch of a rather chemical instant potato mix made famous for its slogan ‘For Mash get Smash’ and iconic robots of its adverts . Instead, SMash is a potentially significant development in the maturing of the mash-up in the enterprise. (I say potentially because IBM isn’t telling us much until April.)

To quote form the press release:

“SMash addresses a key part of the browser mashup security issue by keeping code and data from each of the sources separated, while allowing controlled sharing of the data through a secure communication channel.”

The possibility of leakage between sources is a key issue not only from a security perspective but also from an Intellectual Property perspective (the content may be licensed for specific use and this sharing may incur additional fees). I look forward to discovering if IBM’s proposal manages to balance the need for security against the need for usability. While this is the classic trade off with all security, it is particularly acute for Mash-ups which have the ease of creation at the heart of the value proposition.

Ronan

Posted by rbradley in Market Trends • Mash ups • Product news • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

Different industries have different priorities and adopt SOA in different ways. Ilog has just announced that their rules product, JRules is being used in Hiscox (a major insurance company which focuses on specialist and hence more complex insurance products). By a strange co-incidence, Elizabeth has just announced an upcoming event on SOA and the insurance industry.

The Ilog announcement is interesting in that it clearly states two of the most common requirements in Insurance that SOA (and in this case SOA with additional business rules) tries to meet - and one which is less commonly stated:

“First, Hiscox wanted to be able to add new distribution channels as quickly as possible.

Second, the company wanted to reduce the time and cost associated with both making changes to existing products and bringing new products to the market.

Finally, Hiscox needed to increase the ability of underwriters and business analysts to make changes to rules directly without having to change complex system logic, allowing the company to improve its business response time.”

The ability to add new distribution channels is common across financial services. As the products are purely electronic, adding a distributor is equivalent to integrating their systems with your own. This requires mediation of the message formats and flows – clearly Hiscox is using a rules based approach but of course others are possible.

The need to get to market quickly with novel products is also common across insurance, retail banking and its most extreme case in derivative trading. Again, it requires good message manipulation capabilities in the middleware.

The final requirement is to my mind the most controversial and clearly the most valuable if achieved: To take IT out of the loop when changes need to be made. If it can be done, it has clear cost and agility benefits. However to be successful it requires well formulated message formats, well understood processes and above all careful controls around what can be changed as the underwriters and business analysts are unlikely to appreciate the implications of their actions in the way IT staff have been long trained to do.

Ronan

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

Mash-ups are one of the hot areas for trialing in 2008 and a likely major project area in 2008, 2009 and beyond. The concept is appealing to business users and allows rapid development of useful applications. As I have previously blogged about, mash-ups put a strain on the infrastructure. However the impact is not on the infrastructure alone, it also puts unexpected pressure on the applications supporting the mash-ups. An early adopter in a global investment bank was quoted in a recent article in Waters as pointing out:

"you can't create a service that is designed to support 100 trades per minute and then let someone with a black-box trading system connect to it and expect happy results. The resulting automated traffic would bring the service to its knees and those supporting it would be faced with fielding phone calls from users letting them know the system had gone down."

However, system outage is only one problem - you must also ensure that mash-up user is entitled to use the data (both from an authorization perspective and also from a rights-management perspective as the data may not be licensed for use by the mash-up user).

The only solution is to increase the level of control and governance by defining and enforcing SLA and so on - in effect bringing mash-ups back with the framework of enterprise IT. The challenges will then be

- Finding out where mash-up development is happening in the organization. The very ease with which mash-ups can be created will tend to put them under the radar.

- Convincing the users and developers of the mash-ups that governance is there for good business reasons and not simply central IT attempting to regain control and squash innovation that they do not control.

Ronan

Posted by rbradley in Financial Services • Mash ups • SOA concepts • Web2.0 | Permalink | Comments (0) | TrackBacks (0)

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)