Simone Cicero:

Hello everybody. Welcome back to the Boundaryless Conversations podcast. In this podcast we meet with pioneers, thinkers, doers, and entrepreneurs, and we speak about the future of business models, organizations, markets, and society in this rapidly changing world we live. I’m Simone Cicero, and today I am joined by my usual co-host, Stina Heikkila. Hello Stina.

Stina Heikkila:

Hello everybody.

Simone Cicero:

Today we’re also joined by Alberto Brandolini. Besides being the inventor of the bullshit asymmetry principal aka the Brandolini’s law, Alberto is a legend of domain-driven design. He has invented one of the most used modeling techniques in the space, the technique called event storming. Albert is also a frequent speaker at conferences and events, is an international trainer with more than ten years of experience, and he is also the founder of company called Avanscoperta, which is a hub for inventing, promoting, and spreading new ideas around software development. Such a critical thing in the world we live in. Avanscoperta provides trainings and consulting services and Alberto is always available to add some new insights in the space. Hello Alberto, it’s great to have you here.

Alberto Brandolini:

Hello everybody. Happy to be here.

Simone Cicero:

We kind of deliberately invited Alberto to the podcaster because we needed some expert kind of sparring partner in our exploration of some of the most complex issues of our research. I think we made the case for this conversation because we wanted to explore the role of domain-driven design and more generally, I think, the role of language and context mapping into this process that we see happening, or at least we believe it needs to happen, which we often called ontological convergence. We’re talking about all these evolutions in the industry, technology or software that are driving for example, the adoption of common models, software modules, protocols. But in general, I think what we want to investigate with Alberto, this is a space where language and technology are converging. So in this large space we believe that increasingly the boundaries are blurring. Boundaries between technology and business, boundaries between one team and another team, boundaries between one organization and another organization. So, Alberto, maybe as an initial kind of common ground, you can give us a little bit of overview of what domain-driven design is, why it’s becoming ever more important as we move forward in this century and a little bit of maybe your contribution to the space, your work with even solving.

Alberto Brandolini:

