By Paul de Raaij & Evelyn van Kelle
Software development is at the core of most companies. We’re all digital enterprises that need to understand how technology is heavily influencing our core business and can make or break our competitive advantage. Making the right decisions when it comes to investing in technology has become a crucial skill for digital leaders.
We’ve tried it all over the past years; waterfall, Agile, Scrum, DevOps and whatnot. We still haven’t found that silver bullet though. Spoiler alert: we probably never will. But hey, it’s the journey that counts, right?
All these methodologies were developed to get us what we so desperately want: shorter time to market, faster delivery, cost reduction, fast delivery of value to the business… Yet, we are still not leveraging all the benefits we aimed for.
That might have something to do with this other ‘small’ detail that often gets overlooked: people.
We all work with colleagues. Sometimes interacting with a colleague might be simple and come natural, for others we have to put an effort in. Working with others is hard and the level of success has an impact on the benefits mentioned before. We need to put thought in our interactions and the environment they take place. It requires us to understand the socio-technical complexity that is at play here.
It’s not just about bugs and writing code. It’s – mainly actually – about social activities and cognitive bias. You don’t have to go far to hear all kinds of examples of how business and IT are usually not the greatest of friends. Instant increased complexity right there.
What we need is a way to handle this socio-technical complexity. A way to support interactions of people to be successful. A methodology that helps us deliver that value, fast. That’s exactly where Domain-Driven Design (DDD) comes in.
The Disconnect
Like we said, business and IT do not always understand each other (immediately). When domain experts – the ones who understand the business model/products – and developers – the ones who build the models/products – are disconnected, this can easily result in software models that not represent the business model. In turn leading to all sorts of frustrations. On top of these frustrations, it will lead to higher costs and a prolonged time to market.
To illustrate: imagine that moment you find out you delivered something that is significantly different from what you expected and agreed upon. Business is not happy because they don’t feel understood; looking at a model that is not representing the business model that was discussed. IT is not happy, because requirements weren’t clear enough and there were no comments during the delivery process. Once you find yourself in this situation, it’s really hard to (re)establish that shared sense of reality and motivation. Especially because now you’re slowed down and it will cost more than accounted for beforehand. Oh, and your customers probably won’t appreciate this delay either…
Think about what would change in your environment if everyone was on the same page all the time, sharing a sense of reality and assumptions due to a lack of communication won’t mess up your process…
In other words; it would be brilliant if this disconnect could be solved, everyone speaking the same language and do the modelling together with all relevant stakeholders. DDD aims to do exactly this.
What’s in it for you?
Whether you are a developer, architect, tech lead, or CTO – it is very likely that DDD will cross your path sooner rather than later. Why should you care?
From a developer perspective
Put simply: How can you sell DDD to your boss, or your Product Owner?
In your role you want to make an impact on the success of the company. Of course you write your code with care and apply commonly recognised engineering practices. However, it’s not enough and here’s DDD filling in the void you have been feeling for a long time. So let’s go with it right?
If you can establish real, tangible business value by embracing a certain methodology, why would the business ever refuse what you recommend? This business case is even more powerful if you can demonstrate that the business value is higher with your recommended approach than with other options.
From experiences we see that selling DDD in the organisation often is a bit harder than just saying we are going to use DDD. Every organisation is different and will have its own concerns and parts of resistance. Overcoming this resistance and get things going can be a challenge.
In our view is experimentation the best way to start displaying the value of DDD. In any phase of a project there are opportunities to use one or more of the paradigms offered by DDD.
Are things fuzzy between different teams? Organise a Big-Picture Event Storming session and discover the boundaries between various processes. Starting a new epic that concerns a process? Facilitate an Event Storming session and learn about the process and the language used. The knowledge that is gained is tremendously helpful while developing the new features.
The most important thing is that you get the conversation going with developers and the business. By having better conversations, more and better information appears for anyone involved. As biases and assumptions are challenged, requirements will be defined more clearly before writing a line of code. Making it easier to develop the right thing right with a faster time to market.
As you gain trust and confidence it will become easier to adopt more paradigms and principles from Domain Driven Design in a way that matches your environment. It grows a mantra of ‘Together we create’ versus requirements tossed over a digital fence.
From a leadership perspective
Put simply: Why should I invest and support DDD?
At some point, developers will come knock at your door, trying to convince you to allocate budget and time for the latest shiny new thing in the engineering universe. Good chance that DDD is one of them. Why should you take especially this suggestion seriously? What will it bring you and your company?
Again, it comes down to business value. It’s about building the right thing right. DDD can help your teams to build the right thing. The explorations and conversations done by developers and business people can help you achieve your goals better and faster. Bonus: it leads to less mitigation of conflicts and/or problems.
As we said, we need to put thought in the environment we create. As a leader you bear even more responsibility for the socio-technical system that exists. By supporting DDD you support an environment wherein constructive conversations are being held between IT and the business. Where – by design – it becomes easier to challenge cognitive biases and assumptions made by either one of the participants. Having better requirements from the start has a big impact on the delivery time and rate of change. As some of the core principles of DDD will help you create a shared sense of reality:
- Ubiquitous language will create and maintain a shared sense of reality by removing ambiguity and deepening understanding.
- Domains will help you focus on the value that’s added and will make it easier to objectively decide where to allocate resources.
- Bounded contexts are logical boundaries, allowing you to separate domains in which particular terms, definitions and rules apply in a consistent way.
DDD Values and Benefits
1. A shared sense of reality
You do not want to be preserving when it comes to this one. Business and IT depend on each other, and create their reality together. By creating a Ubiquitous Language, the mission and vision will become even more clear and will create a deeper understanding and motivation. With visual collaboration techniques such as EventStorming, you’ll get input from all relevant stakeholders, enabling everyone to tell the story and collaboratively model reality. These steps are very often ignored or overlooked when working on a project together.
In the end, it’s this shared sense of reality that will lead to a sustainable and impactful change, improve communication and increase business value.
2. Constructive communication
Now that’s an issue, right? Everything seems to stand or fall with effective communication. It all sounds very trivial, but it’s actually not. We’re suffering from open-office spaces that encourage the usage of noise-cancelling headphones, we’re having meetings that don’t enable interpersonal communication, and we don’t make an effort to actually understand each other. On top of that, there’s usually a (physical) constraint between business and IT, which obviously doesn’t improve communication.
DDD principles make it easier to have these conversations with everyone involved, challenge each other and understand each other. By using visual items (post its) to discuss instead of endless discussions and blaming each other, formulating working agreements collectively, and stimulate informal communication, you can establish relationships, lower assumptions and focus more on the facts in front of you.
3. Competitive advantage
DDD helps you to focus your efforts on what is most important to the business. The core of your business. Why you do what you’re doing. What makes you unique. DDD helps you determine your Core Domain, Supportive Domains and Generic Domains, enabling you to allocate resources in an optimal manner. It helps you focus on what sets you apart from your competition so you can remain that competitive advantage.
Recent Comments