Blog

Coach your Architects in Agile Architecture!

When companies transform towards an agile and DevOps way of working, they sometimes ask how to proceed with architects. Some companies ignore architects in their transformation, some will upskill their architects, and some will make the DevOps teams responsible for the architecture. A core problem we see is that those responsible for the transformation have little experience dealing with architecture in an agile way. The agile coaches are concerned with making the organization agile on a process level. The scrum masters are concerned with the agile process on a team level. And in some transformations, the team also has an agile technical coach who teaches the team new practices and techniques from Continuous Delivery, DevOps, and SRE. In contrast, we observe that architects tend only to get training, if any, and no coaching. This article will lay out why it is crucial to rethink how organizations deal with architects and to start explicitly coaching architects when going towards agile architecture. How the role of architects is changing in agile and DevOps The considerable debate in the industry is whether we still require architects when we can make the high-performing software teams responsible for the architecture. That is an ideal situation Read more…

By Kenny Baas-Schwegler, ago

Remote collaborative modelling part 1: Check-in

Collaborative modelling is not only an essential practice in Domain-Driven Design for creating a shared understanding of the domain. I believe it is vital in building sustainable and inclusive quality software. Covid-19 has constrained us to move collaborative modelling sessions online, and for almost everyone, this is uncharted territory and can be quite overwhelming. In these series of posts, I hope to give people some guidance and heuristics to start doing more of collaborative modelling in a remote world so that we can build more sustainable and inclusive quality software. We start this series with a practice that can make or break a collaborative modelling session, a Deep Democracy check-in.

(more…)
By Kenny Baas-Schwegler, ago

EventStorming; Core concepts, glossary and legend

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
(more…)
By Kenny Baas-Schwegler, ago

Making the most out of remote EventStorming

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.

EventStorming Workshop Facilitation | Avanscoperta
Copywrite: Avanscoperta
(more…)
By Kenny Baas-Schwegler, ago

Extending the Bounded Context Canvas with BDD Examples

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.

(more…)
By Kenny Baas-Schwegler, ago

From EventStorming to CoDDDing

We live in a world of constant change. Today we generate more data than we can consume, and it contributes to the constant changes that we observe. Within the IT industry, we have the ambition to create flexible and reliable solutions that can cope with the demand for changes. We created frameworks, new programming languages, and abstracted the management of hardware with the cloud offering. Our industry provides tools and techniques that allow organizations to achieve the promised land of delivering business value to match the changing world. This is why we see many companies make a move towards microservices for mostly the same reasons; creating smaller deployable units, and to achieve a shorter and quicker feedback cycle. Moreover, many companies see the need for Domain-Driven Design to be able to do it. To effectivly do Domain-driven design companies start to do EventStorming to help us to understand the domain better to design better microservices. However, EventStorming can be quite an overwhelming experience. Developers can be left with the question of how to turn a few stickies on a wall into working code. Read João Rosa and mine Xpirit magazine #9 article to know how to go from EventStorming to Read more…

By Kenny Baas-Schwegler, ago

EventStorming cheat sheet

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
(more…)
By Kenny Baas-Schwegler, ago

Cultural needs designing bounded contexts

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.

(more…)
By Kenny Baas-Schwegler, ago

Towards Autonomous Aligned Teams with Domain-Driven Design

I’ve been involved in several transformations over the years, from DevOps to Digital to Agile. These transformations typically focus on transitioning people into near-autonomous teams of no more than eight people who will work in an agile manner. Every company I’ve worked for asks the same questions at these transformations: How do we divide the current software between the teams, and how do we align these teams to our business architecture?To address these questions, companies request my help to design microservices using a Domain-Driven Design (DDD) approach. This approach makes it easier to distribute the software between teams based on identified boundaries, called “bounded contexts.” While I believe enterprises involved in an Agile transformation need at least a Domain-Driven Design approach to create autonomous aligned teams with a loosely-coupled architecture, this process presents unique challenges. For Agile Alliance I have created an experience report where I share my experience over a period of six months using DDD to transition a financial enterprise towards Agile autonomous teams. You can find the report here:

By Kenny Baas-Schwegler, ago