---
title: "blog/post-single"
canonical_url: "https://www.laioutr.com/it/blog/conways-law-composable-replatforming"
locale: it
---
# La legge di Conway nel replatforming composable: l'organizzazione batte gli strumenti
Indice
1. [1.Perché il composable fallisce senza un cambiamento organizzativo](#perch-il-composable-fallisce-senza-un-cambiamento-organizzativo)
2. [2.Cosa significa la legge di Conway per i team composable](#cosa-significa-la-legge-di-conway-per-i-team-composable)
3. [3.Gli schemi organizzativi più comuni che bloccano il composable](#gli-schemi-organizzativi-pi-comuni-che-bloccano-il-composable)
4. [4.Cosa risolve qui una FMP](#cosa-risolve-qui-una-fmp)
5. [5.Tre domande per il vostro brief di replatforming](#tre-domande-per-il-vostro-brief-di-replatforming)
6. [6.Conclusione: il composable è una questione organizzativa, non una questione di strumenti](#conclusione-il-composable-una-questione-organizzativa-non-una-questione-di-strumenti)
1. [1.Perché il composable fallisce senza un cambiamento organizzativo](#perch-il-composable-fallisce-senza-un-cambiamento-organizzativo)
2. [2.Cosa significa la legge di Conway per i team composable](#cosa-significa-la-legge-di-conway-per-i-team-composable)
3. [3.Gli schemi organizzativi più comuni che bloccano il composable](#gli-schemi-organizzativi-pi-comuni-che-bloccano-il-composable)
4. [4.Cosa risolve qui una FMP](#cosa-risolve-qui-una-fmp)
5. [5.Tre domande per il vostro brief di replatforming](#tre-domande-per-il-vostro-brief-di-replatforming)
6. [6.Conclusione: il composable è una questione organizzativa, non una questione di strumenti](#conclusione-il-composable-una-questione-organizzativa-non-una-questione-di-strumenti)
Mel Conway scrisse la sua osservazione nel 1968. Più di mezzo secolo dopo, resta il quadro più preciso per spiegare perché i progetti composable falliscono.
Kelly Goetsch la cita a pagina 3 di *Microservices for Modern Commerce* (O'Reilly, 2016) e definisce i microservizi direttamente come « Hacking Conway's Law ». La sua formulazione: *« Qualsiasi organizzazione che progetta un sistema (inteso in senso ampio) produrrà una progettazione la cui struttura è una copia della struttura di comunicazione dell'organizzazione. »* Goetsch descrive poi come strutture organizzative specializzate orizzontalmente, sviluppatori Java in un gruppo, amministratori di storage in un altro, team UI separati, producano inevitabilmente sistemi monolitici fortemente accoppiati.
Nel 2026 questa intuizione non è ancora stata pienamente recepita. Non per ignoranza, ma perché le riorganizzazioni sono costose, sul piano politico e organizzativo, molto più dell'acquisto di nuovi strumenti SaaS.
## Perché il composable fallisce senza un cambiamento organizzativo
Consideriamo questo scenario: state sostituendo il vostro monolite Shopware con uno stack composable. Microservizi backend via commercetools, ricerca via Algolia, storefront via Next.js. L'architettura è modulare. I contratti sono firmati. I domini sono registrati.
Ma la vostra struttura organizzativa è così:
- Un team frontend centrale che gestisce tutti i ticket UI
- Un team backend che configura le API composable
- Un team contenuti che lavora nel vecchio CMS e scrive ticket per il team frontend
- Un team DevOps che approva i deployment
Cosa succede a questo punto? Ogni modifica al frontend passa per i ticket. Ogni deployment richiede un processo di approvazione. Ogni nuovo test A/B richiede coordinamento tra tre team. La modularità tecnica c'è, ma l'accoppiamento organizzativo produce la stessa inerzia del monolite.
Goetsch descrive esattamente questo schema con l'esempio di uno sviluppatore Java che ha bisogno di una nuova colonna nel database: dieci passaggi in sequenza, sistema di ticket del DBA, passaggi di consegne, tempi di attesa, per una modifica che richiede due minuti di lavoro effettivo. *« Questi passaggi sono estenuanti anche solo da leggere, eppure è così che persino le modifiche minori vengono realizzate nelle aziende. »*
L'equivalente nello stack composable nel 2026: una persona del team contenuti vuole una nuova sezione di landing page. Tecnicamente ogni componente è disponibile. Ma dopo sei ticket e tre riunioni di coordinamento, il momento è passato.
## Cosa significa la legge di Conway per i team composable
Non potete aggirare la legge di Conway. Ma potete usarla deliberatamente allineando la vostra struttura organizzativa alla struttura di sistema desiderata, questo è ciò che Goetsch intende con « Hacking Conway's Law ».
In concreto: se volete un sistema composable fatto di capacità autonome e disaccoppiate (storefront, ricerca, checkout, contenuti), vi servono team autonomi e disaccoppiati che possiedano quelle capacità.
Lo schema che funziona qui è quello dei **team di prodotto interfunzionali per capacità di business**. Un team possiede lo storefront, il codice frontend, il deployment, le prestazioni, i test A/B, tutto. Ha un product manager, uno o più sviluppatori, una persona dedicata alle operazioni sui contenuti. Non aspetta ticket da altri team. Si occupa da solo del proprio deployment.
Goetsch descrive con chiarezza il principio di ownership per i microservizi: *« Un unico team di 2 fino a 15 persone sviluppa, distribuisce e gestisce un singolo microservizio per tutto il suo ciclo di vita. Questo team possiede davvero il microservizio. L'ownership porta una mentalità completamente diversa. »*
Applicato al livello frontend: un team che possiede lo storefront può realmente vivere in modo composable. Un team che gestisce i ticket dello storefront ma non ha autonomia di deployment è strutturalmente un monolite, indipendentemente da cosa faccia l'architettura API sottostante.
## Gli schemi organizzativi più comuni che bloccano il composable
Tre schemi causano sistematicamente problemi nella pratica:
**Schema 1: il team frontend centrale come collo di bottiglia** Un unico team responsabile di tutti gli artefatti frontend non scala con uno stack composable. Quando dieci team di business vogliono contemporaneamente funzionalità storefront, il team frontend centrale diventa il vincolo. La soluzione non è un team centrale più grande, ma un'ownership decentralizzata con infrastruttura condivisa.
**Schema 2: team contenuti senza un percorso di deployment** In molte organizzazioni i team contenuti non possono pubblicare da soli nuove pagine o sezioni. Hanno bisogno del supporto di uno sviluppatore per ogni nuovo template. Questo significa che i team contenuti restano nel vecchio CMS monolitico oppure producono continuamente dipendenze. Una buona configurazione FMP separa l'autonomia dei contenuti dal deployment del codice.
**Schema 3: il DevOps come organo di approvazione centrale** Quando ogni deployment richiede l'approvazione centrale del DevOps, la frequenza delle release è limitata, indipendentemente da quanto modulare sia lo stack. L'ownership del deployment deve stare presso il team che possiede il servizio.
## Cosa risolve qui una FMP
Una Frontend Management Platform affronta l'interfaccia tra struttura organizzativa e stack tecnico. Crea l'infrastruttura che permette a team diversi di lavorare in modo autonomo sulle capacità frontend, senza coordinamento costante.
In concreto: un team contenuti può configurare nuovi layout di pagina in [Laioutr Studio](https://www.laioutr.com/en/product/content-management) senza aspettare ticket dagli sviluppatori. Un team growth può impostare test A/B senza bloccare i deployment frontend. Un team di sviluppatori può creare nuovi componenti, registrarli nella FMP e renderli disponibili affinché altri team li usino in autonomia.
Questa non è solo una funzionalità tecnica, è l'abilitatore tecnico del modello di team interfunzionale richiesto dalla legge di Conway.
L'alternativa, ogni team costruisce il proprio stack frontend e gestisce i propri deployment, produce quello che Goetsch descrive come costo di duplicazione: *« Ogni team di microservizi seleziona, a volte acquista, e gestisce sempre il proprio stack. Ma il punto dei microservizi è la velocità. »* Per il livello frontend questo non regge del tutto: la complessità frontend si gestisce meglio con infrastruttura condivisa, non con una decentralizzazione totale.
## Tre domande per il vostro brief di replatforming
Se state preparando un replatforming composable, vale la pena rispondere a queste tre domande prima della prima riunione di architettura:
**1. Quali team hanno oggi autonomia di deployment per gli artefatti frontend?** Se la risposta è « nessuno » o « solo il team frontend centrale », avete una struttura organizzativa che bloccherà il composable.
**2. I team contenuti possono pubblicare oggi nuove pagine senza il supporto di uno sviluppatore?** Se no, non è una lacuna funzionale del vostro CMS, è una lacuna di ownership nella vostra organizzazione.
**3. Quanti team sarebbero coinvolti da una singola richiesta di funzionalità per lo storefront?** Se la risposta è più di due, avete una struttura con un carico di coordinamento che impedisce la velocità del composable.
Le risposte a queste domande contano più per l'esito del vostro replatforming della scelta tra Hygraph e Contentful.
## Conclusione: il composable è una questione organizzativa, non una questione di strumenti
L'osservazione di Goetsch del 2016 resta invariata nel 2026: i microservizi, e il composable in generale, sono più un tema organizzativo che un tema tecnologico. Comprare gli strumenti senza adeguare la struttura organizzativa vi compra una complessità più costosa, non una velocità maggiore.
Questo non significa che serva una trasformazione organizzativa completa prima di un replatforming. Significa che bisogna risolvere consapevolmente le questioni di ownership: chi possiede cosa? Chi può distribuire cosa in modo indipendente? Chi ha bisogno dell'approvazione di chi?
Una FMP come [quella di Laioutr](https://www.laioutr.com/en/agentic-frontend-management-platform "Laioutr's") può aiutare a mappare tecnicamente questa struttura di ownership, ma non sostituisce la decisione su chi possiede quale capacità.
Per approfondire il lato tecnico di questa domanda, come gli standard del livello frontend influenzino il TCO nello stack composable, nei nostri articoli [10 anni di microservizi nel commercio](https://www.laioutr.com/en/blog/10-years-microservices-modern-commerce-retrospective "10 Years of Microservices in Commerce") e [Headless da solo non basta](https://www.laioutr.com/en/blog/headless-microservices-frontend-layer-gap "Headless Alone Is Not Enough").
**\[Parlate del vostro replatforming composable, la questione organizzativa viene prima](https://www.laioutr.com/demo)**
*Fonte: Goetsch, K. (2016). Microservices for Modern Commerce. O'Reilly Media.*
### **Approfondimenti correlati**
- [Salvaguardare gli investimenti esistenti: perché una transizione composable graduale batte il replatforming completo](https://www.laioutr.com/en/blog/saving-existing-investments-composable-migration "Saving Existing Investments: Why Gradual Composable Transition Beats Full Replatforming")
- [Replatforming degli editori nel 2026: perché i frontend composable stanno raddoppiando i ricavi delle riviste](https://www.laioutr.com/en/blog/publisher-replatforming-in-2026-why-composable-frontends-are-doubling-magazine-revenue "Publisher Replatforming in 2026: Why Composable Frontends Are Doubling Magazine Revenue")
Risorse correlate: [Composable Digital Experience Platform](https://www.laioutr.com/en/composable-digital-experience-platform).
---
Condividi questo articolo
[Condividi su Facebook](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fwww.laioutr.com%2Fit%2Fblog%2Fconways-law-composable-replatforming) [Condividi su X](https://x.com/intent/post?url=https%3A%2F%2Fwww.laioutr.com%2Fit%2Fblog%2Fconways-law-composable-replatforming&text=) [Condividi su LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fwww.laioutr.com%2Fit%2Fblog%2Fconways-law-composable-replatforming) [Condividi su Pinterest](https://pinterest.com/pin/create/button/?url=https%3A%2F%2Fwww.laioutr.com%2Fit%2Fblog%2Fconways-law-composable-replatforming&description=) [Condividi via e-mail](mailto:?subject=&body=%0A%0Ahttps%3A%2F%2Fwww.laioutr.com%2Fit%2Fblog%2Fconways-law-composable-replatforming)
## Altri articoli interessanti
Conoscenza pratica su sviluppo frontend, agenti intelligenti e headless
[Al blog](https://www.laioutr.com/it/blogs)
[iPhone Duo and Ecommerce: What Merchants Need to Know Now
iPhone Duo goes on sale on October 23, 2026. Online stores don't need a dedicated app or a custo…](https://www.laioutr.com/it/blog/iphone-duo-ecommerce-foldable-storefront)
[Dati prodotto strutturati: dove si vedono davvero nello storefront
Dati prodotto strutturati significa che ogni informazione sul prodotto vive in un attributo tipizzat…](https://www.laioutr.com/it/blog/structured-product-data-pim-frontend-2026)
[44% decide con trial o PoC: il PoC dello storefront per la DACH
Nella regione DACH le decisioni sul software si prendono sempre più spesso sul campo: nello studio &…](https://www.laioutr.com/it/blog/storefront-proof-of-concept-dach-buyers-2026)
[Confronto FMP: come scegliere la Frontend Management Platform giusta
Scegliere una Frontend Management Platform (FMP) non significa confrontare liste di funzionalità, ma…](https://www.laioutr.com/it/blog/frontend-management-platform-comparison-how-to-choose-2026)
[DAM, PIM e CMS convergono: cosa significa per il tuo frontend
I fornitori di DAM, PIM e CMS stanno entrando l'uno nel territorio dell'altro, e sempre più …](https://www.laioutr.com/it/blog/dam-pim-cms-convergence-content-hub-storefront-2026)
[Contentful Live Preview: cosa deve garantire il tuo frontend
Con Contentful Live Preview i redattori vedono una bozza accanto all'editor della entry e seguon…](https://www.laioutr.com/it/blog/contentful-live-preview-frontend-perspective-2026)
[Content governance su larga scala: contenuti prodotto e brand asset
Content governance su larga scala significa definire una volta sola ruoli, approvazioni, regole di b…](https://www.laioutr.com/it/blog/content-governance-product-content-brand-assets-frontend-2026)
[Agenti AI come operatori del frontend: architettura e controllo
Un agente AI diventa un operatore del frontend quando osserva lo storefront in produzione, individua…](https://www.laioutr.com/it/blog/ai-agents-as-frontend-operators-2026)
[Agenti di acquisto e feed: cosa cambia con l'Agentic Commerce
L'Agentic Commerce aggiunge un nuovo lettore ai tuoi dati prodotto: gli agenti di acquisto in Ch…](https://www.laioutr.com/it/blog/shopping-agents-product-feeds-agentic-data-distribution-2026)
[Server-side tracking nell'e-commerce: la misurazione torna completa
Il server-side tracking sposta l'inoltro degli eventi di analytics e di conversione dal browser …](https://www.laioutr.com/it/blog/server-side-tracking-ecommerce-complete-measurement-2026)
[Immagini prodotto via deeplink, non via ZIP: asset sempre aggiornati
Se invii ancora le immagini prodotto a rivenditori, marketplace e stampa come file ZIP, ogni pacchet…](https://www.laioutr.com/it/blog/product-image-deeplinks-asset-distribution-2026)
[Da PrestaShop 8 a 9 senza replatforming: prima disaccoppia il frontend
Puoi togliere gran parte del rischio dall'aggiornamento di PrestaShop da 8 a 9 staccando la stor…](https://www.laioutr.com/it/blog/prestashop-8-to-9-upgrade-without-replatforming-2026)
[Order management con un OMS come fulfillmenttools: la vista frontend
Un order management system efficiente decide quale sede evade un ordine, quanto stock è davvero disp…](https://www.laioutr.com/it/blog/order-management-fulfillmenttools-oms-frontend-2026)
[Niente budget di replatforming nel 2026? Il frontend viene approvato
Se nel tuo budget 2026 non c'è spazio per un progetto di replatforming, non sei l'unico, e n…](https://www.laioutr.com/it/blog/no-replatforming-budget-frontend-project-approval-2026)
[Order management nel garden retail: cosa deve mostrare lo storefront
Nel retail per giardino e fai da te, lo stesso carrello può contenere un articolo spedito in pacco, …](https://www.laioutr.com/it/blog/garden-retail-order-management-seasonal-frontend-2026)
[](https://www.laioutr.com/it/apps/shopify)
Laioutr
[Shopify](https://www.laioutr.com/it/apps/shopify)
Shopify è una piattaforma di commerce per vendere online e nei negozi fisici.
[](https://www.laioutr.com/it/apps/shopware)
Laioutr
[Shopware](https://www.laioutr.com/it/apps/shopware)
Shopware è una piattaforma e-commerce europea e flessibile per cataloghi prodotto e commerce omnicanale.
[](https://www.laioutr.com/it/apps/adobe-commerce)
Laioutr
[Adobe Commerce](https://www.laioutr.com/it/apps/adobe-commerce)
Adobe Commerce è una piattaforma di enterprise commerce per scenari B2C e B2B complessi e globali.
Planned
[](https://www.laioutr.com/it/apps/b2b-sellers)
Laioutr
[B2Bsellers](https://www.laioutr.com/it/apps/b2b-sellers)
Suite B2B per Shopware che trasforma lo shop online in una piattaforma professionale di commerce B2B.
Planned
[](https://www.laioutr.com/it/apps/commerce-layer)
Laioutr
[Commerce Layer](https://www.laioutr.com/it/apps/commerce-layer)
Commerce Layer è una piattaforma di headless commerce per rendere disponibili online inventari e cataloghi.
[](https://www.laioutr.com/it/apps/commercetools)
Laioutr
[Commercetools](https://www.laioutr.com/it/apps/commercetools)
Commercetools è una piattaforma e-commerce headless basata su SaaS e utilizzata in tutto il mondo.
[](https://www.laioutr.com/it/apps/emporix)
Laioutr
[Emporix](https://www.laioutr.com/it/apps/emporix)
Emporix è una piattaforma di commerce composable e API-first per scenari B2B e B2C scalabili.
Planned
[](https://www.laioutr.com/it/apps/hcl-software)
Laioutr
[HCL Software](https://www.laioutr.com/it/apps/hcl-software)
Suite enterprise per commerce ed esperienze digitali, altamente configurabile.
Planned
[](https://www.laioutr.com/it/apps/intershop)
Laioutr
[Intershop](https://www.laioutr.com/it/apps/intershop)
Piattaforma di enterprise commerce per modelli di business B2B e B2C complessi.
Planned
[](https://www.laioutr.com/it/apps/magento-2)
Laioutr
[Magento 2](https://www.laioutr.com/it/apps/magento-2)
Piattaforma di commerce estendibile e molto diffusa per scenari B2C e B2B.
[](https://www.laioutr.com/it/apps/oxid-eshop)
Laioutr
[OXID eShop](https://www.laioutr.com/it/apps/oxid-eshop)
OXID eShop è una piattaforma di commerce estendibile per requisiti B2B e B2C complessi.
Planned
[](https://www.laioutr.com/it/apps/patchworks)
Laioutr
[Patchworks](https://www.laioutr.com/it/apps/patchworks)
Patchworks è un iPaaS low-code che collega e-commerce, ERP, WMS, 3PL e marketplace.
Planned
[](https://www.laioutr.com/it/apps/PrestaShop)
Laioutr
[Prestashop](https://www.laioutr.com/it/apps/PrestaShop)
Piattaforma di commerce open source per merchant piccoli e medi in Europa e oltre.
Planned
[](https://www.laioutr.com/it/apps/saleor)
Laioutr
[Saleor](https://www.laioutr.com/it/apps/saleor)
Piattaforma di commerce open source e API-first basata su GraphQL per storefront personalizzati.
Planned
[](https://www.laioutr.com/it/apps/salesforce-commerce-cloud)
Laioutr
[Salesforce Commerce Cloud](https://www.laioutr.com/it/apps/salesforce-commerce-cloud)
Salesforce Commerce Cloud è una piattaforma di enterprise commerce basata su cloud per aziende di ogni dimensione.
Planned
[](https://www.laioutr.com/it/apps/sap-commerce-cloud)
Laioutr
[SAP Commerce Cloud](https://www.laioutr.com/it/apps/sap-commerce-cloud)
Piattaforma di enterprise commerce per cataloghi complessi, modelli di prezzo e journey omnicanale.
Planned
[](https://www.laioutr.com/it/apps/scayle)
Laioutr
[Scayle](https://www.laioutr.com/it/apps/scayle)
SCAYLE è un commerce engine con cui brand e retailer fanno scalare il proprio business.
Planned
[](https://www.laioutr.com/it/apps/spryker)
Laioutr
[Spryker](https://www.laioutr.com/it/apps/spryker)
Piattaforma di commerce composable per modelli di business B2B e B2C esigenti.
[](https://www.laioutr.com/it/apps/sylius)
Laioutr
[Sylius](https://www.laioutr.com/it/apps/sylius)
Sylius è un framework e-commerce developer-friendly per esperienze di shopping B2C e B2B.
Planned
[](https://www.laioutr.com/it/apps/vendure)
Laioutr
[Vendure](https://www.laioutr.com/it/apps/vendure)
Vendure è una piattaforma di headless commerce per aziende con requisiti complessi.
Coming Soon
[](https://www.laioutr.com/it/apps/vtex)
Laioutr
[VTEX](https://www.laioutr.com/it/apps/vtex)
Piattaforma di commerce cloud-native e composable per B2B e B2C su larga scala.
Planned
[](https://www.laioutr.com/it/apps/websale)
Laioutr
[Websale](https://www.laioutr.com/it/apps/websale)
Backend di commerce stabile e adatto all'enterprise per ambienti retail complessi.
Colloquio strategico
## Pronti a trasformare il vostro frontend in un livello di controllo?
Mostrateci il vostro stack, la vostra roadmap, il vostro scenario di replatforming: vi mostriamo come si integra Laioutr, quanto costa e quanto velocemente andrete live.
*"Dopo 30 minuti abbiamo capito che Laioutr rende fattibile il nostro replatforming." - Daniel B., CEO,* [*hygibox.de*](https://hygibox.de)
[Prenota una demo](https://www.laioutr.com/it/contact)
## Structured Data
```json
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://www.laioutr.com/#identity",
"name": "Laioutr",
"legalName": "Laioutr GmbH",
"url": "https://www.laioutr.com/",
"logo": {
"@type": "ImageObject",
"url": "https://www.laioutr.com/laioutr-logo.png",
"width": 400,
"height": 400
},
"email": "info@laioutr.com",
"telephone": "+49 30 75435715",
"address": {
"@type": "PostalAddress",
"streetAddress": "Münchweilersteig 5",
"postalCode": "12559",
"addressLocality": "Berlin",
"addressCountry": "DE"
},
"vatID": "DE450905846",
"sameAs": [
"https://www.linkedin.com/company/laioutr",
"https://www.youtube.com/@Laioutr",
"https://x.com/laioutr"
]
},
{
"@type": "WebSite",
"@id": "https://www.laioutr.com/it/#website",
"url": "https://www.laioutr.com/it/",
"name": "Laioutr",
"inLanguage": "it",
"publisher": {
"@id": "https://www.laioutr.com/#identity"
}
},
{
"@type": "BlogPosting",
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#article",
"headline": "La legge di Conway nel replatforming composable: l'organizzazione batte gli strumenti",
"image": [
"https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmpi74v5pstx108laqbu9eyup"
],
"datePublished": "2026-08-27T12:27:08.352085+00:00",
"dateModified": "2026-08-27T12:27:08.068522+00:00",
"inLanguage": "it",
"articleSection": "Insights",
"keywords": "Composable, Migration, Frontend Management, commercetools, Shopware",
"author": {
"@type": "Person",
"name": "Marcel Thiesies",
"jobTitle": "Co-founder e CEO, Laioutr",
"image": "https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmj01b962364n07lb0iguvts5"
},
"publisher": {
"@id": "https://www.laioutr.com/#identity"
},
"mainEntityOfPage": {
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#webpage"
},
"isPartOf": {
"@id": "https://www.laioutr.com/it/#website"
}
},
{
"@type": "WebPage",
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#webpage",
"url": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming",
"name": "La legge di Conway nel replatforming composable: l'organizzazione batte gli strumenti",
"inLanguage": "it",
"isPartOf": {
"@id": "https://www.laioutr.com/it/#website"
},
"breadcrumb": {
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#breadcrumb"
},
"primaryImageOfPage": {
"@type": "ImageObject",
"url": "https://eu-west-2.graphassets.com/cmii2mlqi0dux06l5543v7nkc/cmpi74v5pstx108laqbu9eyup"
},
"datePublished": "2026-08-27T12:27:08.352085+00:00",
"dateModified": "2026-08-27T12:27:08.068522+00:00",
"mainEntity": {
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#article"
}
},
{
"@type": "BreadcrumbList",
"@id": "https://www.laioutr.com/it/blog/conways-law-composable-replatforming#breadcrumb",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Laioutr",
"item": "https://www.laioutr.com/it/"
},
{
"@type": "ListItem",
"position": 2,
"name": "Insights",
"item": "https://www.laioutr.com/it/blogs/insights"
},
{
"@type": "ListItem",
"position": 3,
"name": "La legge di Conway nel replatforming composable: l'organizzazione batte gli strumenti"
}
]
}
]
}
```