Single view of Customer from Distributed Software: Part I

Customers are at the heart of every business model and industry. It is therefore no surprise that throughout my journey as a consultant I have witnessed initiatives eventually lead to one trying to get a single, unified view of the customers at they appear in various IT systems

The challenge is when technology implementations focus on core business domains such as “core banking”, “core claim”, “core accounting” etc., the focus on Customer Relationship Management (CRM) domain is missing or not explicit. This leads to an implicit implementation of CRM capability making it a generic domain vs a core or supporting domain

What does this mean then? Simply put, we either have a fragmented view of our customers or we have a CRM but no single-view i.e. there are duplicate customer details and that implies data issues

Definitions

Let us define some language before we go any deeper

• Single view of customer: We have 1 copy of the information record of a Customer across all our systems, regardless of how many systems the customer interacts with or addition / removal of systems
• Customer: Someone who has a special business relationship with our org and we need to manage or support
• Customer 360: While single view was customer across all systems, 360 is the customer and their relationships in all systems. What are their related business entities and values?
• Contact: Depends on the context! There is a polysemy in this word and we need to use DDD to find which bounded context is this contact in to define it. So Customer Contact is not the same as a Claim Contact or a Debtor Contact. Depending on the context – Customer management, Claim management or Invoice management the attributes change
• CRM: Customer Relationship Management (CRM) is the act of supporting your customer as they interact with your business. This is such a common thing for businesses to do that this has become a generic domain i.e. businesses can buy a CRM software vs building and specialising on their own

So 

Now that we have the words and the problem context we should be asking a few key design questions and looking at what this problem needs for the best solution

 

• Why do off-the-shelf CRM software not auto-magically do single view of the customer? Because we have many systems and the customer can interact and be managed in any
• What strategies should we use for a Single View? Our options are single giant monolithic address book, distributed address books but single view, distributed systems but one master book etc
• How do we build integrations to avoid duplicate data in the customer context?
• How do we maintain de-coupled concerns but single view as we add new software systems to our eco-system through mergers (M&A)?
• What design patterns allow for a single view of Customer in our software in a distributed business-software model?

These questions and more should lead to a set of desired software quality attributes for this problem. I come back to these attributes because software design and architecture is a process of compromise within constrains – you cannot have it all

For example, a highly consistent single view of customer would be to have 1 table which various software teams read/write to. While this provides consistency and a single view, it fails to be extensible, autonomous etc due to the coupling at the database. Thus, this is a great pattern for a small business but may pose problems as the organisation grows

Solution Quality Attributes: What are important to a good Single View of Customer solution?

Let us then see what attributes are key for this solution. A single view of the customer needs the follow:

Ability to provide a single view of our customer as they interact with various aspects of our software

We prefer this view be real-time consistent but delayed or eventual consistency is okay as long as we do not have duplicate copies of this customer information, especially when they interact with us or we with them

Ability to distinguish and transition casual contacts in our system to customers. We would like to manage, and therefore need a single view, only for our customers. There may be general contacts within our systems who are not yet our customers, which is OK

So when we mean “Our customers” have a core set of attributes we need in the customer management context. So ability to view core unique attributes of a customer, compare with another and resolve duplicates

Ability to add new systems without impacting the view and instead enriching the view in a Customer 360

Next post: Designing the solution from Options, Patterns and Anti-Patterns

In the next post we will look at some of the options available for designing systems to evaluate how they meet the needs (quality attributes) for a single view of the customer

What design patterns and anti-patterns are out there in the wild? How can we recognise where we are today and how do move towards realising a single view of customer?

Read the second post here