I recently asked a room of practitioners: "How much are you involved in architectural decision making?" The average was 7 out of 10.

Sounds good right?

Then I asked the same group: "What is software architecture?"
>>>

The biggest blocker to teams making intentional software architecture decisions isn't technical complexity. It's not knowing whether they're allowed to decide.

Last week at AI Native Amsterdam I talked about facilitating software architecture while AI agents write the code. In the talk I use Gregor Hohpe's model of different modes of how architecture decisions get made in teams (see the slide), and I asked the audience which mode they preferred and what was blocking them from getting there.
>>>

The speed at which AI agents write code is no longer the bottleneck. Whether we understand what that code is actually doing, that's where it gets interesting.

On 7 April I'll be speaking at the AI Native Netherlands meetup at the Miro offices in Amsterdam.
>>>

Something a bit special is happening at FlowCon France in two weeks: I will be on stage at the same conference with my co-authors of Collaborative Software Design, just not at the same time.

#CollaborativeSoftwareDesign #DomainDrivenDesign #SoftwareArchitecture #DecisionMaking #FlowConFrance https://flowcon.fr
>>>

Everyone is talking about how AI will change the way we build software.

Almost nobody is talking about what was already broken before it arrived.

After recording and editing our new @virtualddd Stories on Facilitating Software Architecture & Design together with @roundcrisis and @ahl, one thing keeps coming back to us: the hardest part of software was never the technical decisions. It was what happened — or didn't happen — in the room where they were made.
>>>

As per usual practice, we are finalising our slides on the train, one day before Agile meets Architecture kicks off in Berlin.

The talk is about debiasing your software design decisions and the structured interventions you can take to counter them.

Evelyn van Kelle is presenting the part on overconfidence bias. She is, as we speak, absolutely certain our slides are nearly done.

I'm presenting the part on additive bias. I have, as we speak, added three more slides.
...

Here's something worth sitting with: a product owner deciding "the user should never have to re-enter this information" is making an architecture decision. A domain expert saying "that data doesn't belong here" is making an architecture decision. They just don't always call it that.

This is why, when we get to designing how bounded contexts communicate with each other, we don't hand it to the engineers and wait. We do it together, engineers, product people, domain experts in the same room.
...

First day of another DDD foundation workshop, and we hit the wall that almost every team hits: naming.

Not "what should we call this?" — that's the surface question. The deeper one is: how much does a name already decide for you?
...
#DomainDrivenDesign #CollaborativeModelling #BoundedContext #SoftwareDesign

Came across this take recently: "How long until the DDD community realises AI/LLM assisted programming is still DDD, but you no longer need to do the actual implementation, just document & validate it?"

We already do. The bounded context pattern is still very much valid.
...

#DomainDrivenDesign #BoundedContext #UbiquitousLanguage #AIAgents #SoftwareArchitecture

After 2 years consulting DHL eCommerce BeNeLux, I've decided to join them as software architecture enabler.

The reason? I'm simply not done yet. And I wonder if I ever will be.

#DomainDrivenDesign #TeamTopologies #SoftwareArchitecture #CollaborativeModelling #EventDrivenArchitecture
...