A growing organization behaves much like any other living thing as a bundle of metabolic processes that work well enough to sustain it day to day. We can sample these processes but we can't expect to know them completely.
As observers we will select an area of interest, focus our attention on processes present, assess the clarity of view, and pass judgement upon what we find.
Ultimately our judgements will lead to actions in the best interest of the organization. But before then we must become competent observers.
Say we want to understand service ownership.
How many services do we have?
match (s:SERVICE) return count(s)
How many services do each team own?
match (s:SERVICE)<-[:OWNS]-(t:TEAM) return t.team, count(s)
How many services don't have owners?
match (s:SERVICE) where not (s)<-[:OWNS]-(x) return count(s)
How important are the services, owned or otherwise?
match (s:SERVICE) optional match (s)<-[:OWNS]-(t:TEAM) optional match (s)-[:DEPENDS]->(u:SERVICE) optional match (s)<-[:DEPENDS]-(d:SERVICE) return s.name as service, t.name as team, count(u) as upstream, count(d) as downstream order by downstream desc
We're using dependents as a measure of importance. We can look further up and down the dependency tree with a hop-count annotation on the relation.
optional match (s)<-[:DEPENDS*1..3]-(d:SERVICE)
This will lead to questions like, why does one service have so many more dependencies, or, why do so many services have no dependencies?
But the better question is, why do a few services with many dependencies not have a clearly recorded owner? Did we fail to make a match? Did someone fail to register as owner? Maybe a reorganization is in progress or dropped something in the last reorg?
These are all good questions to answer before some service stops working.