The fundamental problem in software development that domain-driven design tries to address is the fact that especially in enterprise software development, what is really, really important is understanding what is the problem we are trying to solve. It’s not about coding speed, but it’s about understanding what is the right thing to do. Okay, this seems like fairly obvious, but if we think about what is the structure of the typical enterprise organization, be the profit or nonprofit, doesn’t matter. You have departments which are usually structured in sales. They have local expertise often expressed in local jargon and all of this mixture of languages and diverging perspectives is very, very hard to compress squeeze into a single model solving a variety of problems throughout the enterprise. So what domain-driven design does instead is one acknowledges that the conversational language we use for gathering requirements, discussing knowledge with the experts, is not a completely reliable media. There are synonyms, there are words with multiple meanings, and there are all of the possible inconsistencies if people are coming from different cultures. There’s a typical example of let’s have a coffee and then you’re doing this with an Italian and that means let’s have an espresso. But you don’t call it expresso. So if you are Italian because it’s so deut, is small, it’s just whatever bigger is not a coffee. And then, well, if you are from northern country, you need the larger cup because the weather is colder outside and so coffee is something different. So if we assume the same coffee is probably not going to work at the software level, but in terms of domain driven design domain driven design brings on the table 1) awareness of the possible inconsistencies of the conversational language, 2) the fact that if you go for one single model solving all the problems, it’s not going to work. You’re stretching it, you’re bending it and you’re making it very hard to maintain and not very fitting the many purposes. Instead, DDD suggest to say to do two things, one, accept to have many multiple single purpose models, each one with a very specific language. Inside this bubble that we can call a bounded context, we could consider language to be reliable instead. Every term has only one meaning and the language is what becomes called the ubiquitous language could be spoken by every representative of every stakeholder of the software project, be the business expert, be the software developers, the DBA or the tester whoever is involved, the words they use are very precise, have no ambiguity in this specific context, so that inside these bounded contexts you could optimize the model towards one purpose: multiple model, each one very precise. That is the main idea. Then the thing that might be really interesting is why this became popular. It was an idea that was born actually 17 years ago now, and there was a little group of early adopters that were happy about it and then it was a little bit of a hype cycle and then it started booming again. Well, actually ten years ago was the beginning of the renaissance when ideas from Greg Young and Udi Dahan became popular and was born with the Red Book and we have a little bit more architectural options, that was also my contribution a couple of years later with event storming and then the other driving force was coming from the outside, the microservices movement, the goal, the rush for distributed architecture. Well, if you go in this direction, you got to have very clear what is the structure in terms of models because if you are still bringing the coupling with you from a data center architecture well then your microservices architecture is going to have a very hard life. That is the main idea. That’s the reason why it’s getting more popular. If you go distributed then having clean boundaries and separation really becomes a key factor in effectiveness and success when it comes to event storming, event storming is a way to deal with gathering information learning in the enterprise. Instead of having multiple interviews with business stakeholders trying to understand what is their own problem, then you talk with somebody else and they give you a different version of the same problem or maybe a different perspective, and then you’re trying to put together all the different stories in a coherent whole. While with event storming, we do something different. We gather all the key stakeholders in the same room. We try to build an end to end model of a business line of a critical project or whatever is the scope could actually scale up to very very large workshops and together we build a behavioral model of everything. The building blocks are little sticky notes where you write events on them like item purchase, order completed, order deliver, payment received and all this stuff we put them on a visible timeline but the thing is we’re not doing it in a boring way, we are doing it together just like we first make a big mess. It’s actually called chaotic exploration. The first step of an even storing workshop but then this little crowd participating to the workshop tries to linearize the storyline okay, this has to happen before this. I cannot send you these goods to your address if I haven’t collected your address or if I received a payment or did you always receive the payment before the order? Not always. Okay, so we have a lot of discussions during the workshop. The model becomes more sophisticated and all of these discussions are spontaneous and provide a clarification of the of the flow. In the space of one day, we get roughly 20, 30 people now having a visible model, something like 12, 15 meters of everything that happens inside the business line. But also we could see more stuff like which are the critical system, which are the critical people, which are the default boundaries of hand off responsibilities, which change your perspective, whatever could enrich the model. And this becomes a very sophisticated background for any other conversation. When are we creating value could be an obvious step or who is responsible for this area, where this responsibility ends? What is going to be the scope of our next development project? A lot of these things are actually visible including frictions discussions and different point of views. It just makes every other conversation a lot easier and makes a very good learning experience. Last but not least, instead of gathering information from different sources in different moments event storming forces all the sources to agree on the representation of what happens. So we get a story which is already linearized and this linearization is where most of the learning happens. Okay, now I see it end to end. I know what every person is doing, how these people are contributing to the model, Oh, now it’s a piece of cake. That’s where I like to be.

Simone Cicero:

What is the difference in your experience in approaching these challenges with domain-driven design approach when it comes to, on the one hand, building a product for a customer and on the other side, instead, when it comes to maybe more like process-oriented work, which is typically related to how companies work, how different departments hand over part of the value proposition or the processes that need to be executed to generate a certain value proposition. So is there a difference, I would say, or something that maybe is worth double clicking in this differentiation between a small team building a new product for a certain type of customer and on the other side, larger organizations?

Alberto Brandolini:

