Tuesday, March 3, 2009

roll-out - SQL and XML

Wow. What a stir I caused when I put XML and SQL side by side! Thanks to all of your for your feedback.

Please correct me, but I believe there are two reasons for that interest: the first is simply that this is a novel and unusual idea. The second is that ISO 20022 being work in progress, the people involved in it are (quite rightly) protective about it.

The idea is not to run ISO 20022 down, nor to say that SQL is an alternative to XML. Saying that car A is good and putting it side by side with car B does not necessarily mean that car A is the same as car B, nor that car B is bad. In fact, the purpose is rather to contrast them, by which I mean, their initial similarities might then lead us to learn something interesting from their differences.

The crux is deployment or, to use Swift terminology, roll-out. And a model case I often think of, is precisely Swift, because they have been able to succesfully manage all these evolutions over the years -- my first arms were with USE/BKE, then I witnessed SwiftNet, and so on. The vast majority of these roll-out efforts have been fruitful and the ecosystem is still prospering (which was not granted either). No flattery intended here -- it is fact.

The reason why it has always worked out, despite the unavoidable grumblings here and there, is that Swift staff paid enough attention to what skills people had in the banks, what equipment was required, what training they needed and so on. They were always careful to provide a realistic roadmap to help any bank -- big or small, advanced or without in-house IT staff -- catch up and stay close. Everybody had to make it together, or nobody.

So, roll-out is not merely a technological proposition. It has to do with people, processes, systems and the environment. With constraints such as culture, capacity to accept change, cost, security policies, and how each tool fits into the balance of things.

That being said, let us get down-to-earth: suppose that today I want back office staff in my bank to be more effective in exchanging and processing interbank data. I want them to be able not only to make reports, but I want to empower them with something that will help them better exploit information from data feeds, fund administrators, back offices of other banks. They also must be able to provide data in the same way when requested.

And, since it is time of short budgets, they must be able to do it with whatever tool they already have on their desktops.

So I am going to train them.

Let us first check that they already know the part of FIN that relates to their job, because otherwise I would first send them to get trained by Swift. Since FIN is already deployed, that is a must.

Then what I am going to teach them? XML or SQL?
  • First XML: certainly, quite a few actors in the financial world are able to ship data in XML format. But what tool (that we already have) should I to teach my staff in order to exploit it? How to write an XSL stylesheet for their browser ? Programming javascript and the DOM model, in the browser? vbScript from the command line? And when that is done, how do we criss-cross that with other data get it into a usable report ? Let us face it: XML is complex for non programmers and, for now, should better be left to IT departments. I do hope that this will change,with user-friendly tools, but that is not possible yet.
  • With SQL, by contrast, I know with certainty that I can give two or three half-days of training and already get a significant increase in productivity. I know that if I teach them some Access, they will be able to import Excel and CSV files from their brokers, custodians or correspondents, mix all that and produce useful reports. Those who already create Excel macros will make good candidates.

Soon, the "rest of us" start to naturally exchange data using mdb files (preferably from a network disk), or through e-mail if necessary. And after a while, querying "serious" databases like SQL Server or Oracle,with Access,and exporting that to Excel becomes a normal thing.

The interesting part, is that SQL is not really the enemy of XML. Because then, back offices can work out ways to import XML data into their home-made relational databases and exploit it. That could even help them accept it.

Perhaps spreading the knowledge of SQL into back offices might even help pave the way for ISO 20022!



Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com