mapping the software items (and whatever related)... has been a conquest ever since. Although what you may infer without knowing deeper essential details (engines and what data drives them how), would be static. Still, "communication diagrams" are very useful meta-view.
some suggestions:
* have ways for multiple views and/or start-points and/or both up/down directions. e.g. hierachy vs reason/effect vs dependence vs whatever-else. Then think about animating those in time
* heat-map over the views, as e.g. churn(changes)-in-time, or usage(number of dependents), etc
* requirements engineering kind-of-view ~ may overlap with dependency (both directions!) but with explicit requirements/assumptions tied to respective stakeholders. Though this may need links to/from JIRA and similar issue-trackers etc
* check Wardley maps - yet another view, starting from customer/stakeholder/vendor-points. Also may move in time. It may need user decision on which things are big/separate-enough to surface on that view - sometimes a single script is on-par with whole subsystem
* future maybe - growing above into zoomable per-project thing (more proj.mngmnt than just code, incl. related e-mails etc) - described here: https://news.ycombinator.com/item?id=43060108
* probably more.. will add if something else dawns on me
Lots of good ideas in your comments, thanks. Like you say, you want call-graphs, hot-spots from your monitoring systems, seeing user interaction diagrams, links to other components, amount of engineering time spent on features, mapping security issues, tech debt, etc. The challenge is going to be to keep a simple product :)
These are not meant to distract you from current goals/ways - pick those which ~80% match what you already have, postpone/abandon the others. Like, devOps view is very different from all else, with somewhat weak links across to the product-related or build-related views (heh, new view: costs-related. Be them people-hours or compute/storage). No need to compete with focused tools in that space, (e.g. see [0]). Though some linkage/hints might be doable and valuable. (also see some github-repo visualizers below.)
3+ years ago i landed as architect onto a working system having 300Kloc js codebase across 20+ repos, plus other ~100 unused ones with unknown Mlocs in them, running over 25+ containers in 2 datacenters.. without neither good architectural diagram nor deployment diagram nor runtime flow diagram... took me quite some months to build some mental image of which is what and where and why. It was event-sourcing engine so event-flows mapping from parsing the source was doable (few weeks, python+esprima+graphviz), but all else... nope.
some suggestions:
* have ways for multiple views and/or start-points and/or both up/down directions. e.g. hierachy vs reason/effect vs dependence vs whatever-else. Then think about animating those in time
* heat-map over the views, as e.g. churn(changes)-in-time, or usage(number of dependents), etc
* requirements engineering kind-of-view ~ may overlap with dependency (both directions!) but with explicit requirements/assumptions tied to respective stakeholders. Though this may need links to/from JIRA and similar issue-trackers etc
* check Wardley maps - yet another view, starting from customer/stakeholder/vendor-points. Also may move in time. It may need user decision on which things are big/separate-enough to surface on that view - sometimes a single script is on-par with whole subsystem
* future maybe - growing above into zoomable per-project thing (more proj.mngmnt than just code, incl. related e-mails etc) - described here: https://news.ycombinator.com/item?id=43060108
* probably more.. will add if something else dawns on me
have fun!
p.s. fractional CTO? i am looking that way too..