Financial Services SOA Adoption Challenges
This week in the April 30 InformationWeek publication there was short couple of paragraphs under the heading “SOA: A Warning Shot”. The short article reports that financial services firms that have implemented SOA’s are “… finding that they can be more expensive, less reliable, and harder to maintain than standalone applications” (quoting Sajay Sethunath, chief architect for BearingPoint’s financial services consulting business. From the article:
“His conclusions should be a warning to other industries. IT departments tend to pick the low-hanging fruit and build services that they know will be reused by several applications, he says. But too often they haven’t established a metric to show how the effort leads to savings. What’s worse, Sethunath says, many of the services aren’t even what business users want.”
I work with financial services firms every day, and know many CIO’s and CTO’s in the industry personally. I can say with confidence, there is truth to Sajay’s comments. Some are indeed struggling with early implementations of SOA’s. I know of IT organizations in financial services that have made meaningful progress, although many are in early stages without the skills and knowledge to build a complete SOA infrastructure.
Research done by the Aberdeen Group says that cost-savings remains the biggest lure of SOA. But regardless of where the IT organization is in the SOA implementation, the big payoff though is a ways out. The analyst at the Aberdeen Group gathered data from over a thousand companies, and the report basically concluded that if 2005 was the year of SOA romance, the honeymoon was over by the end of 2006, in other words reality is setting in.
SOA’s are valid and worthwhile for any financial services IT organization, but the reality is that they require a systemic change in architecture and process. SOA’s are very complex. After seeing successes and failures win lots of organizations, many of the key glitches are becoming clear, they are:
-
Don’t underestimate the power and usefulness of the right tools, like a flexible and extensible registry to manage services, policy servers and collaboration wikis.
-
Quality, quality, quality. Because distributed components loose the benefit of an all-seeing and all-knowing compiler, there isn’t a quick “syntax error” message you’ll get when a disparate service is consumed for the first time in a unique composite application. The registration process of any service needs to include comprehensive testing and certification.
-
Follow popular standards and create your own where they don’t exist.
-
Pick the right people, the right skill sets. People that can see and understand the end from the beginning, but can also manage daily tactics of what needs to be done to get there, (Steven R. Covey’s famous book “7 Lessons of Highly Successful People” defines who the right people are to build an SOA as far as I’m concerned).
-
Understand and define what business issues exist that can benefit from the SOA. Keep that definition in mind throughout the process, in particular when things start to get off track.
-
Set realistic expectations. The big payoff may take a while to realize, so the value needs to be understood in a temporal context.
No pain, no gain. Nothing worthwhile is every easy, so don’t lose heart. It’s the right architecture and process that can today’s business challenges. Think of it as a journey, not a destination.
May 7th, 2007 at 1:00 pm
Not a surprise, given the mad rush to get on the SOA band-wagon, primarily fueled by software vendors. There has not been a week when I do not get a phone call from a software vendor enquiring about our “SOA Strategy”. My answer to them is - “We do not have an SOA strategy. We have a business strategy and a technology map to meet it. SOA may be one of the components of our technology map”. We have enjoyed the success of SOA by very carefully planning and implementing it in areas where it makes most sense, for example for interfacing with our Dealer’s business systems.
-Ashish Raghute
Director of Technology
IT Department
Fleetwood Enterprises, Inc.
May 8th, 2007 at 9:30 pm
[…] Darren Wesemann Blog Darren Wesemann on SunGard Technology Home | « Financial Services SOA Adoption Challenges […]
June 13th, 2007 at 10:46 pm
That is too correct in many ways. Per-service level ROI, achieving the real isolated nature of the service (so as to let future composite apps fully leverage the underneath stuff), the performance penalty and no guaranteed metrics; ooof - there are dozens of (mostly) hidden problems in a Financial Services company truly benefiting out of SOA.
With that being said, no harm nor low-opinion intended on SOA and I personally like services from years past and to come.
Ashwin
www.bfsiforums.com - An Online Community for Banking, Financial Services and Insurance industry.
July 5th, 2007 at 12:52 pm
Agreed on challenges of adoption. I would posit though that Sungard focuses on FS firms that are leading edge tech adopters. As a result, the leading edge is a constantly evolving one, with many practioners rolling their own to achieve competitive differentiation. “Standardization” flies in the face of that differentiation as it lowers or eliminates the competitive (and cost) barriers.
Service process standardization is the holy grail, and not one pursued lightly. Firms that can afford the discipline (yes, that’s not a typo) will achieve the benefits. But it’ll take a bit. And probably require a mindset change in management and developers (and users) alike. Perhaps creating an expense model that works along a consumption model (SaaS) would help defray the investment?
December 10th, 2007 at 10:38 am
I hear what you are saying. Capnetix is a new vendor that is building new solutions to old problems for the financial industry. We are interested in the phrase…”Follow popular standards and create your own where they don’t exist.”.
We are working in the area of pooled fund administration, and don’t want to reinvent the wheel for things like creating new participants, adding accounts for participants to trade in funds, adding trades, getting NAVs etc. We can write our own services, but if there are standard definitions of these, we would prefer to conform to them, to lower integration costs later. We see our offering as something that can both serve as a stand alone app, AND ALSO work as part of a larger SOA architecture. Designed and built that way from the beginning keeps our costs low, and gives customers flexibility to plug our component into a larger architecture.
Charlie Peppler
cpeppler@capnetix.com