Diagram driven development | Booking.com

[intro jingle] Hey, everyone. First of all, thank you for making the time to attend - and also for giving me a place on the stage. It's a very prestigious organisation that organises this, as well as so many people I look up to in the industries here. So, it's a really humbling experience. So, thank you for being here. My topic is diagram-driven development. But before we get into that, first of all, namaste. I'm from India. I lived for around 28 years there before moving to the Netherlands in 2023. And that's when I started working for Booking.com, where I'm working right now. And overall, I have around 10 years of experience, which is not a lot, but it's something, something to see what I like and come to speak at conferences like this. So, over the last five years, about halfway through my career, I saw that there are some things that I feel more interested in, some things that I feel are foundational enough that talking about it with people like you, all of us together could talk about the foundational things. So, I write a little bit, and I speak a little bit about these topics. And that's what brings me here today as well. Because these foundational topics are kind of what the future of software might hold for us. So, before talking about the future, a bit into the past, as a community, we decided that these big monolithic structures, these big repositories that did everything, were hard to manage. And it started to show its age. And we decided that there's a better way of doing this. Following the Unix philosophy, building bigger things out of smaller parts is better. So, we decided to go the microservices route. And it's essentially similar to a puzzle piece - where you have a big set of puzzle pieces, and each one of them is very easy to handle and manage, but together they form something bigger. And that worked really well for us over the last decade, microservices gave us a lot of benefits. and that's why everybody is doing it in some form or the other. I certainly am doing this almost every day, and this is really good. But the fact is that anything that is widely popular in the industry starts to show us that they are good, they're really good at solving some issues, but there are some things we might still have to do with them. And that's what I want to talk about today. The problem that I see in microservices is that it fragments our systems. And just like a jigsaw puzzle, if you look at the set of puzzles that are there in the box that it comes out with, it's very hard to see what it makes overall. So, because we have so many pieces, it's hard to see the big picture. But the big picture is really important, because when we build products, we build a product that should work as a whole. The customer, the end user is not going to be happy with just the puzzle piece, just the microservice. They want something bigger, something that they can use. And this fragmentation poses two problems. First, it is hard to change because there are so many moving parts. Any change that we want to do to the product might require changes in five or six microservices. That means meetings, that means discussions, that means agreements, disagreements. So, adaptability to change is one problem of microservices fragmentation. And the second is that it's hard to understand. Because there may be thousands of microservices, and thousands of microservices is not a very crazy number, it happens, it's very hard to understand what does what. Because you might have one corner piece of the puzzle that is not aware of the other corner. But again, the problem is one whole thing that we're trying to solve. So, let's try to look not challenges that we set out to solve. I didn't wake up in the morning thinking, 'Oh, today, I'll do some prolonged discovery.' That is never the case. What we would like to do is to spend more time building features, building domain microservices. And a little bit of help from another system could bring it all together to help us build more product features. So, is this the future of socio-technical systems? Well, I can't predict the future. Maybe you can. But one thing I can say for sure is that we cannot influence the future if we do not question the present. And although microservices gave us a lot of benefits, and I think that microservices are here to stay, they did leave us with one problem that is not solved. That is fragmentation. And fragmented systems are accidentally complex. They're difficult to change, they're hard to understand. BPM diagrams are kind of like the glue that allows systems to be more composable. So, we have these microservices that take on a lot of the product responsibilities. But they are not composable just by on their own, right? So, having a layer, a control layer or an orchestration layer that composes microservices together would be a real benefit. But also, because it is a diagram, this is a unified mental model that everybody would understand. And we would not have to rediscover our systems multiple times. And that really is the power of a diagram-driven development, because it brings systems and humans closer together to build an organisational cohesion, so that we could really solve the problems that we want to solve and not get stuck with problems like coupled systems or re-implementations. And that's why I would argue that the future of socio-technical systems, if not BPM, has to do with solving fragmentation. Thank you. [applause] [outro music] [music ends]