Alberto Brandolini Reaching an agreement is one of the most expensive
and sophisticated activities of human beings in the organization - seriously also underrated
and underestimated. “Oh, we just need to reach an agreement”. That might take ages. A lot of it is about visualizing instead of
talking, that speeds up things. And the second is we don't try to reach an
agreement. We try to visualize disagreement instead,
so that we can get a snapshot of our current level of understanding, including th
e current
disagreement. So I would split reaching an agreement from
the visualization. The only thing we agree is: is this the way
we all see this today? Yes, fine. Is it beautiful? No. Is it honest? Yes, that's the best we can do. Then if we need to converge, every convergence,
every agreement has a cost. And the cost might actually skyrocket in a
larger distributed organization. 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 inv
ented 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 al
ways 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 l
anguage 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 inc
reasingly
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 matt
er. 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 bec
ause 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 no
t 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 soft
ware 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 t
hen
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 stor
ming 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
sam
e 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 l
ike 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 mor
e 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 gatherin
g 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 di
fferentiation 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 di
fferentiator 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 d
ata 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 de
fault 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 so
me. 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 w
hat 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 billi
ng. 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 talki
ng 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 prep
ared 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 peopl
e
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 eve
ry 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 agreeme
nt 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 actua
lly 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 s
ame 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 t
hen, 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 show
s 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 s
aid 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
wh
ere 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 th
e 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 r
eally 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 othe
r 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 mom
ent 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
fr
om 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 tim
e, 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 collaborator
s 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 t
his 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 need
ed 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 t
he 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 cal
endar. 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
w
ith 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 ad
d 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 th
at 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. Ju
st 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 technic
al 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
streaml
ined 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 curio
us 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 ab
out 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 real
ly 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.
Comments