I used a visual data analytics toolkit for several years to help big telcos reconcile switch vs billing data. The tool was very dated looking, but it was ideal

I used a visual data analytics toolkit for several years to help big telcos reconcile switch vs billing data. The tool was very dated looking, but it was ideal for the specific tasks we were performing. I found the best use was as a discovery tool. Often a business would believe it knew its own processes and rules, but with large complex systems (often quite old software, especially on the billing side), it was very difficult for the companies to know if what they believed were the business rules were actually what was happening in their software. So we would work with the client to visually express these rules, in steps and phases, using visual flow-based development. It was kind of similar to REPL-based programming in that you could drop a node on the canvas, hook it up to a previous output, and run it immediately. Then you could inspect the outputs to see the result. Of course there were also UI features which made it very easy to get various details at a glance, such as number of elements on outputs with additional details on hover (min/max, avg, etc.) Being visual, it was also easier for non-technical clients to grasp what was going on. It was sort of a bridge language which allowed us to communicate with the client. Often the client would come up to speed with this representation and actually get involved in the building process. Eventually you have accurately modeled the business process, or at least what the process _should_ be. Then if the numbers coming out aren't right, you do additional analysis to identify the root causes. Then you build some following models which compensate for this to ensure the correct output. Finally, you have a formula of sorts which can then be implemented in other more production/repeatable code. On average, a client would recover $10 in lost revenue (due to billing errors) for every $1 they spent on our time. An unexpected side benefit of this process was that new observations could be made which might shape future business decisions. This was especially useful for new business models (such as design and implementation of early in-flight wifi services). Regarding model/diagram complexity, that was solved in the same way we solve complexity in text-based coding. You just organize details into sub-models, drilling down or stepping out to different views. One complex model might end up with a single node representation within a higher level model. I always wished we could have UI views like this on normal software projects to help in those times where your head gets lots in the complexity of dozens of modules and hundreds or thousands of functions (seeing the forest despite the trees, etc.)