Okay, well, there are differences. I would start from the organization perspective first. So I’m flipping your questions because then it’s going to be easier for me to answer. So domain-driven design was not born with products in mind, was born with enterprise software. I’m looking to the organization, I’m trying to understand what is the key differentiator in the current moment in time for the organization. And I’m applying advanced design and modeling and implementation techniques to this portion of the software because this is the place that is going to make a difference right now for the organization. So having multiple stakeholders is the matter in the fact that we are making software, developing software for the enterprise. In terms of event storming, also I mentioned it like this is one thing actually event storming is a family of workshop. The one I described is what I call the big picture. A lot of people involved, there are two other recipes. One is called process modeling which is really optimized for designing collaboratively processes which may or may not include software in this. And there’s a more technical version which is software design which designs software components which are supporting business processes. So there’s a lot of focus in all the decisions that happen during a business flow and what is the data needed to support this decision? What are people looking at maybe in term of UX UI, visualizing the information which is crucial, and also understanding how this information is coming from, whether, if it’s missing, whether if it’s easy to acquire and looking at bottlenecks and all of this stuff. So in one way, the way domain-driven design was born and also the way event storming was developed, it was syncing with one organization in mind and that was software for the organization. That’s default space. The moment we move into products, a few things change. One thing is, well, depends on the product. Some products are workflow products. We’ve been working on something that was related to financial analysis forecasts and related to billing and sharing forecasts inside the organization. That was cool. But that’s already a portion of a typical customer’s workflow. So it might still be really useful to go event storming to understand what happens in the customer flow. Still, it really changes if you’re talking about one customer, if you are maybe a consulting company developing one customer solution for one external organization or if you’re developing the product for the market in this case you don’t have one customer, I hope, I hope you have more than them. But then you need to design not for the specific customer, but for your ideal customer persona or customer personas. We think market segments. You think about what the typical customer might want and it really changes some. I mean, if you are consumer market you’re going to look to a very, very large space of very diverging way of using it. And if you are very specific to a given niche, well, maybe you can approximate the default usage. Still there’s something which is even in products which are not following this workflow approach. Well, think of Excel for example. That’s a tool that doesn’t really follow any workflow approaches purposes. You can use it in so many different ways. A spreadsheet, we don’t know what is the moment in the workflow where you’re using it. You’re using it maybe for whatever. So it doesn’t make any sense to explore this in an event based approach. Okay, that’s the first difference. Another one. But still, if you are the company making a product spreadsheet, you will still have a lot of workflow on your side. Maybe marketing, customer acquisition, well, registration, activation, product set up and then also gathering, tracking, inconsistencies and bag claims and also the billing. All of the stuff that happens around the product that’s very domain-driven design in the structure and could also be explored very efficiently with event storming and yeah, we did it, it works and really helps, usually.

Simone Cicero:

Everything you speak about doesn’t really sound like software related to me. You spoke about, for example, DDD as a way to ensure learning in the enterprise. It’s all about ensuring that the people around the setting process understand clearly what they’re talking about and they have this ubiquitous language and share the language among each other. And I’m sometimes very surprised that companies often don’t understand how much it’s important to have shared models to agree around something. And because this process of agreeing, first of all, it’s inherently collective. So it’s something that is a property of the ensemble, I would say, not of the single person in the organization. And also because it’s a way to really make tradeoffs visible. When we prepared this conversation, you spoke about something very interesting to me that is this idea of seeing the cost benefit of agreeing, right? Can we try to clarify why this kind of piece of work that not many companies seems to do, why is this at the same time so important, obviously, and on the other hand very much undervalued and rarely practiced by organizations?

Alberto Brandolini:

Reaching an agreement is one of the most expensive and sophisticated activities of human beings in the organization. Still is also underrated and underestimated oh just we need to reach an agreement that might take ages. If you look at the dynamics of what happens in the big picture, event storming we are visualizing everything and we agree on nothing and that’s what makes the workshop really really efficient. I mean agreement on a solution has a different path and a different format. That’s what we do on software design and process modeling format but what makes it viable to run a large workshop 20, 30 people in the same room is that we basically postpone agreement and we use tricks like little hotspot, a magenta or fuchsia sticky note saying visualizing this agreement exactly. Because if we try to normalize every bit of the model where we don’t agree time is going to pass and we’re going to finalize nothing. So the main idea about the big picture is reaching an agreement has costs that go exponentially up related to the number of people just because each one of them want to have an opinion or just make the same opinion heard by everybody it’s going to slow us down a lot. So a lot is about visualizing instead of talking, that speeds up thing. And the second is we don’t try to reach an agreement. We try to visualize this agreement instead so that we can get a snapshot of this is our current level of understanding, including the current disagreement, then some of those disagreement might be worth investigation. And then we do a separate workshop for them. But I think the key thing is in every organization is just the cost of reaching an agreement is underestimated, it’s treated like an easy activity and it’s not. And this cost is really related to the size of the organization. Reaching an agreement about the meaning of a word in a very large organization could take ages or could be fake, people might end up lying. Yes, it’s fine for me it’s not fine, I just don’t want to spend any more hours or days or months discussing it. Still it’s valuable. So I would split reaching an agreement from the visualization. So I’m all for visualization and visualize in the current state of understanding validated by everybody the only thing we agree is is this the way we all see this today? Yes, fine, that’s that’s good enough but all of my different opinions are visualized great, that’s something we can put our signature on. It is beautiful? No. It is honest? Yes. That’s the best we can do. Then if we need to converge every convergence, every agreement has a cost and big cost might actually skyrocket in large distributed organization.

