Navigating a Large Scale Modernization With DDD

Approximately one year ago, we started a modernization effort. So we had big plans and when we started out and I submitted this talk, I dreamed of talking about the success story. But unfortunately, it came differently. Just a couple of weeks ago, my employer and I decided to part ways. Not only because of what I'm telling here, but it still played a role. So all I can tell you about is about the lessons learned and what not to do.

So what was the plan? Our plan was to start with domain driven design, a domain driven design approach, and also being inspired by team topologies. And one important piece was also that we wanted to have a unified or a more uniform tech stack. In short, what is domain driven design and what did we try to do with it? So because we don't have much time, in very short domain driven design is about building software along the lines of your business domain. So designing your software so that it is in line with your business domain, with what your business is doing. What we did in the first step is we wanted to use domain driven design to restructure our organization, to find the bounded contexts within our organization and then plan our teams, our product teams along those lines. So we use something like big picture event storming to find all the bounded contexts and all in all, this process was relatively smooth sailing. So in the end, we had a couple of bounded contexts and we had a plan how to reorganize our organization and how to structure our teams. And for this, we also took a look at team topologies. And again, in short, team topologies is about four fundamental types of teams. First of all, we have stream aligned teams, what you probably know as product teams or cross-functional teams, and then there are other types like enabling teams and complicated subsystem teams and also a platform team. But for us, it was important to find the stream aligned teams and there you can see another slide in the team topologies approach. There are also different ways how those teams can interact with each other. But as I said, for us, it was important to find what to use domain-driven design to find the bounded contexts within our business and then apply the rules of team topologies or combine those two things and have teams that have streamlined teams that are ready to work on a given bounded context. So much for the theory, but in theory, in practice, things weren't as smooth sailing as we hoped for. So first thing that came into our way was company politics, because we wanted to restructure our organization along those bounded contexts. But of course, there were already people leading certain teams, and maybe some teams would not exist anymore after this or be in a completely different shape. And of course, not all people were happy about this. And then there is also the reality of today's tech stack, which we didn't give enough thought. So our goal was to restructure our product teams. But we had to keep in mind that the current team structure was organized around projects, around technical projects. So other teams in our new structure, or our new way of structuring our company, didn't exactly know how to deal with all the technologies involved in those other projects. So the first big lesson learned here is that we have to make sure that everybody has the same goals. So at least that everybody is aware and buys into the vision of the goals, of the restructuring, for example, and that all the people also have the same understanding of the current problems. If there are technological realities, you can't just reorganize your whole company and change all the teams without taking into consideration the current technology you are using.

So after that, we decided, now it's the time for building a new platform for our web applications, because this was also one aspect we want to improve. We want to move into the direction of a modern unified technology stack. And I set up an RFC process. So this is something we didn't have before. So I wrote a document and requested comments on this document. And in theory, this, I think, is a good idea. But in practice, as we will see, it didn't work as smoothly.

And in this document, I highlighted that we want to use a monorepo approach in the future and we want to use Next instead of Laravel. And then all people were invited to contribute to this document. And in theory, this is a good idea, but in practice, not everybody knew at this time how important the decisions will be that were made in this RFC process. And all in all, it still felt very much as me dictating the future of the platform of tomorrow. And this led to learning lesson two.

The people must feel involved in coming up with the solution for a new technology stack, for example, or anything you want to, or any larger effort within a company or a team. So we have to make sure that everybody gets on board. And because this is not always possible, for those people who are not happy with the solution, for those people who you can't convince that your idea is the best, they at least have to be aware that they need to disagree and commit. So you should make it a practice in your company that everybody feels heard and everybody is heard. But of course, you can't convince everybody, but still the people need to be aware that in the end, although they disagree, they have to commit and do their best to make the new project succeed.

Okay, so this was the RFC process for a new technology stack. And then it was time to build it. So let's build it, I thought. And there was another problem. I overpromised. And of course, then everything took a lot longer. So to find support for this RFC, I said, yeah, it won't be a big deal. I can do a lot of the work and we can do it on the side. So it won't be a big deal in the end and everything will be easy. But of course, it wasn't that way. Everything took a lot longer than anticipated. And the teams weren't aware that they also need to invest some time into it. So everybody was unhappy, basically, because there was no progress anymore.

And this leads directly to lesson three. We have to convince all the stakeholders why we need to do this and why it's worth to invest some time into it. And to convince all the stakeholders, you need to tell a convincing story. And after you told it the first time, you need to tell the story again. And you need to tell it again and again and again. And most importantly, you need to tell your story to the leadership team. And you have to get buy in and convince the leadership team. And you have to do this not with false promises as I did. But by telling, by making your case that in the end, it will be better for everybody if we invest some time into this new technology stack, for example.

So to recap, the first lesson I learned was make sure everybody has the same goals. And everybody is on board and stands behind those goals. And everybody has the same understanding of the problems. Lesson two, the people must feel involved in coming up with the solution. So to do this, make sure to get everybody on board. And if somebody still disagrees after being heard and making their case, then you have to ensure that they disagree and commit. And lesson three, convince all the stakeholders and repeatedly tell your story why what you want to do, why this big technological refactoring, for example, is worth it in the end.

My name is Markus Oberliner. And if you want to talk about what I told you today, to not repeat the same problems, reach out to me on Twitter or LinkedIn, for example. And maybe if you're into testing and Vue.js, think about Mapbook.