TLDR. Growth without intentional structure produces chaos. Most IT transformations treat the symptom. The disease is structural: architecture mirrors the organization, and the organization mirrors business choices nobody made deliberately. Struct2Flow is a framing to make these choices on purpose, layer by layer, with every layer designed as a platform that can be reused, multi-tenant, and evolved over time. Built on Conway’s Law, Team Topologies, and Domain-Driven Design. Illustrated with a fictional travel company.

Companies invest huge amounts of money trying to get themselves back on track. Most of it is wasted. Which problems are they actually addressing? The symptoms or the disease?

They migrate monoliths to microservices. They adopt platform engineering. They roll out OKRs. They switch from on-prem to cloud, then back to private cloud, then to multi-cloud. They send people to leadership trainings and culture workshops. They hire a new CTO, then a new CPO, then a Head of Transformation.

And the same problems keep coming back. Maybe in a different system, maybe with different acronyms, but the same problems. The reason, I have come to believe, is structural.

The disease has a name

Conway saw it in 1968. Any organization that designs a system will produce a design whose structure mirrors the organization’s communication structure. If your organization is chaotic, slow, misaligned, and overly complex, your systems will be too. You cannot architect your way out of an organizational problem.

This is the principle I derive from it, and it is the principle behind Struct2Flow:

Architecture follows Structure. Structure follows Business.

If your business has been growing without an intentional structure, your structure is accidental. If your structure is accidental, your architecture is accidental too. No migration, no transformation, no framework will fix that. You will spend a lot of money and end up with a slightly different version of the same chaos.

Where this comes from

The idea is not original. It builds on the Reverse Conway Maneuver, described by Jonny LeRoy and Matt Simons in 2010. It builds on Team Topologies by Matthew Skelton and Manuel Pais, which is, in my opinion, one of the most influential books of the last decade. It builds on Architecture for Flow by Susanne Kaiser, who connects Team Topologies, Wardley Maps, and Domain-Driven Design.

Struct2Flow is what happens when you take these ideas seriously and try to apply them in real organizations. It is a framing to identify structural misalignments, link them to architectural symptoms, and design intentional structures that drive flow.

One word about complexity before we go further, because it matters later. Complexity comes in two flavors. Intentional complexity is inherent to the business. In an insurance company, calculating a premium is complex, and that complexity is the business. Accidental complexity is everything else. The interfaces, the manual steps, the workarounds, the systems that grew because nobody designed them. Manage the complexity, or it will manage you.

A small example

Let me make this concrete. Imagine a company called Aventravel. They organize adventure travel around the world, sports and cultural exploration, headquartered in Germany with branches on every continent.

Customers can book trips on the website or through an Experience Advisor. The Experience Advisors in Germany cover all countries without a local branch; the rest are handled locally. Trips are operated either by partner agencies or by internal Field Operations teams. A Travel Back Office handles visas, insurance, vaccinations, the boring parts that make adventure travel actually work.

Now let’s visualize how this company is structured.

The Aventravel structure as a four-layer pyramid: business-agnostic staff functions at the base, the business foundation above it, then market and country specific functions, with customer channels at the top

From the bottom up:

Operational Business Agnostic Staff Functions. HR, Finance, Legal, IT for IT, Marketing. The test for this layer is simple: if Aventravel started selling sports apparel tomorrow, would these functions need to change? No. They are agnostic to the business.

Business Foundation. Travel Back Office, Partner Discovery, Partner Management. This is the company’s domain, the layer where deep business knowledge lives. The test here is: could Aventravel offer these capabilities to other travel companies? Could competitors be tenants of this platform? If the answer is yes, you are looking at a business platform, and that is where the most interesting architectural decisions live.

Market and Country Specific. Germany, International, Brazil. Anything country-specific belongs here. Tax rules, local regulations, language, currency, local field operations. The moment country-specific logic leaks below this layer, you have created architectural debt. Going international by accident is one of the most expensive mistakes I see in growing companies.

Channels. Web, Experience Advisor, future apps, chatbots. Every touchpoint where customers meet the company.

This is a pyramid. You can also imagine it as a building with towers, like Notre Dame, where each tower is a business unit standing on the same foundation. Same idea, different shape. Use whichever helps your team think.

The same structure as two business pillars, Travel and Souvenirs, each with its own layers, standing on one shared foundation of operations and platform functions

Why this matters

Here is what happens when Structure does not follow Business, or Architecture does not follow Structure.

Companies build commodity applications instead of buying them, because some engineer somewhere convinced leadership that “we are different”. Companies over-customize standard software until upgrades become impossible. Companies create unique processes in areas where uniqueness has zero value. I have seen at least six different travel expense reimbursement processes in my career. None of them was a competitive advantage.

Companies ignore industry standards because they believe they are special. They build desktop-first software when their customers live on phones. They go international with a “Germany first, others translated” mentality and wonder why no other market really takes off.

All these are symptoms of the same disease. The structure was never aligned with the business intent, so the architecture mirrors something that no longer reflects what the company is trying to do.

What I do about it

This is the work I do as an independent advisor. I come in when an organization can feel that things are not flowing, but cannot quite name why. I help leadership teams make the layers visible, identify which ones are accidental, and design the small number of intentional moves that get the structure aligned with the business again.

It is rarely a big bang. It is usually a sequence of focused interventions: a domain that needs to be split, a layer that needs to be elevated, a team boundary that needs to be redrawn, an architectural decision that needs to be made on purpose for the first time.

Storm2Flow is the first product that came out of this work, and it is a small concrete instance of the same thesis. It exists because, in real engagements, capturing and aligning process reality used to take days. Now it takes minutes. If you are curious, the link is below.

If any of this resonates with how your organization currently feels, I would be happy to talk. The earlier these conversations happen, the cheaper the changes are.

Further reading

About Storm2Flow

Storm2Flow is the first product from Struct2Flow. It turns messy input, text, voice notes, workshop output, photos of whiteboards, into the artifacts teams actually use: flow diagrams, BPMN models, sequence diagrams, structured process flows. Built hands-on inside real engagements. Currently in beta.