Simone Cicero:

I believe this is really a way to make a case for modularity, am I right? So this idea that we can achieve large complex systems only through modularity, that reduces the need for agreement inside the module, let’s say, and leaves the rest to a clear interface.

Alberto Brandolini:

Yes and no. I mean, having components, modules that have a very specific purpose, it just reduces the need to collective agreement about stuff. But at the same time there’s something embedded inside of domain-driven design, in the space of context mapping. There are a few patterns of collaboration which are stressing the different edges. So let’s say you might have a context mapping part called a shared kernel, which is saying like, okay, there’s a portion of our model which is exactly the same. We are going to treat it like one and shared with everybody, which has the advantage of having a single definition perfect. But it has disadvantages, which is the cost of evolving. This one is very, very high because if you touch this little portion of the software, it can have massive ripple effects across the organization. And then at the other end of the spectrum you might have something like patterns of collaboration. This model is evolving, but I need a separate version of it which is evolving to my need, so I can still negotiate the translation if needed or if there is no space for negotiation the translation. I will write an adapter so that my model is going to be independent from the external model and I don’t have to be involved in all the discussions about the evolution. Also the final extreme is what is called separate ways. There is this model, there is this model which is apparently very similar, but the cost of coordinating or merging the two is not worth the coordination cost. So I do what I want, you do what you want. Maybe let’s have a beer in a few years, but let’s have zero coordination cost between our models because coordination has a cost. Domain-driven design maps all of these patterns and drawing a map of this collaboration is displaying you the forces that could make your software project a success or a trap. That’s actually very powerful because it shows the gray area between software architecture and politics, which nobody else is looking at.

Stina Heikkila:

Making things that are usually very complex so clear to some extent, through your mapping, it’s quite easy to visualize how that would work. But then, like you said, when you’re approaching the politics of the situation what I was curious to understand better when you were explaining the approach is that it seems like if you take this domain-driven design approach in the flow that you mentioned, if you have a kind of blank slate no, that seems that it would work more smoothly. Right. Because you would map everything and then you can see some levels of disagreement but if you’re starting from a blank page of course it’s easier to find the optimal agreements and probably the cost of reaching an agreement might be less. But then if you work in context where there are already vested interests, there are existing solutions in place that maybe have some level of lock in also through contracts and previous investment. How do you work in essential context? Is that part of the disagreements that you might visualize or can you work with this kind of method in already existing quite complex environment? What does emerge if you do that and what implications can it have for how the organization evolves in that case?

Alberto Brandolini:

