Articles and expert streams

Strategic Integration Design with DDD: A Small Talk with Karol Skrzymowski and Philipp Kostyra 📹 Your integrations grew and nobody designed them! An informal chat with Karol Skrzymowski and Philipp Kostyra to learn more about their upcoming Strategic Integration Design with DDD Workshop, why this topic matters, how the workshop is structured, what problems it addresses, and why people should join. It’s also a chance to hear what Philip and Karol are working on today and to get Alberto Brandolini’s insights on the topic. 🎙 Guests Philipp Kostyra 🐜Karol Skrzymowski 🎙 Moderator Alberto Brandolini 🛜 Info When: Sept 1st, at 7:00 pm CEST Where: live streaming on Youtube or Linkedin 👉 Workshop: https://lnkd.in/ezGgxYWT 🔔 Subscribe to our YouTube channel: https://lnkd.in/dZHa-3Dy 📩 Join our newsletter: https://lnkd.in/dpC_jvKg 🗓 Upcoming Public Events: https://lnkd.in/djY7yTK6

How do we work as programmers, architects? How do we solve problems? What are our ways of working? Is the team we’re on an actual team if we put on our headphones, put music on and everyone focuses on their own ticket in jira? These are a few of the core questions that are the subject of ways of working. How do we work as programmers, architects? How do we solve problems? What are our ways of working? Is the team we’re on an actual team if we put on our headphones, put music on and everyone focuses on their own ticket in jira? These are a few of the core questions that are the subject of ways of working. Most people (not IT) view programming as an activity, where you sit in solitude in front of a computer and write code. That’s it! Done! Software is born and we move one to another project. The reality, as always, is more complex than that. Software engineering is a complex endeavor. While this notion may work for small programs like automating your own workspace, or writing a small app for your phone for your particular needs, this is not how programming works in business environments - it is a collaborative effort. Over the years there have been many approaches to programming, we still do solo programming and then validate it through code reviews. We do pair programming, where the core practice is that we have a pair of people working on a piece of code on the same workstation. Some developers do rubber ducking, where they debug and extend the code through explaining it to inanimate rubber ducky, or a(n) (un)willing colleague. This episode we’ll be a little bit different! Usually we have a conversation, share examples, and discuss a problem. This time around we’ll attempt to solve a problem by coding! And for that part not any kind of coding! We’ll jump right into a practice that originates from eXtreme Programming and goes further! We’ll be doing Ensemble Programming! We have invited two Fullstack Engineers and Ensemble practitioners, James Herr and Arthur Morrow to guide us through the process! Let’s see if together we can solve the problem we prepared!

“We don’t do message brokers and Event-Driven at this company” is what I heard from one client some time ago. I was puzzled, because why would someone discard a whole valid set of architectural patterns? Turns out a few years back they suffered heavily because someone thought they could be like Netflix or LinkedIn and use Kafka. “It worked for those companies - right?” Absolutely! The problem was that this client was not a streaming service and had no use case for streams! The result? Heavy implementation, high cognitive cost for all teams, serious operational problems. “We don’t do message brokers and Event-Driven at this company” is what I heard from one client some time ago. I was puzzled, because why would someone discard a whole valid set of architectural patterns? Turns out a few years back they suffered heavily because someone thought they could be like Netflix or LinkedIn and use Kafka. “It worked for those companies - right?” Absolutely! The problem was that this client was not a streaming service and had no use case for streams! The result? Heavy implementation, high cognitive cost for all teams, serious operational problems. We often look at the success of various companies, their tech stack and think: “Hey! We can do the same thing! It will work because it worked for them!” The problem is that we often do that without looking at trade-offs, added complexity, or even having a valid use case for such technology. This effect is dubbed a “cargo cult”, and while it originates from people’s behaviour in Melanesia during the 2nd World War, it has found its home in IT! Let’s have a chat about one of the most famous cargo cult in Integration Architecture - Kafka! For that we’re bringing to the stream two returning guests: Chris Simon, a technology coach and advisor helping technology teams drive business success. Chris talked about this this year at DDD Europe “It’s like 10000 streams when what you need is a queue” Aaron Lee, a Senior Solutions Engineer at Solace. Aaron will happily discuss event-driven architecture, networking protocols, application design, monitoring, time-series data, and visualization frameworks for as long as you’ll listen. Together we’ll dive into Event-Driven Architecture and when to use Kafka and other message brokers! Join us live!

