(Data) Ownership, Boundaries, Contexts – what do these words mean?

In the last months, we started to use these terms more and more at my company without discussing the concepts behind them. One day I was asked, “What do you mean by data ownership?” 🤔 The question made me realise that I don’t know how much of these concepts are understood.

These terms refer to sociotechnical concepts (some originating from Domain-driven design). They refer to one possible answer to the question: how can a product be improved and maintained in the long term? How can we avoid hunting for weeks for bugs, understanding what the code does, finding out what it should do, and hoping that fixing one issue does not lead to a new problem? How can we continue having fun instead of becoming more and more frustrated?

Real digital products address needs which were fulfilled earlier manually. Companies which survived the first years of testing the product are often innovators in their market. They have chances to stay ahead of the others, but they have the burden of solving all questions themselves. I don’t mean the technical questions; nowadays, we have a considerable toolbox we can use. But all the competitors have that toolbox too. The questions to answer are how to organise in teams and how to organise the software to reach a steady pace without creating an over-complicated, over-engineered or over-simplified solution.

How to get a grip on the increasing complexity built up in those years when the only KPI that mattered was TTM (Time-to-Market)?

Years ago, the companies creating software to help automate work answered this question with silos around the architecture: frontend, backend, processing, etc. In the meantime, it became clear that this was not good enough.

Engineers are not hired to type code but to advise and help to solve problems. 

This means they should not belong to an engineering department anymore but be part of teams around different topics to handle: marketing, search, checkout, you name it. These are sub-domains or bounded contexts (depending on the importance of the subject, more than one bounded context can build the solution for the same sub-domain). These contexts and their boundaries are not fixed forever because the context changes, the market around the company changes, and the needs change. The people involved change and, finally, the effort needed changes. The best way also to define them is to take a look at how the business is organised (sales, marketing, finance, platform, developer experience, etc.) and how the companies using the product are organised (client setup, client onboarding, employee onboarding, payroll period, connected services, etc.). By aligning the software and – to get the most significant benefit – the teams to these sub-domains, you can ensure that the cognitive load for each team is smaller than the sum of all.

What are the benefits?

  • The domain experts and the engineers speak the same language, the ubiquitous language of their bounded context, to use the DDD terms.
  • The teams can become experts in their sub-domain to make innovation and progress easier as the problems are uncovered one after another. They can and will become responsible and accountable about their domain because they are the only ones enabled to do so.
  • Each team knows who to contact and with whom to collaborate because the ownership and the boundaries are clear. (No long-running meetings and RFCs anymore by hoping to have reached everyone involved).

What does data ownership mean in this case? Data ownership is not only about which team is the only one controlling how data is created and changed but also the one controlling which data is shared and which remains implementation detail. This way, they stay empowered and autonomous: they can decide about their experiments, reworks, and changes inside their boundaries.

Data ownership also means process ownership. 

It means the team which owns the data around “expenses”, for example, owns the features around this topic, what is implemented and when so that they are involved in each improvement or change regarding expenses from the beginning. This is the only way to respect the boundaries, take responsibility, and be accountable for all decisions around the software the engineers create.

Applying these concepts can’t be done overnight, mainly because it is not only about finding the (currently) good boundaries but also shifting the mindset from “let me build something” towards “I feel responsible for this part of my product”. It needs knowledge about the product and a lot of coaching and care. But finding the boundaries to start with should be doable in case of a product already established on the market and with a clear strategy. The alternatives are silos, continuously increasing cognitive load or the loss of an overview and local optimisations.

KanDDDinsky 2022 Watch-List

This is the list of the sessions I watched, some with additional insights, others as a resource. All of them are recommended if the topic is interesting to you.

All sessions recorded during the conference can be viewed on the KanDDDinsky YouTube channel.

Keynote By Mathias Verraes about Design & Reality

Thought-provoking, like all talks I saw from Mathias.

Connascence: beyond Coupling and Cohesion (Marco Consolaro)

An interesting old concept regarding cohesion and good developer practices. Fun fact: I had never heard of Connascence before, but two times at this conference 😀.

Learn more about this from Jim Weirich’s “Grand Unified Theory of Software Design” (YouTube). It is a clear recommendation for programmers wanting to learn how to reduce cohesion.

Architect(ure) as Enabler of Organization’s Flow of Change (Eduardo da Silva)

The evolution of the rate of change in time

“The level and speed of innovation has exploded, but we still have old mental models when it comes to organisations” – Taylorism says hello 🙁

Evolution pattern depends on architectural and team maturity.

“There is no absolute wrong or right in the organisational model of the architecture owners; it is contextual and depends on the maturity.”

This talk is highly recommended if you work in or with big organisations.

Systems Thinking by combining Team Topologies with Context Maps (Michael Plöd)

A lot of overlapping between Team Topologies and DDD

💯 recommended! (The slides are on speakerdeck.)

Road-movie architectures – simplifying our IT landscapes (Uwe Friedrichsen)

There will always be multiple architectures.

“The architecture is designed for 80-20% of the teams, and it is ignored by 80-20% of them.”

The complexity trap

Uwe describes his concept-in-evolution of a desirable solution that could help avoid the different traps. They should be

  • collaborative and inclusive,
  • allowing to travel light with the architecture,
  • topical and flexible

The concept is fascinating, with a lot of good heuristics. A clear recommendation 👍

How to relate your OKRs to your technical real-estate (Marijn Huizenveld)

Common causes of failure with OKRs
Combine OKRs with Wardley Maps

The slides are on speakerdeck. Marijn is a great speaker; the talk is recommended if you work with OKRs.

Improving Your Model by Understanding the Persona Behind the User (Zsofia Herendi)

Salesforce study: 76% of customers expect companies to understand their needs and expectations.

😱 what about the rest of 24%?!! Do they not even expect to get what they need?

Zsofia gives a lot of good tips about visualising and understanding the personas.

Balancing Coupling in Software Design (Vladik Khononov)

Maths meet physics meet software development – yet again, a talk from Vladik, which must be seen more than once.

The function for calculating the pain due to cohesion.

By reducing one of these elements (strength, volatility, distance) to 0, the maintenance pain due to coupling can be reduced to (almost) 0. Now we know what we have to do 😁.

Culture – The Ultimate Context (Avraham Poupko)

Why does not have the DDD community any actual conflicts? Because our underlying concept is to collaborate – to discuss, challenge, decide, agree, commit (even if we disagree) and act.


This talk is so “beautiful” (I know, it is a curious thing to say), so overwhelming (because of this extraordinary speaker 💚), it would be a failure even to try to describe it! It is available, go and watch it if you want to understand the DDD community.

This list is just a list. It won’t give you any hints about the hallway conversations which happen everywhere, about the feeling of “coming home to meet friends!” which I got each year, and I won’t even try 🙂.