Data is not an IT problem. Data is a business problem.
Business is the dog and IT is the tail. Sure it is, you might say, but do things work the right way in your shop? I bet not.
Experience from the University of Life (First Class Honours) and the School of Hard Knocks (Summa Cum Laude) tells me that in most financial services (FS) places, more often than not you will find that the dog and the tail are mis-aligned.
Building great processes and sorting out the data quality you need as a foundation for them are business problems and require business vision and leadership. So often though IT end up dominating change projects. Why?
The FS business is built on IT and needs it to survive; we have a lot of it, it is always beset with legacy aka technical debt issues and there are multiple degrees of complexity caused by having your own custom built stuff mixed in with standard vendor packages and a goodly dollop of outsourcing.
That said, IT is not business. I am indebted to an old colleague, Nik Mueller of Credit Suisse for hitting the nail on the head over a recent afternoon beer: “It used to be that if I had a business challenge, either fixing something or doing something new, I could pull a couple of folks into a meeting room, draw a few pictures and figure it out. Not anymore; that same knowledge and understanding is spread out amongst 10 or more folks, with no one of them having an overall picture of the ecosystem.”
Of course in the Credit Suisse case, there is the extra burden that the never ending re-organisations have 99.99% ensured that knowledge and interest have moved on, either to other parts of CS or out of the organisation.
Deadlines and the must do projects are still there, while at the same time, change has become harder and harder. Business folk often find it hard to really master enough technical detail to impose themselves on IT. As soon as business let’s go the leadership reins, with the deadlines not moving, IT will often be left to fill the vacuum. IT ends up having to lead, because the deadlines are still there and they have the most knowledge.
Another ill is the proliferation of IT architects of one flavour or another; a recent experience suggests that if you lay all the IT architects in an organisation end-to-end, you still won’t reach a conclusion.
Lessons to be Learned
With all due respect to my learned and wise friends on the IT side of the FS organisations; when the IT tail wags and leads the business dog, this is more likely to go wrong than right.
On the specific subject of data, with the move to data lakes to drive big data, the need for leadership means that a business owner for Group Data has to be identified and put clearly in charge.
The Group function has to then allocate responsibility for data to data owners; this might be by domain. Those domain owners then need to be tasked with delivering the data centrally; they should simply be commanded to share the data. Individual consumers of data should not have to deal with each domain owner and ask for approval for every use of data.
As far as the group data solution goes, the Enterprise and Solution Architects need to be at group level, not in the domains or businesses. The approval process for new and changed implementations also has to be Group owned.
Once the data is in the central, federal data lake, it needs to be subjected to data quality assurance. That requires tying out terms or fields in input feeds to a common taxonomy or catalogue and then writing rules for each common term.
The group function has to ensure data is delivered, inputs are mapped to common terms and that domains then deal with data quality exceptions. That group function may allow some variation in tool used, but it should not allow the domains to set out the process for quality assurance.
There needs to be one tool and one process for reporting on exceptions and having the domain owners supporting the fixing of all those issues. The Group Function directs and the domains do.
My description of this would be that a “benign dictatorship” is required of the Group Function. Now sometimes, benign won’t work; individual domains will want to approve every use of data, old silo based forums in IT will debate at length about tools. They all need to be cut off and down to size at the first opportunity; worst case, drop the benign and focus on dictatorship.
It is at this point, that all would do well to heed the words of the late Margaret Thatcher on consensus:
About the Author: I help banks master their post trade processing; optimising, re-engineering, building.
I understand the front-to-back and end-to-end impact of what banks do. That allows me to build the best processes for my clients; ones that deliver on the three key dimensions of Operations: control, capacity and cost.
Previous Posts
Are available on the 3C Advisory website, click here.
Publications
The Bankers’ Plumber’s Handbook
Control in banks. How to do operations properly.
For some in the FS world, it is too late. For most, understanding how to make things work properly is a good investment of their time.
My book tries to make it easy for you and includes a collection of real life, true stories from nearly 30 years of adventures in banking around the world. True tales of Goldman Sachs and collecting money from the mob, losing $2m of the partners’ money and still keeping my job and keeping an eye on traders with evil intentions.
So you might like the tool kit, you might like the stories or you might only like the glossary, which one of my friends kindly said was worth the price of the book on its own. Or, you might like all of it.
Go ahead, get your copy!
Hard Copy via Create Space: Click here
Kindle version and hard copy via Amazon: Click here
Cash & Liquidity Management
An up to date view of the latest issues and how BCBS guidance that came into force from Jan 1 2015 will affect this area of banking. Kindle and hard copy.
Hard Copy via Create Space: Click here
Amazon UK: Click here
Amazon US: Click Here
Share on:
