Tuesday, 21 May 2013
Putting customer master data in the Cloud
By David Taber, CIO.com | Jul 3, 2012
0 comments
Digg
PrintIn distributed business systems, we have the messiest of plot complications-there's no source of truth for who all our customers are. Accounting has one version, distribution may have another and CRM may have a third. This problem multiplies with international divisions, global customers, and business units that were the result of mergers and acquisitions.
The more distributed your systems are, the more likely you have this problem. I have one client that is endlessly creating hundreds of dupe account records every day because it has more than 75 systems, each of which thinks it owns the definition of accounts.
If you are lucky enough to already have an ESB and customer master database, and everyone's already using them, congratulations. The other 99.9 percent of you should read on.
Deus Ex Machina: A Loosely Coupled Solution to Loosely Coupled Data
The problem comes from loosely coupled systems. However, the solution strategy can come from the ultimate loosely coupled system-cloud computing. Let me explain.
Analysis: CRM Systems: Unite or Die?
If business rules (and politics) support it, you could create a customer master database as a cloud service. The process of setting up that service isn't that much different from the good old days of database; after all, you're just using a more ubiquitous set of protocols. Remember, traditional customer masters typically become boil-the-ocean projects for political and data quality reasons, not because of technical issues.
A different approach is to choose a cloud application, rather than a centralized database, to be responsible for the customer master. The knee-jerk choice for that central (cloud) application is accounting. While that system will typically have very good data quality, let's not jump to a conclusion just yet.
For an application to be a suitable customer master repository, its infrastructure must:
- Be accessible, calling in and out from everywhere in the enterprise with SOAP and RESTful APIs.
- Be extensible, handling extra fields that act as foreign keys for every other applications' use, as well as extra text fields to handle multiple versions of the account name, such as A&P vs. The Great Atlantic and Pacific Tea Company, as well as other key parameters.
- Handle different categories of accounts, including direct, partner, prospective and inactive.
- Handle foreign character sets and multiple address formats.
- Scale to the number of accounts and peak load update rates at reasonable cost.
- Provide secure access rights and update privileges for each class of account and user, with the ability to encrypt sensitive data as needed.
- Host code to operate on account data in support of transformation, workflow, data hygiene and other functions.
- Be reliable and available at least 24 hours a day, six days a week, with auto-retries when other parts of your infrastructure are not responding.
Add comment
Recent popular content
Most Read
HR consultant Gemini Personnel employs data protection and disaster recovery solution from FalconStor
BYOD and ITSM: What you need to know
Understanding hypervisor-based disaster recovery
A little security for Big Data
Survey highlights growing market for and proven benefits of deduplication in production environments
Recent popular content
Most Read
HR consultant Gemini Personnel employs data protection and disaster recovery solution from FalconStor
BYOD and ITSM: What you need to know
Understanding hypervisor-based disaster recovery
A little security for Big Data
Survey highlights growing market for and proven benefits of deduplication in production environments