The first answer is yes, absolutely, very same tool which is context mapping could be used in brownfield and in greenfield scenario. I don’t know which one is easier because well, let me take a look at the brownfield. We’re going to have legacy software, we’re going to have existing contracts and strong forces. We’re just visualizing them and drawing a context map of a complex enterprise scenario shows the politics, shows the constraints, shows for example, the fact that there’s a strong business need to evolve one portion of the software which is downstream to low-quality components and subject to, well, let’s say ripple effect, interferences or sometimes also failures. And if somebody is asking our team to, you need to deliver great software there, but we don’t have our boundaries protected, well, it might be a good moment for waving a red flag. Unless we protect ourselves from the outside influencer, we cannot make great stuff here because it’s going to be a continuous cycle of firefighting restarting stuff, fixing problem which are not ours and so on. And this information is very clear before starting the project and very vital. So before starting any project in legacy we do what is called brownfield context mapping. It makes me ask the right tough questions and draw the map quickly and then give some hard to digest advice like this is never going to work unless we do this. Oh no, but we have to keep it. Well then, goodbye. That’s the type of discussion we might have. If you go on a clean light or a greenfield type of thing then it is easier because you don’t have the politics involved and nobody cannot be blamed for purchasing a license for a useless tool ten years ago that now becomes a drag for the evolution. You don’t have this problem. Still you have software architect aiming to do the perfect thing and this could become paralysis in some scenario. That’s why I said maybe it’s not easier because you might be wondering a lot, okay, what might be the composition of this system? That’s a place where we actually do use a lot, event storming to understand what is the flow and then to detect the ideal boundaries. Actually, most of the time we do a combination of the two activities we try to detect what might be the ideal boundaries, we look at the existing legacy to see where are the effective boundaries and then we put the two images together and we look at both of them. Oh, this is where you should be, this is where you are installed. So now what are we going to change first? What is the single transformation that is leading you into a better place?

Simone Cicero:

We have seen technologies making it easier to build software, let’s say, from known software professionals. Right. So a couple of things that this brings up is for me, I would say, a multiplication of the context where software can be adopted. So in general we can expect maybe a future where more applications get built and to some extent also some kind of larger standardization of the enabling layers. So let’s say that everybody uses a certain low code technology. Most of the software will be modules that exist already in the technology and lots of work to be done more in terms of deciding how these modules get connected for a specific need of a specific person. Right. So I would say that with the penetration of these technologies there would be more work for bids persons, maybe less work for purely software persons. First of all, what is your perception about this and the role of DDD and in general these collective techniques to make some people agree around what they want to build around the shared model? So how are these kind of practices going to be impacted by the professional low-code environments or even AI and software? Are they going to be less important? More important?

Alberto Brandolini:

Most of no-code and low-code approaches are actually designed around the paradigm which is antithetic to domain-driven design. I mean, domain-driven design maps many things, and one way to describe this could be the conformist. But let’s say most of those digital code is about maybe getting some data from one source and forwarding to another one or maybe maybe making a little bit of data manipulation on this and then visualizing it on another platform. The great advantage is exactly what you mentioned. Just like there’s a lot of do-it-yourself approach that could really help if we are in the prototyping stage, that’s actually amazing. You can get something that looks almost like what you want in a very very short time. Amazing. The thing, it changes if you start looking at things in a longer perspective. Like whatever you write in terms of software is something that needs to be maintained later on. So is the business person maintaining the software? Well, maybe not. Is the software person having to maintain a no-code solution or low-code solution? I’m not sure. Maybe that’s not the right ecosystem you would like to create. It’s still great in the early stages of a startup. It might not be good for a more mature enterprise behind the scenes good business enterprise software discovered in a domain driven design way is a little bit more event based. No-code solution seems to be closer to the mental model of the business person and seems to be a little bit more data centric. That’s something that will have a price at a given moment in time. The other thing still has to do with the evolution of software. So let’s say I have one business need that I need for my company. In our case, we needed a platform for selling tickets for our training organization. Great, we find a solution already, we started using it, and we kept using it. Then at a given moment you would like to go to some other solution because you might be trapped license costs or maybe it’s not really fitting what you need to do now. So you might want to go to another one. The moment you want to switch to another solution or evolve it, you realize that it’s not only passing from solution A to solution B. If you want to keep historical record of all the stuff that happened, you need an internal model somewhere to merge the historical information from the multiple sources and then oh, just giving all of your model inside a third party tool might not have been the perfect solution in long term thinking for your organization. So the moment we needed to make the transition from A to B, we needed to build an internal C model that could bridge between A and B because the only way to preserve history. So this is one of the tricky things. It’s just different life cycle. Domain-driven design has a word for it which is called the conformist pattern. There’s a radiate model. It looks really convenient. You have very good short-term advantages. You’re also have disadvantages in the long term. So make a conscious solution. It might be a throwaway model, it might also become a trap later on, but then you might be already successful enough to pay for a better solution.

