Blog article
See all stories »

Mobile and the SOA Silver Bullet

For several years I have blogged about how many banks continue to rely on legacy systems and how the latest proverbial straw never seems to break the camel’s back.

Now mobile payments and mobile banking looks like it will finally break through to the mainstream.

With Paym going live on April 29th, is mobile payments the final straw?

Although some organisations have embraced such developments as a driver for change to a more modern, open and flexible architectures, It seems that many others are relying on the silver bullet of an SOA wrapper or integration layer to paper over the cracks of their legacy history.

The difference between a true open and service based platform and an SOA wrapper may not be visible at the surface. However, to those who understand the work involved in trying to expose services from within the depths of a monolithic system and then orchestrating them to perform useful tasks - this is yet another maintenance headache in the making.

Is the SOA wrapper just another sticking plaster that further entrenches the legacy systems and holds back true customer focused innovation?

 

3745

Comments: (3)

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 15 April, 2014, 14:20Be the first to give this comment the thumbs up 0 likes

Yes. Yes. No.

Yes, SOA is a Band Aid.

Yes, SOA will entrench legacy systems. 

No, SOA is not a Band Aid on cancer. Legacy does not preclude innovation. While latest technology can't hurt, it's not a prerequisite for innovation, which can happen in many other forms viz. business model. As I've highlighted in Why Banks Can't Transform Legacy Applications - Part 2, banks have a decent track record with innovation with whatever panoply of systems they've been using. 

Paul Love
Paul Love - Konsentus - Nottingham 17 April, 2014, 07:20Be the first to give this comment the thumbs up 0 likes

Thanks for the comments Ketharaman.

My point was that a SOA Wrapper will tend fix the legacy system in aspic, and prevent further innovation in a legacy core, and limit it to "easier" changes in the peripheral systems that just work with the wrapper.

If the underlying core data structures and relationships are wrong then more and more work (and resulting complexity) is needed in the wrapper to support such innovation.

At some point these core card based data structures need to become customer centric to cope with the demands of mobile and omnichannel banking.

But we are still waiting for "the straw that breaks the cammel's back".

Ketharaman Swaminathan
Ketharaman Swaminathan - GTM360 Marketing Solutions - Pune 17 April, 2014, 16:54Be the first to give this comment the thumbs up 0 likes

@PaulL: Legacy has been around for around five decades if not longer. People have been trying - without much success - to get rid of it for at least a decade. I may be naive but I tend to think that there can't be anything wrong with something that has this kind of pedigree. Of course, there could be a lot of things suboptimal with legacy code in the context of mobile, omnichannel and things like that. But, I remember the same was said when phonebanking and netbanking entered the picture a decade or two ago. Those straws didn't break the legacy camel's back. Neither will these. Since one of the most powerful use cases of SOA is to hide the deficiencies of the underlying legacy application, why not consciously push the complexity to the SOA layer instead of tinkering with the legacy code? End of the day, I trust my bank with my money and I'm perfectly okay if it follows the old adage "don't fix it if it ain't broken".

Paul Love

Paul Love

VP Business Development

Konsentus

Member since

23 Jul 2009

Location

Nottingham

Blog posts

22

Comments

121

More from Paul

This post is from a series of posts in the group:

Innovation in Financial Services

A discussion of trends in innovation management within financial institutions, and the key processes, technology and cultural shifts driving innovation.


See all