Does career growth and loyalty happen naturally within business environments? Every business owner would probably wish it did. But is there any truth to such wishful thinking? Can a person’s career in a business be anything more than just an employee-employer relationship, where both parties merely benefit from their contractual agreement? Does career growth and loyalty happen naturally within business environments? Every business owner would probably wish it did. But is there any truth to such wishful thinking? Can a person’s career in a business be anything more than just an employee-employer relationship, where both parties merely benefit from their contractual agreement? How can we facilitate empathy and compassion into our career paths? How can we deal with extremely long feedback loops, and delayed gratification of seeing the results of your efforts? Is it worth the time and effort to care? All of these are valid questions, especially in times where human connection is often disappearing behind digital screens and all sorts of apps that are supposed to support collaboration. To talk about all of this, our next guest is Hannes Lowette, a developer turned mentor, coach and a person contributing to the learning culture at Axxes for the last 15 years. He finds that careers not being a zero sum game is something to reach for and we can all win! He believes that bringing empathy and compassion to the job can change people’s growth tremendously! As he says: “I get out of bed to help others succeed.” Join the discussion!

AI is changing far more than how we build software. It is fundamentally reshaping the craft and our identity. As AI commoditizes specialist skills, developers and architects are shifting toward new perceptions of their roles - reviewers, orchestrators, and stewards of autonomous systems. For many, this transition sparks excitement, while for others, it brings uncertainty. In an era where the pace of AI leaves little room for reflection, we find ourselves consuming more knowledge but often feeling less connected to our work, our colleagues, and ourselves. AI is changing far more than how we build software. It is fundamentally reshaping the craft and our identity. As AI commoditizes specialist skills, developers and architects are shifting toward new perceptions of their roles - reviewers, orchestrators, and stewards of autonomous systems. For many, this transition sparks excitement, while for others, it brings uncertainty. In an era where the pace of AI leaves little room for reflection, we find ourselves consuming more knowledge but often feeling less connected to our work, our colleagues, and ourselves. In this episode, we’ll explore identity through an architectural lens. We'll discuss how our professional identity can be understood as an architecture, where its coupling to the world and internal cohesion evolve alongside our environment. Drawing on concepts from cognitive science, complexity theory, and sociotechnical practices, we’ll examine how to consciously redesign our coupling with the world to discover a deeper sense of lived fittedness between who we are, what we do, and the possibilities AI creates. We’ll tackle critical questions: How do we transition our craft from writing code to designing sociotechnical systems? Where do human judgment, design, and modeling become even more valuable? How do we consciously reshape our coupling with the world and maintain cohesion? What practices help us stay connected to ourselves and others during this transition? This stream, our guest will be Xin Yao, a Sociotechnical architect and change facilitator, who will help us explore what it means to not just survive the AI era, but to thrive within it. Join us in the discussion as we apply architectural thinking to ourselves, and learn how to navigate the transition toward greater professional and personal cohesion.