Simone Cicero:

What I perceive here is don’t use a no-code solution or an existing product for specific part of the business process that is central to your business. Otherwise, every time you have to change something you will for example lose your history or your data and so on. So essentially there is a kind of a pressure to as an organization be able to develop your own software backbone, I would say. Let’s say the messages be a variety of discounted no-code or even AI driven software development because they are luring you. But over the long term it may be very complex, let’s say to evolve. Can we say that investing in DDD or in general in understanding these models and visualizing them and understanding your bounded context as an organization and creating these kind of spaces where the people in the organization can share a model, share a language is a way to kind of keep the organization more capable of evolving some extent. So it’s like as an organization you have to go through this because it makes a better organization, it makes a more capable organization. Once an organization has a set of shared models and the capability to understand how these bounded context of existing models connect with each other and evolve. So what do you think in terms of the strategic, I would say role that integrating these kind of modeling techniques and domain-driven design in general can bring to the organization in terms of strategic advantage?

Alberto Brandolini:

Two things. One, I wouldn’t be so radical to say like well, don’t go no-code or low-code. It’s mostly about maturity and awareness. There is a spectrum. The thing that I might be warning people about is the life cycle of a piece of software is mostly maintenance and while the solution for situation, for building a prototype might be 10% of the life cycle of your software product and maybe the business person, the founder of a startup is not clearly the person who’s going to be in charge of maintenance of all the no-code, low-code components scattered around the system. But we are adults and we know that if we are prototyping a business model with a startup, maybe we’re not going to get anywhere. So it’s absolutely reasonable to go fast prototyping. What domain-driven design suggests is just like be aware of the cost of your architectural decision and in general be aware of the evolutions of these forces around time, is not only now is how long are you going to stay with this piece of software that looks so beautiful right now? It can be a terrible trap in five years. In terms of other exploration tools, be it in storming, contacts, mapping, this could also be outside of domain-driven design. It is not calling for a very sophisticated implementation or is not calling for a sophisticated implementation everywhere. It’s one thing is are you aware of the forces inside your organization at a very high level? Event storming is just telling, it’s just a collaborative way to do something like value stream mapping or a multi currency value coordinates. So where are you creating revenues, where are you creating goods, where are you improving the reputation of the people involved, where are you creating happiness? That’s all of the stuff that could get visualized and that’s a great information to be available inside the organization. The moment you are aware of which are the steps making your collaborators happy, which are the steps making them angry, well that’s actually really valuable. Same goes for mapping the models, the different purposes of software components in your organization, somebody needs to know that and then well, the choices you do with this, okay, that might be very context-specific. So we do the map, we play the high value, high complexity skills and the sophisticated architecture only where it matters. The thing with domain-driven design is giving you the tool for diagnosis, where applying the full stack of capabilities also in the architectural and implementation space makes sense. You don’t have to make everything perfect, you have to make really, really good things where quality pays off.

Simone Cicero:

