Single view of Customer from Distributed Software: Part II


In the previous post we discussed how to identify some of the challenges around a single view of the customer. In this post we look at some of the ways we manage customer contacts in the enterprise systems and relate them to Domain Driven Design context mapping

Single vs Silo’d view of the customer

Patterns

1. Separate ways: We all have our address books

  • Does not provide a natural way to get the single view of customer
  • Fragmented but autonomous
Context map: Each system builds it own view of the customer, they way they see it. Partial, fragmented view of Customer

Systems view with contexts, silo’s everywhere

2. Shared Kernel: One giant address book

  • Monolithic database for customer management
  • Can provide a single view of customer
  • Downside are the complex rules from all the domains applying to a single table
  • Downside is also the loss in autonomy
Context Map of a shared kernel customer pattern
The system view of the single monolith at the centre of the shared kernel pattern

3. The anemic Customer API: CRM system as the monolith

In this pattern all systems store their attributes into the CRM via a Customer API. CRM has the single view of the customer and the “account” / “contact” tables are extended to hold details from contexts outside of customer management only (e.g. Policy management, Document management etc)

The Customer API is no longer a vehicle for self-service, because the table behind is collaboratively maintained by all the teams. This reduces to the pattern #2 above, making CRM system a monolith

  • This pattern provides a single view in customer management context
  • But can impede business transactions in other contexts
  • It feels like an open host service and hence autonomy, but it hides the painful reality of a bloated CRM
  • Attributes copied from other systems lead to implicit integration challenges
Context map for the anemic API: Notice this is a SK not an OHS and the Customer / Supplier relationship

Implementation view shows another danger of this pattern – these single master as a monolith needs to be checked with in real-time by all systems when mutating information which has relation to a customer. Imagine not being able to buy a policy because the contact validation rule in the Customer API or backend database prevented you from creating a new contact

4. The 360 pattern:

The next time we will discuss pattern #4 which is a good mix of maintaining a view and being decoupled

Summary

We looked at 3 patterns for managing customer related information across our systems and examined how well they did in providing a single-view of the customer, challenges in maintaining them etc

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s