{"id":19685419,"url":"https://github.com/kislerdm/org-infrastructure-overview","last_synced_at":"2026-05-13T11:33:28.967Z","repository":{"id":176676955,"uuid":"655546703","full_name":"kislerdm/org-infrastructure-overview","owner":"kislerdm","description":"The tool to facilitate understanding of complex systems using C4 model diagrams with dynamically-adjustable level of details.","archived":false,"fork":false,"pushed_at":"2023-07-29T23:05:39.000Z","size":914,"stargazers_count":1,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"master","last_synced_at":"2026-02-06T13:12:49.336Z","etag":null,"topics":["c4-model","conways-law","orgchart"],"latest_commit_sha":null,"homepage":"http://www.dkisler.com/org-infrastructure-overview/","language":"TypeScript","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kislerdm.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2023-06-19T06:00:47.000Z","updated_at":"2025-08-27T14:26:49.000Z","dependencies_parsed_at":"2024-11-11T18:25:49.685Z","dependency_job_id":"db09c143-9d37-44f9-aed7-0665876222a2","html_url":"https://github.com/kislerdm/org-infrastructure-overview","commit_stats":null,"previous_names":["kislerdm/dynamic-diagrams","kislerdm/org-infrastructure-overview"],"tags_count":4,"template":false,"template_full_name":null,"purl":"pkg:github/kislerdm/org-infrastructure-overview","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kislerdm%2Forg-infrastructure-overview","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kislerdm%2Forg-infrastructure-overview/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kislerdm%2Forg-infrastructure-overview/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kislerdm%2Forg-infrastructure-overview/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kislerdm","download_url":"https://codeload.github.com/kislerdm/org-infrastructure-overview/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kislerdm%2Forg-infrastructure-overview/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":32980783,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-13T11:31:52.688Z","status":"ssl_error","status_checked_at":"2026-05-13T11:31:52.072Z","response_time":115,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["c4-model","conways-law","orgchart"],"created_at":"2024-11-11T18:21:49.218Z","updated_at":"2026-05-13T11:33:28.945Z","avatar_url":"https://github.com/kislerdm.png","language":"TypeScript","funding_links":[],"categories":[],"sub_categories":[],"readme":"# `org-infrastructure-overview`: organisation infrastructure's architecture overview with dynamically-adjustable level of details\n\n`org-infrastructure-overview` is the tool aiming to facilitate understanding dependencies between complex systems\nacross (sub-)organisations using [C4 model](https://c4model.com/) diagrams with dynamically-adjustable level of details.\nIt illustrates inter-domains interactions spanning several teams and services based on their definition as\nthe [graph](graph-schema.json).\n\n## Contents\n\n* [Demo](#demo)\n* [How to run](#how-to-run)\n    + [Prerequisites](#prerequisites)\n    + [Commands](#commands)\n* [How to define graph](#how-to-define-graph)\n* [Contribution](#contribution)\n  + [Further development](#further-development)\n\n## Demo\n\nThe screenshot illustrates the tool in action by visualising the infrastructure defined in the [file](src/data.json).\n\n\u003cimg src=\"webui-demo.png\" alt=\"webui\" height=400 style=\"border:#000 solid 1px\"\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eDemo topology\u003c/strong\u003e\u003c/summary\u003e\n\nThe demo application is based on the demo org structure topology described below.\n\n**GIVEN**\n\n- The organisation _Foo_ contains of two departments: _DepartmentA_ and _DepartmentB_.\n- The _DepartmentA_ has two domains: _DomainA_ and _DomainB_.\n- The _DomainA_ consists of three teams: _Team0_ (backend), _Team1_ (frontend).\n- The _DomainB_ has one team: _Team2_ (analytics and reconciliation).\n- The _DepartmentB_ has two teams: _Team3_ (streaming platform) and _Team4_ (CIAM).\n- The _Team0_ has one outbound dependency: _Team1_, and two inbound dependencies: _Team3_ and _Team4_.\n- The _Team1_ has two inbound dependencies: _Team0_ and _Team4_.\n- The _Team2_ has one dependency: _Team3_.\n- The _Team3_ has three dependencies: _Team0_, _Team2_ and _Team4_.\n- The _Team4_ has three outbound dependencies: _Team0_, _Team1_ and _Team3_, and one inbound dependency: _Team3_.\n- The _Team0_ owns two services: _Service0_ and _Service1_.\n- The _Team1_ owns one service: _Service2_.\n- The _Team2_ owns one service: _Service3_.\n- The _Team3_ owns three services: _Service4_, _Service5_ and _Service6_.\n- The _Team4_ owns three services: _Service7_, _Service8_ and _Service9_.\n- _Service0_ consists of three containers:\n    - _App1_: _Kotlin_ application deployed as AWS EKS;\n    - _Database_: AWS Aurora Postgres.\n    - _Cache_: AWS Elasticache Redis.\n- _Service1_ is a _Kotlin_ application to run batch jobs on database.\n- _Service2_ is a _JavaScript_ application deployed to AWS EKS.\n- _Service3_ consists of two containers:\n    - _App_: _Python_ batch processing app deployed to AWS EKS;\n    - _Database_: analytics db AWS Redshift.\n- _Service4_ consists of three containers:\n    - _App1_: _Kafka_ deployed as AWS MSK;\n    - _App2_: _Schema Registry_ deployed as _AWS Glue Schema Registry_;\n- _Service5_ consists of three containers:\n    - _App1_: Go application to sync domain events data to datalake deployed to AWS EKS;\n    - _Database_: S3 bucket.\n- _Service6_: secrets manager deployed as AWS Secretsmanager.\n- _Service7_: is a Go application to mutate user's account deployed to AWS EKS;\n- _Service8_ consists of four containers:\n    - _IAM_: AWS Cognito;\n    - _l0_: Go application deployed as AWS Lambda for AWS Cognito trigger 1;\n    - _l1_: Go application deployed as AWS Lambda for AWS Cognito trigger 2;\n    - _l2_: Go application deployed as AWS Lambda for AWS Cognito trigger 3;\n- _Service9_ is AWS SES used as the email notification service.\n\n**Note** that the above description is stored as the [graph definition](src/data.json) for the tool.\n\n#### Test Scenario - Domain Level\n\n**WHEN**\n\n_DomainA_ is selected\n\n**THEN**\n\nThe following diagram is expected.\n\n```mermaid \nC4Container\n    Enterprise_Boundary(Foo/DepartmentA, \"Department A\") {\n        Component(Foo/DepartmentA/DomainA, \"DomainA\")\n    }\n```\n\n#### Test Scenario - Container Level\n\n**WHEN**\n\n_Service2_ is selected\n\n**THEN**\n\nThe following diagram is expected.\n\n```mermaid\nC4Container\n    Enterprise_Boundary(Foo/DepartmentA/DomainA/Team1, \"Team1\") {\n        Container(Foo/DepartmentA/DomainA/Team1/Service2, \"Service2\", \"JavaScript/AWS EKS\", \"web application used by clients\")\n    }\n    Enterprise_Boundary(Foo/DepartmentA/DomainA/Team0, \"Team0\") {\n        System_Ext(Foo/DepartmentA/DomainA/Team0/Service0, \"Service0\")\n    }\n    Enterprise_Boundary(Foo/DepartmentB/Team4, \"Team4\") {\n        System_Ext(Foo/DepartmentB/Team4/Service8, \"Service8\", \"\", \"IAM\")\n    }\n    Rel(Foo/DepartmentA/DomainA/Team1/Service2, Foo/DepartmentA/DomainA/Team0/Service0, \"Uses to process user's requests\", \"sync, HTTP/JSON\")\n    Rel(Foo/DepartmentA/DomainA/Team1/Service2, Foo/DepartmentB/Team4/Service8, \"Authenticates users\", \"sync, HTTP/JSON\")\n```\n\n\u003c/details\u003e\n\n## How to run\n\n### Prerequisites\n\n- Node.js v18.16+\n\n### Commands\n\nRun to setup:\n\n```commandline\nnpm install\n```\n\nRun to test:\n\n```commandline\nnpm run test\n```\n\nRun to launch a dev server:\n\n```commandline\nnpm run dev\n```\n\nRun to build:\n\n```commandline\nnpm run build\n```\n\n## How to define graph\n\n**The graph definition rules**:\n\n- The graph must be defined according to the [JSON schema](graph-schema.json).\n- Each element in the graph is referred to as a `node`.\n- Dependencies between nodes are defined by `links`.\n- Every `link` represents a dependency, not data flow. The attribute **_from_** denotes the ID of the node\n  dependent on the `node` denoted by the attribute **_to_**.\n- The `node` ID is defined as a Unix path, which includes the IDs of the node's parent and the parent of its parent\n  and so on recursively.\n- The `node` ID is defined by using the names of the node and its parents. All special characters and spaces are\n  removed, and the results are concatenated using the forward slash sign (`/`) as the separator.\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eThe contextual topology\u003c/strong\u003e\u003c/summary\u003e\n\n```commandline\norganisation 0\n|-- department 0/0\n|   |-- domain 0/0/0\n|   |   |-- team 0/0/0/0\n|   |   |   |-- service 0/0/0/0/0\n|   |   |   |   |-- application 0/0/0/0/0/0\n|   |   |   |   |-- application 0/0/0/0/0/1\n|   |   |   |   |   ...\n|   |   |   |   |-- queue 0/0/0/0/0/2\n|   |   |   |   `-- database 0/0/0/0/0/P\n|   |   |   |-- service 0/0/0/0/1\n|   |   |   |   ...\n|   |   |   `-- service 0/0/0/0/L\n|   |   |-- team 0/0/0/1\n|   |   |   `-- application 0/0/0/1/0\n|   |   |   ...\n|   |   `-- team 0/0/0/K\n|   |-- domain 0/1\n|   |   ...\n|   |-- domain 0/X\n|   |   `-- application 0/X/0\n|   |   ...\n|   `-- domain 0/M\n|-- department 0/1\n|   ...\n|-- team 0/R\n|   ...\n|-- department 0/Y\n|   `-- database 0/Y/0\n|   ...\n|-- department 0/Z\n|   `-- team 0/Z/0\n|   ...\n`-- department 0/N\n```\n\nThe context transitions from the _organisation_ level down to the _system_ level. The diagram of every level includes\nthe nodes which belong to selected level's node and the linked nodes from other levels.\n\n\u003c/details\u003e\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003eGraph definition example\u003c/strong\u003e\u003c/summary\u003e\n\n**GIVEN**\n\n- Two business domains _DomainA_ and _DomainB_ belong to the same business unit _Unit0_;\n- _DomainA_ updates the entity based on the domain events emitted by the _DomainB_;\n- Both domains communicate via the _Platform0_ by publishing and consuming domain events.\n\n**WHEN**\n\nThe given topology is intended to be illustrated using the `org-infrastructure-overview` tool.\n\n**THEN**\n\nThe following graph shall be expected:\n\n```json\n{\n  \"nodes\": [\n    {\n      \"name\": \"Unit0\",\n      \"type\": \"department\",\n      \"nodes\": [\n        {\n          \"name\": \"DomainA\",\n          \"type\": \"domain\"\n        },\n        {\n          \"name\": \"DomainB\",\n          \"type\": \"domain\"\n        }\n      ]\n    },\n    {\n      \"name\": \"Platform0\",\n      \"type\": \"service\"\n    }\n  ],\n  \"links\": [\n    {\n      \"from\": \"Unit0/DomainA\",\n      \"to\": \"Unit0/DomainB\",\n      \"description\": \"Uses to update the entity state\"\n    },\n    {\n      \"from\": \"Unit0/DomainA\",\n      \"to\": \"Platform0\",\n      \"description\": \"Publishes and consumes domain events\"\n    },\n    {\n      \"from\": \"Unit0/DomainB\",\n      \"to\": \"Platform0\",\n      \"description\": \"Publishes and consumes domain events\"\n    }\n  ]\n}\n```\n\n\u003c/details\u003e\n\n## Contribution\n\nThe codebase is distributes under the MIT license. Please feel free to open PR, or issue with your request.\n\n### Further development\n\nGiven that the organisations which would benefit from the tool use [spotify backstage](https://backstage.io/),\nor [opslevel](https://www.opslevel.com/), it would make sense to integrate the tool's logic as plugins to the mentioned\nsystems.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkislerdm%2Forg-infrastructure-overview","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkislerdm%2Forg-infrastructure-overview","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkislerdm%2Forg-infrastructure-overview/lists"}