Solution Architect – Enterprise Data Warehouse

Period:
05/16 - 07/18
Industry:
Banks
Project objective
Design and prototyping solution architecture for BCBS239 requirements
Project tasks
Solution architect, data architect, IT architect

Fresh back from a retreat in Brazil. The last project completed beforehand, I’m traveling to a new city with the task of conducting a two-day workshop on the implementation of BCBS239.

BCBS239 is a regulation of the Basel Committee on Banking Supervision and expects banks to consolidate their risk reporting and put it on a reliable footing. Many processes are still based on Excel and Access-supported models. In addition, the regulation expects banks to deal more intensively with responsibilities, governance and data quality.

During the workshop, I like my approach and am commissioned to design a scenario as a solution architect that fits the needs of this specialist bank and its culture.

We discuss an agile approach, something new for the company. We want to create usable value quickly. It is better to take a small misstep than to have to wait for benefits in long “waterfall cycles”.

I go through the various approaches with which I have already gained experience and research new ones. In the process, I come across “Data Vault 2.0”. I had already heard of Data Vault, but had not yet worked with it. So I call up some old contacts, ask for recommendations and realize that this is going to be “our” solution. You can find out more about Data Vault 2.0 here.

Up to now, the customer has hardly done any programming, working more with an extended workbench. Therefore, a part of the IT that a large banking service provider has built for the reporting system is integrated into the architecture and the service provider is commissioned to adapt the existing reporting data to the Data Vault structure. This saves costs, because the entire technicality of the solution is retained, we remain synchronized with the reporting system and compatible with other data recipients that should not yet be touched. That’s integration.

The whole thing is happening while I’m building a prototype with Talend Open Studio (more information here), which will get a good part of the data into a database and make it easier to use and analyze. This replaces the first piece of Excel processing and creates new possibilities, as much more data can now be found in one place.

A new service provider is found and comes on board. Experienced Talend enthusiasts build the data routes that are not taken into account by the reporting route mentioned above. Templates are set up to ensure that we can quickly integrate new sources and quickly create new evaluations.

We create additional benefits and visions “on the side”: The solution originally intended for a specific regulation can now also integrate an impairment calculator for IFRS. Data that we already have is also needed there. Further data that is used there will be needed later. Synergy and cost efficiency “in passing” (well, some effort was already required 😉 ). And if risk control, finance and reporting have already merged their data in a bank, the path to many other areas is short and simple.

The implementation of an “annoying” requirement suddenly becomes an enterprise data warehouse:

“Can’t we also integrate the new business pipeline?”
“Can we perhaps also integrate internet research on our customer engagements, something like big data?”
“Can this give us a 360-degree view of our company?”

Yes, all of this is possible with the chosen approach. And not because it was planned from the outset, but because the architecture is designed to be open and integration-oriented.

This approach takes place in a bank, but is completely independent of the sector.