![rw-book-cover](https://substackcdn.com/image/fetch/f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fd0d0026d-f7d8-49e9-8929-1ebd05fb6d87_1000x1250.jpeg) ## Metadata - Author: [[winnie|Winnie]] - Full Title:: American's Next Topological Model - Category:: #🗞️Articles - Document Tags:: [[Data team topologies|Data Team Topologies]], - URL:: https://roundup.getdbt.com/p/americans-next-topological-model - Finished date:: [[2023-09-26]] ## Highlights > Data teams have learned a lot from software teams, and will certainly learn much more, but one area we cannot emulate our software engineering peers is organizational topology ([View Highlight](https://read.readwise.io/read/01hb6bx8h51j4khebkwkysjk8n)) > instead of making arbitrary divisions based on standard business areas, focusing on greater alignment between the organization's knowledge graph and people graph. Far from [shipping the org chart](https://en.wikipedia.org/wiki/Conway%27s_law), this is an alignment that moves in both directions, organizing people around the ways data flows as much as organizing data projects around groups of people. ([View Highlight](https://read.readwise.io/read/01hb6bxt9fxxx2d0wpsp5tew8q)) > A common pattern to handle this setup today would be 'hub and spoke', using a central team to land and stage the data, then have the embeds build on top of this in separate areas of a shared project or in separate projects that import the central project (and potentially others ([View Highlight](https://read.readwise.io/read/01hb6c0ygh3xgxwy7vceed6e8w)) > ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F9e6b234f-8239-4501-9319-e8333e3d316b_1064x720.png) ([View Highlight](https://read.readwise.io/read/01hb6c14wfvpggvfvqh1b74jwb)) > Wouldn't it make more sense for the product analyst to own the entire transformation vertical for that data source? Why arbitrarily force them to go to a separate team to, say, unnest a JSON field differently, and all the ensuing downtime that handoff would take? > On the other hand, our finance and marketing analysts are actually working from a shared set of components, but they are better served to separate past a certain level to simplify their projects and allow independent development ([View Highlight](https://read.readwise.io/read/01hb6c1j466xd8hjxgcydzp0my)) > Something like the below would make a lot more sense for our organization: ([View Highlight](https://read.readwise.io/read/01hb6c1s7wby0w9jatgtczwscn)) > ![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F78410ef1-7977-4e54-a945-6aa9a3166f63_1063x695.png) ([View Highlight](https://read.readwise.io/read/01hb6c1tctftny1e2nkgdt64qk))