Thoughts on organizing architecture

When being part of an enterprise, you will meet different architects on any given day. The first one introduces itself as a solution architect, the other calls itself the enterprise architect, and they both mention a domain architect. It might feel like different names for the same thing, and perhaps even a bigger question, do we even need all of these different architects? Should the team not be able to make all of these architectural decisions by themselves?

Read more →

EventStorming as a cultural assessment

We are on a quest…

As consultants, we are not only challenged by the technical challenges our customers face, but also how it affects the organisational structures and the culture. Based on our experiences, EventStorming is a great technique to expose the underlying cultural aspects of an organisation, while focusing on the value streams and technology. In this post, we are sharing what we have learned, by giving examples from our experiences that hopefully inspire you to use EventStorming as a cultural assessment.

Read more →

Mental models: a reflection on AWS outage

In November 2020 AWS had a major outage, which started with their Kinesis service, having a cascading failure over some services. Several articles and analyses of the outage, including the official note from AWS. This blog post reflects the outage, but rather focus on the technical aspects, I will deep dive into the social ones, namely mental models.

Read more →

Organisational structures to create autonomy: what I’ve learned from my daughter

I’m grateful to learn from my daughter. Be able to see how the brain develops and picks up new concepts, skills and words. Nowadays, I enjoy to sit down and watch her play. As a parent, I also need to help her to achieve her autonomy: emotionally, mentally and physically. It is the job, and my wife and I are navigating through it. There is not a guide on how to parent, and we discuss what is working and what is not working. Sometimes is just not the time for a new skill, other times our daughter doesn’t develop an interest for a particular activity. Well, we are all different, and that is what makes the world colourful!

Read more →

Diverge and converge to create a Context Map

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. 🙂

Read more →

Chaos Engineering as management practice

Chaos Engineering is a practice that has its roots at Netflix. It born from the challenges of moving their workloads from the data centre to the cloud; the transient nature of the cloud affected the way that they build and operate a system at scale. The initial project was called Chaos Monkey, and it has almost 10 years.

Since then the community grew, fueled by Netflix practitioners. Today there are commercial and open-source tools, and we can see more initiatives in different communities. The technical practices had matured, and the knowledge started to spread in the IT world.

However, it is deemed perceived as a technical practice. Can we leverage Chaos Engineering as a management practice?

Read more →

Using Team Topologies to discover and improve reliability qualities

Team Topologies is the work of Matthew Skelton and Manuel Pais, and I use it as part of my job. From a sociotechnical perspective, a team-first approach is paramount for any organisation and helps to decrease the accidental complexity. As such, I’m often asked “How can we operate in DevOps?” or “How can I have a reliable service to deliver value to my customer?”.

Read more →

Why Integration Tests won’t save you… or your software

Did the title tease you? Great, job is done! Today I will tell you my story about Integration Tests; it came after another knowledge share lunch with my pal Kenny.

By this definition an Integration Test is

(…) the phase in software testing in which individual software modules are combined and tested as a group. Integration testing is conducted to evaluate the compliance of a system or component with specified functional requirements. It occurs after unit testing and before validation testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready forsystem testing.

Sounds pretty waterfall, right? It is! also, the implementation approaches that I observed creates huge dependencies between teams, coupling the software release process.

Read more →