We communicate daily. It’s easy if we use the same language, work in the same context. The reality is, we really don’t - we live in different contexts and use different languages even if we all speak English - our internal dictionaries, mental models and jargon differ. We communicate daily. It’s easy if we use the same language, work in the same context. The reality is, we really don’t - we live in different contexts and use different languages even if we all speak English - our internal dictionaries, mental models and jargon differ. Jargons differ, especially at work. We would like to have cohesive languages to communicate with between all lines of business, all units, departments, etc. The facts are that we don’t have them, we all assume we understand the same terms the same way, and that creates a lot of friction and confrontation. The same applies to architecture fields - and this is very visible when we compare Data and Integration Architecture and how specialists in those fields communicate with each other. Best example, a Loosely Coupled episode we did in August last year (https://www.youtube.com/watch?v=JaCuv8gRnJg), where we had so much trouble with understanding the terms we used. This episode we’ll dive back into the topic of Data and Integration Architectures and try to find where we have mismatches! Hopefully we can create a common dictionary translating between the two worlds! To help us in the endeavor, joining as a guest is Andrew Jones! Returning to the stream to have yet another lost in translation moment. Join us in the discussion! Post your terms in advance! Let’s see how many mismatches we can find and solve!

Testing has always been a part of work in many engineering fields. IT is no exception. Methods differ between different fields. The idea of testing software is not a new concept, but is probably as misunderstood as many other concepts! For some it is running a SoapUI test suite, for others it is a collection in postman. Then we have test cases and scenarios. All of this culmination to the false notion of 100% test coverage. Testing has always been a part of work in many engineering fields. IT is no exception. Methods differ between different fields. The idea of testing software is not a new concept, but is probably as misunderstood as many other concepts! For some it is running a SoapUI test suite, for others it is a collection in postman. Then we have test cases and scenarios. All of this culmination to the false notion of 100% test coverage. Let’s talk about a broader picture! How testing actually can shape software and change the way we work on it to boost that ‘fail fast’ approach and create short feedback loops! For this purpose our next guest is Ted M. Young, a seasoned software developer with a knack for Test-Driven Development. Together we’ll dive into TDD, what that is and how to apply it! This time with a twist, because Ted is bringing his game to the stream - JitterTed’s TDD Game! We’ll be learning by playing! So let’s dive in and see how collaborative small steps can get us further than scatter-gather isolated approaches. Join us live!

IT professionals composing the current workforce were mostly educated in a Prussian classroom model, that aimed to produce manufacturing workers that follow commands, not think creatively. Over the last few decades we see a lot of movements trying to change that. Unfortunately for us, we’re making education a lot harder with advancement of technology and that technology invading schools and universities. In the age of AI education is suffering and at the same time it is more and more important that we educate better. This episode we’ll tackle the topic of how to educate young IT professionals in a world that is moving faster than we can comprehend. We have access to near-infinite knowledge through the Internet and AI chatbot. We also struggle with misinformation, hallucinations and lack of comprehension! The key question is: what good is all that information if we are incapable of using it in context? IT professionals composing the current workforce were mostly educated in a Prussian classroom model, that aimed to produce manufacturing workers that follow commands, not think creatively. Over the last few decades we see a lot of movements trying to change that. Unfortunately for us, we’re making education a lot harder with advancement of technology and that technology invading schools and universities. In the age of AI education is suffering and at the same time it is more and more important that we educate better. This episode we’ll tackle the topic of how to educate young IT professionals in a world that is moving faster than we can comprehend. We have access to near-infinite knowledge through the Internet and AI chatbot. We also struggle with misinformation, hallucinations and lack of comprehension! The key question is: what good is all that information if we are incapable of using it in context? Let’s tackle the problem of education! This stream our guest will be Chelsea Troy, Machine Learning Operations Engineer at Mozilla, who is also an adjunct associate professor of University of Chicago. Chelsea is teaching machine learning, data analysis and programming and has a first hand view on the future of our IT workforce. Join us in the discussion and learn how can we change the approach to professional learning to fit the current age.

What makes an API more than a specification and an implementation? Einar Waaler Høst joins Karol Skrzymowski to explore the social and technical patterns that shape an API throughout its lifecycle.

For decades, the practice of software architecture has relied heavily on blueprints and models borrowed from traditional, static engineering disciplines. But in today's landscape - where systems are increasingly distributed, services are ephemeral, and change is the only constant - do those old analogies still hold up? We’re finding that the lines and boxes we draw on diagrams often fail to capture the complex, human, and messy reality of integration. If the old ways are failing, how do we find a new philosophical foundation for our profession? For decades, the practice of software architecture has relied heavily on blueprints and models borrowed from traditional, static engineering disciplines. But in today's landscape - where systems are increasingly distributed, services are ephemeral, and change is the only constant - do those old analogies still hold up? We’re finding that the lines and boxes we draw on diagrams often fail to capture the complex, human, and messy reality of integration. If the old ways are failing, how do we find a new philosophical foundation for our profession? Architecture, as a profession, is at a crossroads! Joining this live stream is Barry O'Reilly, creator of Residuality Theory. Together we’ll challenge the fundamental assumptions about what it is to be an architect! The argument is that our profession has leaned too heavily on traditional engineering - a model that is failing in the age of distributed systems, AI and the unstable relationship between IT systems and business environments. Join us as we explore the implications of Residuality Theory and redefine what it truly means to be a modern architect in a world where architecture is more and more distributed. Tune in for a profound conversation about the future of the architect's role and why we need to shift our thinking and approach.

Is design still relevant in the age of AI? Is AI capable of replacing domain experts, architects and developers? Where are the limits? How do promises of companies providing us with Large Language Models hold up to the reality of software design and development? Is design still relevant in the age of AI? Is AI capable of replacing domain experts, architects and developers? Where are the limits? How do promises of companies providing us with Large Language Models hold up to the reality of software design and development? This time around we have no idea what will happen! We’ll be coming live from DDD Europe 2026 in Antwerp! There is an amazing line-up of speakers talking about the future of business aligned software design and tackling complexity at the heart of software! We’ll be inviting various speakers to join us in a panel discussion! Curious what the top experts in the field think about what the near future holds for organizations, architects, developers… Is design dead, or more relevant than ever before? Tune in and join the discussion!

“Nothing is certain, but death and taxes” is what I heard so many times. The truth is that “Nothing is certain but change.” And change seems to be happening faster and faster. There are two architectural characteristics that we can use to describe said change: volatility and variability. “Nothing is certain, but death and taxes” is what I heard so many times. The truth is that “Nothing is certain but change.” And change seems to be happening faster and faster. There are two architectural characteristics that we can use to describe said change: volatility and variability. Nowadays we move faster and faster to catch up with the reality of the market, hype cycles, needs and wants of ‘the business’. We finally managed to understand that variability is the second hardest problem in software architecture, and volatility is only making it worse. Then came the age of ‘AI’ tools, bringing new products, new ways of working, a new hype to have a race in. We’re moving faster or at least it seems like it is so. The question is, how can we keep on going? How can we figure out what to do and not break things that we shouldn’t be breaking? Joining us this session are Andrew Harmel-Law, a highly enthusiastic, self-starting and responsible tech principal at Thoughtworks. Together we’ll dive into further exploration of variability extending the conversation from DDD Europe 2025. We’ll dismantle the shift in the problem space of architectural variability and how to make the right decisions at the new speed! Join us live in this discussion!

The modern Architect is often seen as a master of technical trades, but what if the most crucial 'technology' they need to master isn't a framework or tech stack, but purpose itself? The role of the architect is in constant flux, moving beyond purely technical aspects to driving core business strategy and delivery. It's a fundamental change, and to succeed, we need to redefine what the role should be in a modern enterprise. The modern Architect is often seen as a master of technical trades, but what if the most crucial 'technology' they need to master isn't a framework or tech stack, but purpose itself? The role of the architect is in constant flux, moving beyond purely technical aspects to driving core business strategy and delivery. It's a fundamental change, and to succeed, we need to redefine what the role should be in a modern enterprise. Joining us this session is Paul Preiss, CEO and Founder of IASA, a global association dedicated to building a unified architecture profession and standardization of architectural practices focused on the business purpose of the profession. Together, we’ll dive into the essential pillars of the modern architect’s function, exploring: • The evolving role of the architect and how to ensure its relevance over time. • Achieving enterprise standardization without stifling necessary innovation. • The imperative of teaching in a technology-agnostic manner, • Strategies for strong alignment of the architect’s function with explicit business purpose and corporate strategy.

“I didn’t go to IT to work with people!” is something that I have heard from colleagues time and time again when I was in university and later on a junior developer. From the perspective of time, I think this was a statement that led a lot of them to trouble instead of growth within the career they chose. As software developers, engineers, architects can we really afford to work in isolation? Is it possible to grow in such a case? “I didn’t go to IT to work with people!” is something that I have heard from colleagues time and time again when I was in university and later on a junior developer. From the perspective of time, I think this was a statement that led a lot of them to trouble instead of growth within the career they chose. As software developers, engineers, architects can we really afford to work in isolation? Is it possible to grow in such a case? If I look at my work right now, especially from the perspective of Integration Architecture - my work is dependent on so many people, so that already invalidates the statement, but to truly grow, it requires something different - a community of peers that can put what you do every day into perspective! In this episode of Loosely Coupled we’re joined by Vinicius Albano, a Software Architect, AI Systems Engineer. Vinicius is also the founder of DDD Brazil, a rising community of interdisciplinary specialists sharing their experiences and making them a practical learning - not just theory, but a means to align business and engineering, especially in the age of AI. Together we’ll explore the various aspects of creating and contributing to an IT community and dive into: The importance of a community for your career growth, How communities support learning and change your approach to various aspects of technology, architecture and collaboration, The hurdles of starting a community and what does that really mean,

In meetings with non-technical stakeholders an image can speak a thousand words. In that case a simulation speaks hundreds of thousands! While we’re dealing with technical details, implementation, environment problems, quality is not something done only bottoms-up. It is also something that needs to be explained and supported top-down. In meetings with non-technical stakeholders an image can speak a thousand words. In that case a simulation speaks hundreds of thousands! While we’re dealing with technical details, implementation, environment problems, quality is not something done only bottoms-up. It is also something that needs to be explained and supported top-down. Quite often, when faced with the speed versus quality trade-off we unwillingly stumble into a fallacy that gets many teams stuck in negative feedback loops - sacrificing quality for speed. As a result both are lost sooner or later. Teams find their backlogs filled with bugs, their stakeholders frustrated by missed deadlines and the teams themselves unhappy and stressed. In this episode of Loosely Coupled we’re joined by a defender of technical excellence - Chris Simon! Coming back to the stream, Chris will guide us through the path of Systems thinking, and in particular using causal loop diagrams to identify the feedback loops at play that can shed light on how and why the fallacy is so tempting yet so destructive. We’ll dive into the building of a range of causal feedback loops to visualise the underlying causes of problems. We’ll also experiment a bit, to practice framing the causality, so we can use such visualisations to advocate for the practices of technical excellence that counter the pressures of the fallacy, such as collaborative modelling with domain-driven design, test driven development and living documentation.

Ever shipped a "small change" that broke half the system? Or this tiny change that touched more systems than anyone would think humanly possible? Hours of debugging, analyzing dependencies, managing not-exactly-happy stakeholders only to realize that all of this could have been avoided by putting a little bit more effort before making the change! And then, what about security and the blast radius of a breach? Ever shipped a "small change" that broke half the system? Or this tiny change that touched more systems than anyone would think humanly possible? Hours of debugging, analyzing dependencies, managing not-exactly-happy stakeholders only to realize that all of this could have been avoided by putting a little bit more effort before making the change! And then, what about security and the blast radius of a breach? If you haven't experienced those things, you must be either extremely lucky or new on the job - either way, this live stream will be also for you! In this episode we’ll be taking a deep dive into Impact Analysis - a powerful discipline that can save a lot of time and stress if done in the right time and stage of a project, and how it can help stop things from happening! In this episode of Loosely Coupled we’re joined by Frédérique Mounier, a former communications manager that switched to IT, and now works as a Salesforce Solution Architect and a member of The Adecco Group Tech Design Authority! She’ll be our guide on navigating the potential blast radius and a structured approach to dealing with it, hopefully before it swoops up half of the IT landscape! Together we’ll explore: What is impact analysis and why it matters, What problems we can solve with it, How to approach it without making it a document dense nightmare, When should it be done, Whether you're a developer, tech lead, or project manager, you'll leave with a practical framework you can apply the next day.

Have you seen or read “The Twelve Tasks of Asterix”? Do you recall "The Place That Sends You Mad" task? While this is most of all a joke on bureaucracy, you can also think of it as living in an environment without communication. Regardless of the mechanics behind – paper documents delivered to the offices by internal messenger, pneumatic tubes system, modern computer network, Telepathy data transfer – the problem is that data is not flowing from one involved party (office) to the other. As a result, no work is being done and finally the system collapses when disturbance is introduced (it is the purposeful action of Asterix in the movie/comic… but could be anything in the real world).

How many times have you felt like architects are sitting somewhere in an ivory tower, making decisions disconnected from the reality of messy IT ecosystems? Decisions are made, not aligned, not understood, not enforced. Months later people ponder on what went wrong. How many times have you felt like architects are sitting somewhere in an ivory tower, making decisions disconnected from the reality of messy IT ecosystems? Decisions are made, not aligned, not understood, not enforced. Months later people ponder on what went wrong. What if there is another way? What if we could make the process more aligned with business needs and the organization as a whole. At the same time making the right people involved and sharing common understanding of the problem domain instead of making unnamed and unspoken assumptions about what is being delivered? In a corporate environment we usually have many teams working on different business cases. That by itself usually requires different architecture approaches. Sustainable architecture is a result of an ongoing process aiming to align the siloed approaches done by different teams. What if the balancing mechanism to achieve this is not by having the architect as an explicit role, but instead by facilitating architecture through technical coaching. Joining us in this session is Mufrid Krilic, Domain-Driven Design Coach. He’ll guide us through how technical and modelling excellence can bring value to organizations on all levels. We’ll explore real world examples and stories about scaling organizations and challenges in maintaining sustainability in architecture and alignment processes! Join us in this important conversation!

One of the things that many architects learn early when they switch from a developer role is that there is a shift in the scope of work they do and the understanding they need to build to be effective. This shift is moving away from the technology they know and worked with towards understanding their business. That is a difficult shift, because as engineers we’re wired and conditioned to provide solutions rather than deep dive into problems. “Don’t come to me with problems! Bring me solutions!” - a phrase often said by managers, which is supposed to boost ownership, mostly discourages critical thinking and finding the root cause of the actual problem. One of the things that many architects learn early when they switch from a developer role is that there is a shift in the scope of work they do and the understanding they need to build to be effective. This shift is moving away from the technology they know and worked with towards understanding their business. That is a difficult shift, because as engineers we’re wired and conditioned to provide solutions rather than deep dive into problems. “Don’t come to me with problems! Bring me solutions!” - a phrase often said by managers, which is supposed to boost ownership, mostly discourages critical thinking and finding the root cause of the actual problem. To equip you with tools, we’re continuing the journey into collaborative modelling as a means of understanding problem domains! In this session, we will dive deep into Domain Storytelling, a powerful technique that can give us insights into how people work together and help us transform domain knowledge into business software! Telling stories is the most basic form of human communication. To tell a story, we invited Woody Zuill, a Lean and Agile Guide, to serve as our Subject Matter Expert. And as we dive into collaborative modelling based on the story, we’re being guided by two experts to help us capture the details and ask questions: Dr. Annegret Junker, Chief Software Architect @ codecentric AG, and Fabrizio Lazzaretti, Managing Consultant @ Wavestone! If you wish to learn how to dive into understanding the problem domain, join us live!

“Because we’ve always done it this way” - is a phrase I hear quite often in my line of work, because I usually got places where a change is needed. This is decision-making driven by habits, blindly following best practices or latest trends. The problem? No one took time to understand the problem domain, build up context, and check if this workflow applies to the current situation! Through that we get overcomplicated solutions, before a single service is actually deployed. In an earlier episode with Woody Zuill we were discussing the differences between problems, symptoms and how they should be used as signals. This session, we’ll be taking a dive into decision-making and to guide us we’ll have someone who is very passionate about the topic: Gien Verschatse, a Consultant from Aardling. As a side project, to which she refers to as ‘getting slightly out of hand’, she is researching the science of decision-making strategies, which aims at helping teams improve on how they make all sorts of decisions! In this episode we’ll talk about the importance of critical thinking in decision-making and the way that decisions are made, probably define a few terms that are not commonly known, and discuss tools to help us on the decision-making journey! “Because we’ve always done it this way” - is a phrase I hear quite often in my line of work, because I usually got places where a change is needed. This is decision-making driven by habits, blindly following best practices or latest trends. The problem? No one took time to understand the problem domain, build up context, and check if this workflow applies to the current situation! Through that we get overcomplicated solutions, before a single service is actually deployed. In an earlier episode with Woody Zuill we were discussing the differences between problems, symptoms and how they should be used as signals. This session, we’ll be taking a dive into decision-making and to guide us we’ll have someone who is very passionate about the topic: Gien Verschatse, a Consultant from Aardling. As a side project, to which she refers to as ‘getting slightly out of hand’, she is researching the science of decision-making strategies, which aims at helping teams improve on how they make all sorts of decisions! In this episode we’ll talk about the importance of critical thinking in decision-making and the way that decisions are made, probably define a few terms that are not commonly known, and discuss tools to help us on the decision-making journey!