Talking about the added value of applying Agile Architecture in your organization, we see fewer and fewer “IT architects” in organizations. Is that because we do not need Architects anymore?  

Great landing, wrong airport

I read this phrase a while ago and it got to me. It fitted the projects I was working on. <Enter attentional bias>.  These organisations I was working with were building great solutions (technically). Unfortunately, not always what their customers were expecting. It confirmed for me that Systems Thinking is really important. Combined with some new insights from behavioural sciences, you will land at the right airport.

Small side confession: reading this phrase triggered two things in me.  

• A memory of that time I planned a fun getaway to Mallorca with a friend but ended up at the wrong ‘Weeze airport’. Which made me think of changing this title to “Great holiday plan, wrong airport”. 
• The realisation that this phrase beautifully articulates the million-dollar question: ‘Which problem are we actually solving with this solution?’  

Although the story of the first is – in hindsight – brilliant, I’ll focus on the second one in this post.  

Context Map was the first visualisation for the Bounded Context pattern from Domain-Driven Design. In a nutshell, it is a map of the different Bounded Contexts and their relationships. I tend to create a Context Map during or after a Big Picture EventStorming. Changing perspectives can be helpful, to challenge assumptions and get the best of different techniques.

However, sometimes it is hard to reach a consensus on the Context Map. I often operate in brownfield projects, with large organisations. Although people agree with the different bounded contexts, it is a process that takes time, and most significant energy. Which can lead to fatigue towards the method, and at the same time raises exciting patterns in the behaviours. But this blog post is not about emergent behaviour. 🙂

Recently on Twitter Chris Richardson asked if anyone has created a consistent and comprehensive glossary for EventStorming core concepts.

I replied saying that #EventStorming is fuzzy by design. There are standard core concepts, and depending on the context, we use different words for the post-its. Because with that fuzziness, you get more insights. I call it just enough structure to let transactional conversations flow and create a shared mindset and tons of new insight—a shared pool of understanding. However thinking back at past workshops, and from skimming the EventStorming book checking out the core concepts, Chris has a point, we lack an excellent consistent glossary of the core concept, also specific per type. This post describes my take on EventStorming core concepts written down in a consistent and comprehensive glossary. Just be sure to try and avoid jargon as much as possible, as it sets up the unnecessary insider-outsider distinction.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

A while back the virtual Domain-driven design meetup experimented with doing a remote EventStorming. The outcome was that doing remote EventStorming as you would do it offline is sub-optimal. The interaction was lacking during the storming parts, and the number of insights gained was lower. That is the power of EventStorming, and it was not present. Still, we asked ourselves how we can make remote EventStorming more optimal, and with most of the world being stuck at home due to corona, I started experimenting with it. In this post, I will describe heuristics about my first experience with remote EventStorming.

Ever since Nick Tune introduced the world to the Bounded Context Canvas, I incorporate it in my workshops and trainings. Nick sees the canvas as a checklist for designing our Bounded Context canvas. For me, it is also perfect as a visualisation tool to make the Bounded Context explicit. The one thing I am missing is examples in the form of acceptance criteria discovered and eventually formalised during our Behaviour Driven Development flow. In this post, I explain how I extended the Bounded Context Canvas with BDD examples from Example Mapping to show how to formalise the behaviour of a Bounded Context.

By Paul de Raaij & Evelyn van Kelle

Software development is at the core of most companies. We’re all digital enterprises that need to understand how technology is heavily influencing our core business and can make or break our competitive advantage. Making the right decisions when it comes to investing in technology has become a crucial skill for digital leaders. 

“Once we start judging, we stop learning.” I’ve always been a big supporter of continuous learning, and as a social scientist I know how easily we get trapped in cognitive bias and heuristics. That’s why I’m convinced that it’s crucial to continuously challenge your own perspectives, opinions and judgements. 

That is why I decided to join the DDD Foundations training at Xebia. 

EventStorming is the smartest approach to collaborate beyond silo boundaries. The power of EventStorming comes from a diverse multi-disciplined group of people who, together, have a lot of wisdom and knowledge. While it originally was invented for a workshop to model domain-driven design aggregates, it now has a broader spectrum. From gaining a big-picture problem space of the whole domain to gaining insight into the entire software delivery flow and creating a long term planning. Every one of these workshops has the same basic requirements and needs. In this EventStorming cheat sheet post, I will describe these basic requirements in a cheat sheet.

I have moved the content of this blog to the DDD-crew GitHub page, were it will be updated by the community.

https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet

Read more →

Without a doubt, the bounded context pattern from Eric Evans book domain-driven design is one of the more essential patterns for designing and building modern software. Especially in the land of microservices architectures, where setting proper bounded context which is highly linked with the business goals aka the domain is essential to not get into the distributed monolith anti-pattern. The bounded context is in its core a language boundary, a boundary where language can stay consistent and which is the boundary of the model designed for a purpose. Boundaries for people are crucial from a culture perspective. People cannot live without boundaries; it is a way in which we can define our self and separate us from the rest. To define our self creates an identity, a feeling of belonging which in time can create ownership. However, to be able to define our self, we must also define the others to keep our own identity. When we look at cultural anthropology, we traditionally did this on the border through get-togethers like marketplaces, where we exchange goods. Now if we want to keep the cultural benefits of the bounded context within our company, we must also take care of the cultural needs designing bounded contexts. In this post, I describe these culture needs when using the bounded context pattern.

Read more →