In DDD terms a shared kernel is a form of relationship between two or more bounded contexts.

Shared Kernels from Evans DDD book

I believe these shared kernels are more common in old and central areas of the business. One reason is that companies grow and create new functions while keeping the old functionality running. There are more incentives to allocate people to the new things and less people to maintain the existing things.

As the old is less cared for, employee attrition disproportionally affects more as the knowledge goes with them, and new people does not come with the old knowledge.

If this premise is correct, as companies get bigger the shared kernels become more abandoned. They become what the new teams need of them. And each team needs slightly different things, so new interpretations of the kernel appear.

I understand that different parts of the system use subsets of the entity for their processing. I don’t know if projection is the right term for it (as used in this article by Serge Semenov), but I will use to describe these subsets of functionality inspired by the original kernel.

So here is my thesis:

The core shared kernel becomes loose, and the interpretations of this bounded context substitute the original kernel. It becomes hollow.

Each dependent team deals with both the way to query the original kernel entities and uses their own ways of reading them (projections) or writing them. This process is gradual and hard to roll back as the new interpretations of this shared kernel are not shared beyond their original inspiration.

Hollow kernels

Homonyms arise. As the amount of work to merge and resucitate the original kernel gets bigger, new teams show no interest to fix the situation but reduce the impact of the disagreements, increasing complexity.

As the ubiqutous language degrades, the only real solution is to assign a team with the job of unifying them and restore a more healthy dynamic between teams after that.

This is what Eric Evans has to say in the Domain Driven Design book:

Uncoordinated teams working on closely related applications can go racing forward for a while, but what they produce may not fit together. They can end up spending more on translation layers and retrofitting than they would have on CONTINUOUS INTEGRATION in the first place, meanwhile duplicating effort and losing the benefits of a common UBIQUITOUS LANGUAGE.

Later on Eric Evans suggests to designate ownership for a team and have a customer/supplier in which changes are agreed.