Embrace Plurality

Single system of record

One of the basic enterprise architecture patterns is the single system of Record. The idea is that any particular concept should originate in exactly one system, and that system will be the enterprise-wide authority on entities within that concept. The hard part is getting all parts of the enterprise to agree on what those concepts actually are.

Customer

Pick an important noun in your domain, and we’ll find a system that should manage every instance of that noun. Customer, order, account, payment, policy, patient, location, and so on. A noun looks simple. It fools us. Across our organization, we’ll collect several definitions of every noun. For example:

• A customer is a company with which we have a contractual relationship.

• A customer is someone entitled to call our support line.

• A customer is a person who owes us money or has paid us money in the past.

• A customer is someone we met at a trade show once that might buy something someday in the future.

So which is it? The truth is that a customer is all of these things. Bear with us for a minute while we get into some literary theory. Nouns break down. Being a customer isn’t the defining trait of a person or company. Nobody wakes up in the morning and says, “I’m happy to be a General Mills customer!” Instead, “customer” describes one facet of that entity. It’s about how our organization relates to that entity. To our sales team, a customer is someone who might someday sign another contract. To our support organization, a customer is someone who is allowed to raise a ticket. To our accounting group, a customer is defined by a commercial relationship. Each of those groups is interested in different attributes of the customer. Each applies a different life cycle to the idea of what a customer is. The support team doesn’t want its “search by name” results cluttered up with every prospect your sales team ever pursued. Even the question, “Who is allowed to create a customer instance?” will vary.