Join the conversation

We're back after summer with a hands-on workshop by Karol Skrzymowski about using DDD context mapping as the starting point to choose integration patterns that are fit for purpose, then pick the technology.

Workshop: Sociotechnical Application Integration using Context Maps by Karol Skrzymowski

Most application integration failures aren't caused by choosing the wrong message broker or IPaaS technology. They happen because the technical architecture ignores the sociopolitical reality of the teams involved, or organizations ignore the sociotechnical aspects of what they try to introduce in their IT Ecosystems. What happens if you implement a high-trust Shared Database between teams that have a low-trust Customer/Supplier relationship? Most likely your system will shatter the moment one team changes a schema without asking.

In this hands-on lab, we will address this mismatch by explicitly mapping DDD Context Mapping patterns (the social boundaries) to Ecosystem Architectural Styles (the technical implementation) and related integration patterns. We won’t just discuss "trade-offs"; we will apply design heuristics that are useful in real-world scenarios involving a range of systems, from legacy ERPs to modern microservices.

You will learn to operationalize mappings like: • Partnership, where the relationship allows for the tight coupling of synchronous calls. • The Conformist relationship in which the upstream team has no motivation to support you, so it requires a strictly defensive Anti-Corruption Layer (ACL) within the consumer. • Open Host Service, that creates reusability, but not always allows for loose coupling as scale. • Interchange Context relationships, where integration is extracted from domain systems and implemented as middleware!

This session is designed for architects who are tired of guessing how to integrate systems. You will leave with a range of heuristics on how to explore and identify the risks to integrations stemming from the political landscape of your IT ecosystem. This will give you the vocabulary to express those risks and relationships, and to design for a better future, based on the domain boundaries, not just the technology stack.

🚋 About the Host & Location 🌍 Big thanks to the people at QWAN (Quality Without a Name) to host us this time.

Location: Space to Create on the Utrecht Stationsplein Room: Olympic Space 2 https://spacetocreate.nl/routebeschrijving-utrecht/

At QWAN, they take a systemic approach to support software development organizations to become better at what they do and more fun places to work for. Their approach is grounded in systems thinking, Domain Driven Design, DevOps, agile and lean approaches like eXtreme Programming, Kanban, Scrum, and test driven development. They always keep an eye on the goal: delivering valuable software better, faster, with more joy.

🕖 Schedule 🕙 17:00 - 17:45 Doors open, welcome with food and drinks 17:45 - 18:00 Welcome by our hosts 18:00 - 20:30: Workshop Sociotechnical Application Integration using Context Maps by Karol Skrzymowski 20:30 - 21:00: Social drinks + networking

🎯Target audience 👥 You have an interest in Domain-Driven Design, want to learn more about it, or want to share your experiences with others. Feel free to drop a comment if you're not sure if you should attend.

🍝 RSVP correctly for your fellow members and host 🍕 Please ensure that you update your RSVP. We understand that attending a meetup isn't always possible even though you wanted to come. Throwing away food is just waste, so feel free to change your mind but update your RSVP accordingly :-)

In today's distributed IT world APIs are everywhere! We use them to send statuses, query data, post social-media posts, and most of all we use them in systems in our organizations. But do we really understand the landscapes they create?

In today's distributed IT world APIs are everywhere! We use them to send statuses, query data, post social-media posts, and most of all we use them in systems in our organizations. But do we really understand the landscapes they create?

Let’s discuss why an API catalog is only a starting point! How can OpenAPI and AsyncAPI contracts, quality checks, enterprise architecture, ownership, and runtime relationships be connected? Can we digest this knowledge and derive more meaning out of it?

Joining us this session is Daniel Kocot, Principal Integration Architect @ adorsys, and together we will take a look at what a graph-based knowledge layer makes possible. Can we, using the API Knowledge Stack as a practical example, follow the path from an API definition and a quality finding to an actionable view of the API, its context, its responsibilities, and its next steps.

We’ll be also looking beyond discovery: how APIs can become curated API products, how teams can preserve the intended use and trust, and how organizations can keep their knowledge useful without turning governance into bloated bureaucracy.

How do we move from knowing where an API is to understanding what it means and what to do with it?

Join us in the discussion!

We have a tendency to call something "technical debt", perhaps even register it in some sort of a log, and move on. That is what is happening most of the time. Business requires immediate action. We refer to the “Quality, time, cost” triangle and say “choose two”. The result? Business wants it fast and cheap - quality suffers. And the worst part is that this tool has been already changed and misused so much that no one remembers what was the original “iron triangle”.

We have a tendency to call something "technical debt", perhaps even register it in some sort of a log, and move on. That is what is happening most of the time. Business requires immediate action. We refer to the “Quality, time, cost” triangle and say “choose two”. The result? Business wants it fast and cheap - quality suffers. And the worst part is that this tool has been already changed and misused so much that no one remembers what was the original “iron triangle”.

This is how we create “technical debt”, which can have a multitude of forms. Corner cutting on development, not having full test coverage, or having implicit architecture simply by building instead of designing first.

This session we’ll be diving into Architectural Debt, which may be mistaken for “technical debt”. While it is similar it often has far more severe delayed consequences. This is the kind of debt that can go unnoticed until everything starts breaking down - impacting the most meaningful programs and projects, and in the end business flexibility and adaptability to the business reality. It is not visible in code, you cannot trace it to a single repository, or domain system! These are our architectural decisions, exceptions, duplicated capabilities, temporary solutions (that live forever), architectural compromises and more.

To talk about the impact of Architectural Debt we have invited Nadzeya Stalbouskaya, Co-Founder, Enterprise Architecture & Transformation Adviser. Together we’ll discuss the various aspects of Architectural Debt, how to identify it, how it manifests and what that means for organizations.

Let’s discuss how to manage it without making Enterprise Architecture a bloated bureaucratic sinkhole!