You spoke a lot about DDD and in general, this kind of recognition that we have to first build or at least identify a shared context, then identify the language inside this shared context and then develop software, which makes a lot of sense, especially inside an organization. But on the other hand, At Boundaryless, for example, we have been interested lately in understanding how organizations can bring, for example, a new standard in the market, or at least position, for example, some of their products as enabling platforms. Right. And positioning a product into the market as an enabling platform, of course, goes with kind of projecting on your ecosystem your choices in terms of ontologies and models, right? Of course, there is a degree of extendability that you can inject into a product platform strategy through what we call, for example, extension platforms. So typically we see operators coming into the market with the possibility to develop plugins and extensions or templates so that the third parties in the ecosystem can to some extent integrate and extend your ontology and make it possible for the customers to find out very niche use cases. Right? But to some extent, when an organization brings something into the market, there is always this legitimacy that the organization needs to build for third parties to use a piece of software, especially a platform. Right? Because platform is enabling higher value exchanges on top. Lately we have seen the emergence of this conversation around Web3 as somehow an alternative and an evolution of the platform model. And most of these Web3 players have said we’re going to build protocols. Protocols are not going to be by a central party, I would say. And so you more free, more sovereign. But I’ve seen rarely a conversation around understanding, for example, why some of these protocols are not used, or for example, why there is this tendency to always reinvent the wheel in this Web3 space. I feel like when companies or DAOs actually distributed organizations want to bring a standard, an enabling platform, a protocol into the market, very rarely they understand that there may be some work needed before creating the technology and bringing it into the market. There may be some work needed in first building the shared context and building the shared language. At the same time, I think in a prepared conversation we had, you also spoke about the case of AWS, pointing out to how Amazon has been able to bring this standard to the market through a very aggressive provisioning and cheap provisioning, I would say, pattern. So maybe we can use a few minutes in this conversation to nudge you into a reflection around driving standards into markets, into ecosystems. What could be the role of DDD and in general, how to ponder beyond technology and business model and provisioning as potential strategies to bring something into the market. The questions around building these shared languages and shared context so that the parties involved in the ecosystem can more happily and more easily embrace a shared model. What do you think?

Alberto Brandolini:

I like when you use the word legitimacy for a model. I’m not really really familiar with the Web3 space, but my assumption is most of the models that we are talking about are building blocks. So the modeling space, it is layered and they are expecting companies, organizations or individuals to build a higher level services based on top of components which are, let’s say at lower level of abstraction composition in this way. But the more you approach a larger arena, the harder it is to do something which is standard for everybody, going beyond very basic stuff. I’m thinking about what happened with the old Java class for the calendar. People have been working in the Java space. It has been one of the most complex basic problems in Java because you needed to be aware of different time zones just to have a calendar and then something like 15 years later, under the pressure of the community, can you just make it simpler because we don’t need all of this complexity. In the basic case, a few simpler abstraction were brought to the market. They were not as general purpose of the Java utility calendar, but they were faster to use and easier and they were solving most of the basic stuff. Well, the thing is, if you want to be generic in a wide arena, you need to study and prepare a little more. And maybe the cost for it is not really worthwhile. At the same time, when you said, like some people are just reinventing the wheel, the cost of doing and the pleasure of doing could be more interesting than the cost of knowing there’s already solution plus the cost of learning. How is this solution, which has been developed with a mental model which is different from mine, why learning this could be not so rewarding. And then I’m locked into a solution that is not exactly what I need, or even more, there are so many available solutions for basic stuff and then you don’t know which one is reliable, which one is supported by a teenage developer, which one is supported by a larger company which maybe is dysfunctional. So they just hire a teenage developer because that’s the only person who would maintain this piece of software. Whenever you’re using software components all around, you’re thinking about what is the background, how might be the long term stuff. So sometimes reinventing it is just a way to keep it under your control without distributing vulnerabilities all around. It’s actually fairly complex system in this sense. I’m thinking about the metaphor of softer components as LEGO bricks which is one of the most flawed metaphor in software development. Just like every single time you spend so much time searching for the piece you’re looking for and then evaluating is it really right for me? What might be the consequences, what is the license and all of this stuff. This takes an awful amount of time and it’s also not quality time. Sometimes it’s just more rewarding to just well, I’m going to develop mine, I’m going to put it on GitHub, make it available to other people and making the problem of selecting the perfect solution harder for the next one to come. So it’s a messy ecosystem. If you add in humans and their habits for learning and for getting a little bit of personal reward and recognition, I think it’s going to stay messy. There is no way to well, let’s take all the useless stuff away.

Simone Cicero:

That’s an interesting point. I think adding the detail that comes with Web3 and platforms in general is this question of network effects which depend on somehow depend on sharing a context. Right? I totally understand your points. The points that you say that you’re bringing up that are somehow conducive to acknowledging that there will always be a tendency to reinvent the wheel. But on the other side that we have this pressure to instead the sharing a space, sharing a context because in this way we can achieve network effects. So these are open questions. I think that we have to research more.

Alberto Brandolini:

