Banking, Integration Architectures and Customer Data Ownership

Gartner Analyst Alistair Newton raised data ownership as one of the new main concerns for CIOs in the Banking industry. His view ecompasses handing value-added data back to the Customer for re-use on other related services. Banks need to be managing data internally in a way that the customer can access and update the part that he/she knows best about, like Name and Address for example.
This imposes demands on a banks ‘Single View of Customer’. More importantly it demands (the right!) MDM, Data Quality and Integration Architecture.
In this article we will explore different types of Integration Architectures and come up with a best fit for purpose.

A New Paradigm

“Customer Own Their Data” is quite remarkable considering the MDM and Data Quality discussions in recent years. Not everyone was convinced a MDM project is necessary at all. A lot of focus was put on Functional Integration (i.e. Services/SOA), less so on true Data Integration (MDM/DQ).

For us Customers to own our data makes sense. If my name is ‘Andreas’ but I want to be called ‘Andi’ – from a Customers perspective the bank should comply with that wish. If you then look at the systems landscape inside of large enterprises only few seem to be ready to satisfy a simple wish like this. And the reasons for this are plentyful:

• Failing or incomplete SOA projects
• New data aggregation applications (e.g. web portals) are built, instead of integrating the data backends
• IT projects overrun in time and budget
• Business and IT run as disconnected entities

So?

Firstly, all the systems which require Customer data need to use the same data records of the entities, which are owned and maintained by the customer.

Why? Because, if I change my name now from ‘Andreas’ to ‘Andi’ through the Online banking interface, I’d like to see that change on my next account statement, too.

In order to do so, we need either

1. Shared Data or
2. Data Update Notifications

It is important to note that a central MDM Master is now becoming the MDM slave for the Customer owned entities (like Name and Address for example). Those MDM entities are now ‘mastered’ by the Internet Banking system.

‘Shared Data’ means there shouldn’t any Customer data, except a global identifier, be lying around anywhere else. An MDM master can be such a data repository, but making all the legacy systems using the MDM master is a whole different story.

‘Data Update Notification’ means I am receiving a notification that Customer data has been updated.
Best Practice is to send the whole updated record around instead of just the identifier. This is to save the unnecessary overhead of subsequent getCustomerData requests from all insterested systems.

This is what it means for systems to use the same Customer data. And it is where an Enterprise Architect should start to think about scalability.

Scalability

In a purist SOA/ESB way we would create a single service to set&get the latest and greatest customer data. This service would ideally be unique across the whole enterprise. The peek&idle load of those service calls from all enterprise wide service consumers would be hard to predict and you could end up with the data repository access as the bottle neck. Sure caching is an option, but then you need to think about cache location, cache-size, examine cache hit and miss counts and cache-invalidation strategies. And I’d argue then that this is not part of the core problems you should spend a large portion of your thinking on, when solving your Enterprise Integration challenges.

Remember, aim is to make the Account Statement System print ‘Andi’ instead of ‘Andreas’. If the system, which the Account Statement System uses to get the latest Customer data, is down during my update, the service call and hence my name update will never make it onto my statement. Best case senario is that I will get an error message like “Dear Valued Customer, Due to an Internal Error the requested operation cannot be completed. Please try again later”. It should perhaps read “Due to the wrong Enterprise Integration Architecture the request cannot be completed.”

Solution Architecture

How about sending a ‘Customer Details Updated’ notification to all systems that hold/store my customer data? There will be only one notification per Customer update, no unmanageable sub-sequent service call load, caching has become unnecessary and if a system is down the message will be delivered through a queue whenever the system comes back online

The thinking behind these two Solution Architecture approaches  are quite different. The SOA approach is based on the ACID paradigm whereas the EDA (Event Driven Architecture) approach is based on BASE. In case you want a refresher, Werner Vogel (Amazon CTO) has written a great article on that topic.
The ACID approach is perfectly valid in a non-distributed Application architecture, on an Enterprise Integration Architecture level things change.

Ready to hand the data- ownership over to the customer?

It seems as if the new way to go is to hand data-ownership over to customers. Customers should be happy and CIOs have to worry less about the Match&Merge step withing their MDM and Data Quality projects, at least for the Customer owned entities. However, as shown above, it is still paramount for CIOs to get the Enterprise Integration right first – and that is nothing new.

What’s your view?

Andreas Spanner