Data Architecture Archaeology

Is your Data Architecture more like Data Archaeology?

When preparing your next strategy where will you be pulling your data from? Does your business have a single repository that you can be certain is the only place that data can be? Or, like many – perhaps even most – trading institutions, are you faced with the complex, often painful task of digging around hundreds of dark corners, doing your best Indiana Jones impression, trying to uncover that one vital missing piece like a diamond in the rough?

Sick of making his teams play treasure hunter, Colin Gibson runs the small data architecture team within the markets and international banking divisions at RBS and has spearheaded a project to create a one-stop repository for all market reference data, all perfectly indexed and tagged, that takes the mining out of data mining and lets RBS employees spend more time creating and executing the strategy and less time digging for clues.

FIMA spoke with Colin to find out more about the project and share his key findings and successes…

Download Full Interview Transcript

Transcript:

Interviewer: You spoke earlier about data architecture or perhaps deliberately not about architecture in some ways! Perhaps you could tell us a bit more about this.

Colin Gibson: Yes, it’s more about archaeology than architecture. What it was drawing attention to is a common practice in our firm and in the industry. When people start new projects they spend a lot of time digging around, trying to find the information that should have been left behind by old projects. We’ve been doing something about that, trying to actually provide a place for people to put their information, so that that’s the first place that you should look when you’re trying to understand the data for your new project.

Interviewer: So perhaps if you could give us a little bit more detail about your approach to making that data more accessible?

Colin Gibson: So first of all is understanding what people need to know. So we looked at the end to end problem, we said “People need to know the requirements for data. They need to know where you should source it from, they need to know where it can be stored or should be stored. They need to tie the whole thing together with knowing what it means.” That’s really the key to this, it’s actually for all of those different aspects of data having a common language in the middle that tells you what it means. So we have developed a store for that information.

We could use any tool for it really, but we use a particular tool just to hold it. More importantly it’s how we structure that and the way that we’re able to hold those requirements separately. The messaging information, the storage information and tie it all together with a lingua franca or Esperanto in the middle, which is the logical model.

Interviewer: Did you then see this more as a technology project or is this more of an institutional project, trying to change the way in which people access that technology?

Colin Gibson: It’s definitely not a pure technology project. So the people who need this information are as much business analysts who might be in a business change function as much as they’re in a technology department. It’s for the benefit of change projects. Those projects do generally involve technology and actually the people who craft some of the information of the stores and the messages are definitely technologists. But the thing in the middle, the logical model is technology agnostic, application agnostic, and that’s meant to be in business speak. It’s an explanation of what the business’s data means and why it’s important.

Interviewer: How long has it taken to go from the initial idea through to where we are now?

Colin Gibson: We started seriously about two years ago. We had some previous germ of a model that we started with. We’ve been building out the information around it for about two and a half years now. Still some way to go, and still some way to go in terms of getting people referring to it and using it as much as we would like them to do. But we’ve got to a reasonable place, we just need to take it a bit further.

Interviewer: So would you say that’s a sort of your biggest challenge for the future then, is it encouraging the usage?

Colin Gibson: There is definitely a communications challenge with this. You always have to keep drip feeding people to say “Use this, use this, use this.” At some point we may be able to start mandating that a little bit more than we historically have, but it’s a little bit about encouraging people to do it as well. If they know it’s there, they will be silly not to use it, and if they’re creating this information and they would be short sighted not to put their information there.

Interviewer: So if you were starting out in that project now, or rather doing it a second time over, what would you say were the biggest lessons that you learnt from the first iteration?

Colin Gibson: That’s a good question. I guess probably getting more high profile cases where people are using it, and using those as case studies. Because I think people in the business areas can relate more to something else that has happened in their area rather than something that’s happened in a different area. So actually maybe having a network of champions to help do the selling of this, and having more real examples, we could have done a bit more on earlier.

Download Full Interview Transcript