I was reading an article on master data while pontificating on how to solve some issues at the office and ran across the old golden customer concept in master data. For those unfamiliar, one of the concepts in master data management is the idea that you should have a single source of truth for customer information. Because customer data enters into two systems, there should be a framework to reconcile those systems. For example, suppose we have two systems; system A lists me as Mike Butler with an SSN of 555-55-5555, and system B lists me as Michael Butler with an SSN of 123-45-6789. The golden record model should support a way to know which is correct, store that information, and allow other systems to update themselves from the golden record. Ideally, you create this with a process versus just a direct application of technology. A business process using technology that ensures creating a new customer always follows the same process regardless of the platform is an excellent way to enable golden records. This process allows the primary system to act as a data hub for customer data, which would ensure an accurate golden record. All work with a customer starts in one system and flows into other systems. This has been a key enabler of digital transformation, but it’s changing!
Digital transformation initiatives go beyond the essential record, though, and companies like Accenture view the evolution of golden records into gold profiles. You can find a link to that material at the end of this blog post. Golden profiles enhance the data from the golden record and contextual and insightful information beyond its predecessor. A golden profile can include click-streams, activities, usage data, third-party data, and other information. From a digital transformation perspective, the concept of these golden profile master records is critical to product design, machine learning models, and AI initiatives. The shift towards the golden profile would require a company looking to be more data-driven and, at the same time, have a product-focused way of running the company. Not all companies are at that stage in their transformation journeys.
The Golden Profile
Both these concepts are slightly utopian to me, but they can set the stage for how to set the guardrails for solutions in your company. The only problem with a monolithic golden anything, in my opinion, is as we federate and decouple solutions, the idea of a single source gets more difficult. Architecture models, product thinking, and good data governance design are critical. Another thing that I’ve had the pleasure of doing is when a company divests itself of a division or product, and sometimes decisions are made that keep entities separate. If you’re part of an M&A team, you might be behind the eight ball with your customer data model as well. I’ve also had many experiences with M&A, and you run into other challenges that merging data into a common source can take a while, and processes might not be set up to follow the model above to generate a new customer. Therefore, solution architecture patterns have to account for keeping customer profile data centrally accessible while at the same time supporting federating solutions and focused teams. These are some of the things that lead me down a journey of learning to be a practitioner; analyst/developer -> data -> analytics -> solutions architecture, -> enterprise architecture.
Ultimately, designing golden profiles for digital transformation requires a lot of executives to buy in to support a data strategy. Ideally, if you’re working with decoupling solutions, you’re building microservices that can interact with your conical records, like the golden customer profile. I’ll post some example solutions designs on customer API’s in some future articles. The key in this case would be to leverage AWS to scale out a microservice that can be the customer API and golden source. That was all customer records communicate back to the API, enriching the profile, and building on what the other applications can leverage.
Again, I understand the difficulty in this because not every solution you buy will be able to interact this way. Most of the articles you read will be centered around “if you’re building everything yourself”, and we know in enterprise IT that’s rare. Silicon Valley forgets that, but spend a few months in the IT trenches, and you’ll find that you’re mostly buying and rarely building. Although, I feel like if we could treat data like they treat spice in the Dune book by Frank Herbert, we could all find ways to ensure that “The data must flow” for the business. Easy, right?!