Capping IT Off

Capping IT Off

Opinions expressed on this blog reflect the writer’s views and not the position of the Capgemini Group

MDM: Big Central Customer Hubs are an invitation to steal

IT Departments like databases, they like databases in the way that Marilyn Monroe liked diamonds and what IT Departments seem to firmly believe is that BIG is better in the world of databases. In MDM this database centric view tends to translate into a focus on MDM solutions that are euphemistically called "Hubs" with MDM solutions that don't contain all of the information about a customer in a single Database relegated to being "simply" a "Registry" and some how worse. This mindset is wrong for several reasons, which I'll cover in subsequent posts, but the first reason that its wrong is around information security. Putting all your data in a single central store and then wiring that central store into your website, often with companies using the "synchronisation" approach to get a "more performant" solution means that suddenly everything about your customer is one data breach away from being public. Big databases are simple to steal, once your security is breached. Big databases are nice and central and in effect by compromising the single machine they have now lifted your entire customer database. Federating information so only core information which is actually required at the edge is synchronised and then providing a performance SOA solution (possibly using REST if you are of that sort of information integration bent) with a full authenticated security model then makes it significantly harder to actually steal valuable information. Lets take Credit Card information for starters, why store that in an MDM hub? Certainly why store it and then sync it to the edge. Why not have a Credit Card processing service which contains A User ID which links, via the MDM hub, to an individual The Credit Card details, encrypted Then when a transaction occurs the Web Site can send a request to the CC processing service providing the security code and the ID and the CC service then goes to the MDM solution to get the customers information. To steal information here would require access to multiple machines, the Web site, the MDM solution and the CC service. Performance isn't critical here as we are talking about transactions measured in tens of seconds so a little extra latency due to calls isn't going to materially impact the customer experience. The same goes for lots of other customer information. The Registry model is in fact the right way to go from a data privacy perspective as you can provide graded data privacy enforced based on access to a service rather than having to implement complex data access rules in a central solution. Elements such as data maintenance and system maintenance become more secure as people only have access to the information required within that service and not to everything available about the customer. Unified views are therefore created from the federated data with the policies able to be enforced where the data resides. This means that a policy change, for example the new billing address of a divorced customer being unavailable to a previous joint account holder, can be enforced within the SOA information aggregation layer and enabled via MDM rather than MDM having to understand all of the data privacy rules that exist. Registry MDM is the reality of good MDM, its harder to do well and it requires an IT department with a clear vision of how it aggregates operational information rather than just having a database landfill site into which all information is dumped. Losing the information at the edge is bad, losing a registry MDM database is very bad but losing a Customer Hub MDM database is potentially business ending. Federation makes a better, more secure approach to Customer information, it just means you have to plan more.

About the author


Leave a comment

Your email address will not be published. Required fields are marked *.