I came across two articles on SOA recently. One was from Accenture here and the other one was the transcript of a panel of BriefingsDirect SOA Insights Edition regulars and guests at the recent the Open Group's Enterprise Architecture Practitioners Conference in Austin, Texas. Now I am not a technologist or have a development background although have used technology for a long time now. So when I read about Service Oriented Architecture, I get puzzled because it seems to be something for everybody. My architects would get very excited about it, and I have seen earnest faces talking about inter-operability, messaging, integration, seamless upgrades, and and and. I have also listened to so many consultants (and have done so myself! :)) about how SOA architecture is the bee's knees and will reduce/remove my IT work, budgets, etc. etc. I remember the similar hype about middleware in the middle 1990's, then the internet 1.0, the HTML (and its variants), and so on and so forth. This even went forward to pose a challenge to SWIFT and FIX, where are we now? both are still alive. So be careful of the hype.
But I am afraid when looked at this from the cold light of day from a business perspective in a financial institution, then the lacunae emerge. While I am sure this is useful, but some comments would help in grounding the debate when faced with a budget request for SOA.
1. If you do have a legacy big hulking system and it has started creaking, you have a choice to either go for a big bang or slow. Personally speaking, until and unless somebody holds a gun to your head, I prefer to have a phased approach. Remember sewer lines? that's how IT need to be, be invisible, slow, steady and less risky. Within this, you have a choice to either replace the entire big hairy box with a vendor system or build your own. Chances are that you have already outsourced your application support and maintenance to a vendor. So call them in and ask for a joint task force to come up with 4 options, each to be based upon a risk sharing basis (the vendor and you share the risks and benefits). So this can build out from inside out, or start carving from outside in, full replacement, or modularise. Or variants of this.
2. In a financial institution, it is very rare for the CEO to get involved in decisions like this, you will most probably go talk to the COO or the MD of the trading/functional area. But for heaven's sake, dont natter on about SOA and stuff like that. Talk to him in terms of operational risk and the capital at risk. (of course, you will have the odd MD who is technically literate or in the areas of programme trading, electronic trading and to a lesser extent, in the structured products arena - then you can natter on to your heart's content, lucky sod, budget will be his problem, not yours!).
3. If you are an MD, ask your technology director to put his money where his mouth is and aim to tie his next 2 bonus rounds to the level of operational risk relating to IT and the upgrades (and add things like audit points, error rates, cost per transaction, etc.). In return, you have to pony up what he wants AND support him because problems will arise. So if he wants to do SOA and all that nice stuff, that's fine, but remember he is an architect/builder of your house. You have to live in the house that he designs and builds. At the end of the day, he will nip off to his house and you will have the house that he has designed and built. So work very closely with him.
4. Inter-operability turf wars are huge, you can get into a situation that you end up fighting a huge number of people. Let me give you an example. Most of the Debt and Equity trading departments started merging from 2002 onwards and now the pressure is high to start merging the underlying technology as well. MiFID will require consistent cross product transaction/trade reporting. Confirmations will require consistency. Why have separate SWIFT gateways and upstream boxes? These situations (and very very curiously, regulatory pressures) seem to bring all these new fangled concepts bubbling up to the top and the consultants salivating at the thought of a big product/process replacement or a big integration effort.
Instead of going for the big bang, ask for a small proof of concept study, to be funded out of your own pocket, with the smallest element that can be common. So you can have say the payment messages from both the debt and equity side as common and the PoC study hits this bit. Or the external connectivity boxes, or the trade reporting piece. And in the PoC, be specific about who are the other people who will need to be involved. You will see the politics inherent in the situation. With the huge amount of automation underway, you dont hit the politics till you have to pay for it or when the technology fails. In both cases, its bloody painful and if you are a business person, it detracts from your revenue generating efforts.
More painful is that given the flat management structures, the only person who might resolve this could well be the head of the investment bank who will think the heads of equities and debt are a bunch of whining gits! Keep it small, have 1-2-1 with your opposite number, and roll it out slowly.
5. See the examples quoted in the Accenture presentation, did you notice the inconsistency? On one hand, SOA is supposed to stop big mega IT projects. Take a look at the 3 examples which they quote from the healthcare, airline and telecommunications industry. Which project is NOT a big hairy mega gigantic bet-the-company project? So just how is SOA supposed to remove the need for big mega IT project? So be very careful whenever anybody talks about these hyped concepts.
6. See the panel discussion, it is mostly all up in the air. One interesting comment was how IT departments are moving from a project to a process orientation. That orientation has been in place in financial institutions for decades now, we still tinker around the edges but you still have funding, organisation, governance, risk tracking, etc. along the lines of product and process silo's.
But this is a view from the business. What do you technologists think?
All this to be taken with a grain of piquant salt!!!
No comments:
Post a Comment