There’s one thing that I forgot, like the thing about establishing standards. It really changes a lot. We mentioned Amazon and it’s a way to get in an MTR first Blue Ocean first get in there with a very good quality level. Then you might be a de facto standard. In general, when you mentioned legitimacy, the quality of your component is so good compared to the alternatives that this becomes an obvious choice and this is a good way to create standard in a place. It’s actually very hard if you have already competing approaches to the same problem and forcing a standard above the the existent technologies. That’s where we discuss the wall plug problems. Just it’s the same thing, the same problem in every country. But Italian wall plugs are different from British, which are different from Germany and which are different from other nation. And there is an interesting market for wall plug adapters in airports just because of this, because we couldn’t reach an agreement on a standard on something which is actually trivial like three holes in the wall.

Stina Heikkila:

We are talking a lot about, on the one hand, developing software quite on the technical level. And you also mentioned that, you know, your technique is not only for developing software, but it’s actually a technique for evolving organizations, making like complex environments and disagreements visible and so on. So I wanted to just quickly come back to that element of maybe more looking at your company and the hub that you are creating. What different profiles are useful for you in that? Because I can imagine you work a lot with developers obviously, organizational designers, I don’t know other profiles that you find are helpful to evolve your practice and your framework and what you’re looking into. Also maybe like forward looking.

Alberto Brandolini:

One of the things that happens, especially in process modeling is we see every business process as a sequence or a combination of tough decisions. I mean, there are also easy decisions, but the process never stops on the easy decisions. And this gave us a little bit of a framework for trying to improve, to streamline any process looking at, okay, why are you designing this? What is the information you’re looking at? How hard it is to achieve this information or to reach this information in your organization? So this synergy of software, architectural people making this information available, UX and UI designer making this information reach easy, understandable, easy to access, but also it’s a way of finding new ways to do leadership inside the organization. The moment you make the decision-making pattern streamlined and easy, maybe you don’t need a top layer position to make a critical decision because the process becomes a little bit more obvious and could be distributed. That’s more or less the key issues that we are facing. I guess the hardest part now for organizations which are mostly been going remote is finding a way to make distributed decision, especially on critical areas, still possible. And currently is a space where visual designers really can help a lot. Like our purpose at this moment is understand which decision are really, really critical. Is there any way to make them easy? Can we design a decision-making space for remote contributors which makes their decision easy up to the point of being obvious is not always guaranteed, but designing those decision making space is actually our current challenge.

Simone Cicero:

I would like to ask you to share your breadcrumbs with our listeners. So anything that you want to direct our listeners to.

Alberto Brandolini:

Well, if you’re curious about domain-driven design, there’s a few books you might want to get into. Maybe the smaller one is Vaughn Vernon, Domain-Driven Design Distilled, before getting to the bigger Red Book, which is more for technical people. Of course, there’s my book on event storming, if you’re curious about it. I think there’s a lot of really interesting stuff coming from David Sibbet in terms of visualization. Visual meetings was my entry point and also I would say Dave Gray. He gave me a lot of insights about how to think different type of organization and how to create a space so that different type of organization with lesser involvement from the top management could survive. And final thing, the DDD Crew project on GitHub where they share a lot of resources, modern stuff about domain-driven design. I forgot the Avanscoperta blog where I put a few of these things and it was kind of obvious for me, so well, also this one.

Simone Cicero:

Definitely. We will put every link into the notes and I really encourage you guys, the listeners, to check out the Avanscoperta website and see if you can jump on some of the trainings that Alberto and his crew are delivering.

Stina Heikkila:

So yeah, well, I can also thank you so much from my side. Alberto, I almost feel like we would need a part two of this conversation because there was a lot of things that we could have explored even more. So really good, useful resources. Hope you also enjoyed the time with us, Alberto.

Alberto Brandolini:

Absolutely, yes was a pleasure.

Stina Heikkila:

Great. For everything that we have been mentioning, you can, as always, find all the notes on our website boundaryless.io/resources/podcast and we’ll catch up soon. And remember to think Boundaryless.