Mergers leave behind a particular kind of mess. Different teams, cultures and architectures all suddenly report to the same CTO, and nobody’s quite sure what exists, who owns it, or who to go to if something breaks.
In a recent episode of the Dear Architects podcast, Luca sat down with Mahdi, a tech leader at Fashion Cloud, to talk about how they untangled this complexity. None of it started with someone holding an architect title. It started with a handful of tech leads deciding the problem was theirs to fix.
👗 Meet Fashion Cloud
Fashion Cloud is a B2B wholesale platform between fashion brands and retailers. Before it existed, a retailer with hundreds of brands had to maintain hundreds of separate integrations, some of which were phone calls and emails.
The company came out of a merger between an Amsterdam order-placement product and a Hamburg content delivery system, followed by two more acquisitions, the latest a digital showroom product in 2023. Today, it covers the full wholesale lifecycle with around 50 engineers across 6 teams.
🔦 Step one: find out what you actually have
After each merger, the first question was simple: what systems do we even have, and what problems do they solve?
There was no top-down mandate. The only real driver was a pain point. Nobody knew what they were responsible for, and incident response got messy because people weren’t sure whether an alert was theirs. So three or four tech leads treated it as a design problem and went to work.
They used a deliberately light version of domain-driven design: identify the domains first, add subdomains only where they covered the 80/20 of each team’s critical paths, and let the rest come naturally.
Each tech lead ran workshops with a set of teams. Over about six months they collected what they called the narrative, which was really a C4 model story under a different name. It stuck to Level 1 (Context) and Level 2 (Container), and asked four questions:
- Who are your customers?
- What does your system do?
- What systems do you have?
- What systems do you depend on?
For an organisation-wide picture, you only need the tip of the iceberg.
🧱 Finding the right way to slice it
The tech leads tried tiering services by dependencies and grouping them by domain. What actually worked came from listening to the sales team, who used the word “platform” for almost everything. The team leaned into that and split the landscape into two lists: platform services and individual products.
Choosing what counted as platform was based more on instinct. Product data came first, since it’s Fashion Cloud’s largest dataset and every product relies on it. Shared entities like users, organisations, brands and retailers followed.
Once the picture was agreed upon, conversations got easier. If someone wasn’t sure an alert was theirs, Mahdi could point at a box: that’s yours. If code sat in the wrong codebase, the same diagram showed where it should move.
🔄 From Miro to IcePanel
The narrative started in Miro, which worked until it didn’t. Linked frames drifted out of date, people copied and pasted whole diagrams to change one part, and showing ownership meant Mahdi manually pasting sticky-note tags onto every object.
He’d come across IcePanel a few years earlier, before he was doing architecture work. When you’re not doing architecture, they really are just boxes. This time he started a trial, moved some diagrams over and showed them around. The response was, “can we keep using this?” Now they update the Model once, and every diagram stays in sync.
📝 Keeping it alive
Diagrams covered the what. For the why, the tech leads defined a set of cross-cutting concerns that need an architecture review, like adding a new technology or creating a new domain or data model. Changes that touch them are written up as ADRs, using a template.
To keep the model current, they came at it from two sides:
- Governance: every ticket’s acceptance criteria includes a checkbox asking “Does my task require changes in IcePanel?”
- Real usefulness: in refinement and architecture review sessions, the developer leading a project prepares their plan as Flows and Drafts in IcePanel. The team clicks through it together.
Mahdi tells developers that documentation is like a ticket status: it’s for other people, not for you. On one CRM project, the lead engineer kept the diagrams current, so when Mahdi was pulled into meetings with management he could pull up the live plan and explain it on the spot. Without it, he’d have had to say “I’ll get back to you.”
There’s no dedicated architecture team. Anyone can propose a change. If it touches a cross-cutting concern, they draft an ADR and tech leads self-assign based on scope. If not, the team talks it through, even in a stand-up, and gets on with it.
🤖 Let chaos reign, then rein chaos in
On AI, Fashion Cloud is experimenting freely, and two results stood out:
- Documentation: after building a new service with an AI agent, Mahdi used IcePanel’s model-as-code functionality to generate its model objects and connections. The whole service was documented in about two hours, and his next step is running it in CI so documentation stops being a chore.
- Service scaffolding: a service creator built from Fashion Cloud’s gold-standard template cut a half-day job down to about 7 minutes.
🔁 What Mahdi would do differently
Mahdi called his answer more political than technical:
- Work with leads and decision makers earlier. Aligning earlier with PMs and EMs would have allowed teams to act faster.
- Focus on outcome-oriented artifacts sooner. The diagrams worked well, but too often the tech leads figured things out without turning them into something others could use.
- Involve more people systematically. Relying mostly on tech leads is part of why it took months to get going.
🏁 Conclusion
Fashion Cloud’s story shows that architecture doesn’t need a title or a mandate to get started. A few tech leads saw that nobody knew who owned what, ran workshops to find out, and turned what they learned into a shared model that teams now keep current themselves. Lightweight DDD gave them a common language, the C4 model kept conversations at the right level, and simple governance kept it alive. As Luca put it, people come first: without collaboration, a socio-technical system is just friction on friction.
