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)

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)

Within a couple of days of each other two very different organization starting to talk about the success they have achieved from moving to SOA: Wachovia, the 4th largest bank in the US and the District of Columbia.

A couple of year back, Wachovia embarked on what was understood to be a major investment and organizational shift – an investment strongly backed by the CEO of the corporate and investment banking division. It is also possibly the largest deployed SOA project in investment banking (that I am aware of at least). The remit reported in InfoWorld was to “Rock the boat, change everything, and build a multihundred million dollar, end-to-end, services-oriented development and delivery platform”.

Clearly, this was a project that followed the dream formula – the most senior sponsor signing up to stay the course. Also clear is that Wachovia believes that it is bearing fruit delivering more quickly and at much lower cost the types of custom apps that investment banks build all the time to support trading in new and ever more complex types of financial product.

In contrast, D.C. followed what is probably a more common approach – they had a serious organizational challenge that simply could not be easily fixed with the old point-to-point approach to integration: The city needed to address the crime rate and to do this the city agencies needed to work more closely together and this meant that they needed to integrate better.

Unfortunately, this integration required the 370+ data sources to be connected together. The solution was to make this the start of a SOA and implement based on an ESB (from SeeBeyond – now part of Sun):

“A few years ago, more and more [organizations] started using ESBs for data-sharing purposes,” Adam Rubinson, deputy CTO of D.C. said. Federal customers in particular have used this approach to unlock older databases.

The benefits were again clear and matched what other government agencies moving to SOA have found: It saved money in unexpected places – in this case because they were able to identify vacant properties and collect the higher taxes due on those properties. An important lesson for anybody migrating for SOA - regularly review you RoI model to ensure that you are picking up these unexpected benefits along your path to SOA.

D.C.'s experience echoes what I have seen happening in other US criminal justice organizations at state level and in the UK where the national Criminal Justice IT organization (CJIT) has been spearheading similar initiatives over the last few years.

For more details, the story is here for Wachovia and here for D.C.

Posted by rbradley in Enterprise Service Bus • Financial Services • Government | Permalink | Comments (0) | TrackBacks (0)

In the current issue of International Banking Systems , SAP’s SOA strategy for banking systems is covered in some detail.

The fact that it is SOA based would of itself not be that interesting except that in this case SAP is very much engaging with the customers, focusing on industry specific problems – the first phase involves 9 banks, all well known names such as Credit Suisse and Standard Bank – and are defining generic banking services. Generic in the sense that they cover capabilities that are required by any bank – say credit card payment processing.

The win for SAP is obvious – they can re-engineer and consolidation their many banking product lines in to a single SOA based framework of plug-together components (reducing on-going maintenance costs and complexity) and the components are being designed with help from their potential customers who will presumably buy what they have themselves designed.

The win for the banks depends on how generic these services are. I should point out that SAP are quoted in the article as claiming that the services are not necessarily SAP specific and approximately one third of the current crop are outside of the scope of SAP’s applications.

This is a great example of the huge amount of work that is going on turning SOA from concept into valuable reality - valuable to vendors and customers alike.

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