Financial Services SOA Adoption Challenges
Wednesday, May 2nd, 2007This 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.
