4 ms·

For me, the lack of speed in creating the dependency graph has never been an issue. The issue when it comes to flowcharts has primarily been creating the correc

For me, the lack of speed in creating the dependency graph has never been an issue. The issue when it comes to flowcharts has primarily been creating the correct scope for the particular task, to have the right visualization tools to display my intent and to fill the chart with relevant information. When I have tools all of this, a high amount of conceptual information can be baked into a small and easy-to-access space. In my experience, "all" the info is very rarely required (which the speed-dependency-chart implies), since very few can process it anyways. I'll be sticking to Miro.

michaelsalim 4y ago
Do you have a strategy for that? I do have the same issue sometimes.
- baalimago 4y ago
  No specific strategy, I'm still trying to figure out what makes some diagrams better than others, and how to design diagrams which "works". The one I've used which have gotten the most spread in the company I'm working at were is one which mapped the transformation of a specific state in the microservice architecture. The state in question is highly central to our products success, and it reflects many (but not all) the relations between services. The dataflow were from leaf entrypoints, through processing, and finally stopped at internal consumer endpoints. The result is a reversed tree structure where each node is a microservice/external service (text in node explains which one, and linked to gitlab project) and each edge said which protocol is used for them to communicate. So, it reflects what services are required for a specific customer, depending on which path the customer takes in order to produce this state for internal consumers. Doing this enabled us to also analyze the "hot path", and "cold path" to know what services were problematic (rarely used/overused/too poorly written considering their importance/etc) and not. But in general, it needs to look nice. It should be pleasing for the eye to watch the diagram, should spark curiosity to investigate how the system works. Straight lines, consistent shapes for specific meanings, colour coded blobs. Directed edges also seems to work well. Once I told an ops guy "start here at the leaf, then follow the arrows", it really clicked for him. And at the end of the day, it's a frontend, with all it's ups and downs, and should be treated as such.

michaelsalim 4y ago

Do you have a strategy for that? I do have the same issue sometimes.

baalimago 4y ago
No specific strategy, I'm still trying to figure out what makes some diagrams better than others, and how to design diagrams which "works". The one I've used which have gotten the most spread in the company I'm working at were is one which mapped the transformation of a specific state in the microservice architecture. The state in question is highly central to our products success, and it reflects many (but not all) the relations between services. The dataflow were from leaf entrypoints, through processing, and finally stopped at internal consumer endpoints. The result is a reversed tree structure where each node is a microservice/external service (text in node explains which one, and linked to gitlab project) and each edge said which protocol is used for them to communicate. So, it reflects what services are required for a specific customer, depending on which path the customer takes in order to produce this state for internal consumers. Doing this enabled us to also analyze the "hot path", and "cold path" to know what services were problematic (rarely used/overused/too poorly written considering their importance/etc) and not. But in general, it needs to look nice. It should be pleasing for the eye to watch the diagram, should spark curiosity to investigate how the system works. Straight lines, consistent shapes for specific meanings, colour coded blobs. Directed edges also seems to work well. Once I told an ops guy "start here at the leaf, then follow the arrows", it really clicked for him. And at the end of the day, it's a frontend, with all it's ups and downs, and should be treated as such.