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 about investing in technology has become, more than ever, a crucial skill for digital leaders. Discover how Domain-Driven Design can bring business and IT together and make your technology an outright success.
The essence a successful model: people
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, and fast delivery of value to the business… Yet, we’re 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 together with colleagues. Sometimes interacting with a colleague might be simple and come naturally; for others, we have to put in more effort. Working with others can be hard and the level of success has an impact on the benefits mentioned above.
To get the most out of collaboration, we need to put thought into our interactions and the environment in which they take place. It requires us to understand the socio-technical complexity that’s at play here.
It’s not just about bugs and writing code. It’s mostly(!) 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 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 Domain-Driven Design Disconnect
As 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, it can easily result in software models that do not represent the business model. On the contrary, it often leads to all sorts of frustrations. On top of these frustrations, you’ll experience higher costs and a prolonged time to market.
To illustrate this, imagine that moment you find out you delivered something that is significantly different from what you expected and agreed upon. What you’ll get is:
- 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 the requirements weren’t clear enough and they received 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 you’re slowed down now 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, while assumptions based on a lack of communication won’t mess up your process anymore…
In other words, it would be brilliant if this disconnect could be solved, with everyone speaking the same language and doing the modeling 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?
DDD from a developer’s 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 recognized engineering practices. However, it’s not enough, and here’s Domain-Driven Design filling in the void you’ve been feeling for a long time. So, let’s go, 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 experience, we know that selling DDD in the organization is often a bit harder than just saying we’re going to apply Domain-Driven Design. Every organization is different and will have its own concerns and resistance. Overcoming this and getting 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, you’ll have opportunities to use one or more of the paradigms offered by DDD.
How to persuade your organization
Are things fuzzy between different teams? Organize a Big Picture EventStorming session and discover the boundaries between various processes. Starting a new epic that involves a process? Facilitate an EventStorming session and learn about the process and the language used. The knowledge that is gained is tremendously helpful while developing 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. The result is that you’ll be 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.
DDD from a leadership perspective
Put simply: Why should I invest in and support Domain-Driven Design?
At some point, developers will come knocking 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 into the environment we create. As a leader, you bear even more responsibility for the socio-technical system that exists. By supporting DDD, you’ll support an environment wherein constructive conversations are being held between IT and the business. In such an environment, it will become easier – by design – 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. Some of the core principles of DDD will help you create a shared sense of reality and:
- 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.
Domain-Driven Design benefits
1. A shared sense of reality
Whether you like it or not, business and IT greatly depend on each other; they create their reality together. By creating a Ubiquitous Language, your mission and vision will become more clear and will create a deeper understanding and motivation within both teams.
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 use of noise-canceling headphones, we’re having meetings without interpersonal communication, and we’re not taking the effort to actually understand each other. On top of that, a (physical) constraint between business and IT is often present, which obviously doesn’t improve communication either.
DDD principles make it easier to have these conversations with everyone involved, challenge each other and understand each other. By using visual items – like post-its, many post-its – to discuss instead of endless discussions and blaming each other, formulating working agreements collectively, and stimulating 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’s most important to the business. The core of your business. Why do 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 keep that competitive advantage.
So, now what?
Get that discussion started. See what that first EventStorming experiment will bring you. Do you see your business and IT teams come closer? Does your leadership see the dynamics change?
Please feel free to contact us if you have any questions about the Domain-Driven Design principles or how to implement DDD in your organization.
In case you don’t know yet what DDD is, you can always check one of the training courses we offer. See below for more training info, view our webinar ‘5 tips to kickstart your Domain-Driven Design approach‘, or check the Xebia and Qxperts websites.