Hacker News Reader

Comment by qznc | Hacker News Reader

I believe the answer is to have a single model of everything.

You can build the model from whatever: Draw it with a GUI, query your server infrastructure, analyze binaries, collect it from databases, parse it from documentation, process your issues, etc. The important points is to merge all the information into a single model.

You cannot represent this model on a screen in any meaningful way. Instead you can only get certain "views" into it to understand an aspect or answer specific questions.

Does it exist today? Many tools and processes have been developed to achieve it. For example, "Model-based systems engineering" is a very formal approach. I have yet to see it realized in practice though.

I'm pretty sure it isn't a single tool or process though. By definition it integrates with nearly everything and that means a lot of customization. You won't get it get it off the shelf.

View on HN

This is something I that’s been living in my head for a few years now—and no, it does not exist yet. I’m also convinced the only way to get it right is to have a single graph, modelling the entire system, and apply filters on the graph to get only the nodes you’re currently interested in, then have different diagrams produced from that as the output. How else would you describe the flow of packages from the internet through the firewall, what the logical network looks like, and which physical location things are located at? These questions all interfere with each other on a conceptual level, yet are all conceivable using different attributes of the same connected graph nodes.

It’s very complex, very interesting, and lots of work.

I came to the same conclusion, and the closest thing I’ve found is using a graph database.

I've had the same thought but then gave up because it's not even a single graph: we assume it's a single graph because some parts of "concept - connection - concept" tuples...but that fails to capture the reality that the aggregate behavior of a system can implement a wholly different behavior.

A practical example of this would be neural networks in AI: which collectively implement functions much greater then the individual links.

You can always build a subgraph and find a connection to bring that into the main graph. If it’s part of a system, it’s part of the graph.

I have the same conclusion, if you capture the model as a graph you can then derive from the graph as many visual representations as you need, for instance, this tool can generate archimate context diagrams from the graph data ( mostly by doing "ontology translation" ) https://github.com/zazuko/blueprint

It exists, it's called MBSE. Look up tools that support this approach.

The problem with "a single model of everything" is that it is an inferior tool.

It's a drawing or diagramming tool, but the stand-alone diagramming tools are better.

It's a text composition tool, but word processors are better.

It's a code writing tool, but IDEs are better.

In every single thing it tries to do, a specialized tool is better. So this single tool needs to be close enough to the best in every category in order to not be a boat anchor holding you back. So far, nothing has come close.

Yes, that is good point. It might be reason why it fails in practice. Whatever view one produces from a single model, it will look crappy and cheap compared to the Powerpoint slide of someone else. It might be more truthful and more up to date, but it isn't as persuasive. Persuasion is what a presentation is ultimately about: It should influence the behavior of the audience.

Nothing stops us from using specialized tools in this case. They just need to not work on "single source of truth" of their respected domain, but on a projection of a single artifact into relevant dimension. Devil's in the details, of course, but at least with IDEs I can tell with certainty, based on my experience, that sticking to editing directly the single source of truth plaintext codebase is wasting much more time and cognitive effort than IDEs are saving us.

> Does it exist today?

Not sure, but IMO a dataflow diagram from good ol' SSADM got a lot of the way there. Unlike a lot of the modern techniques which model (groups of) deployed components, DFDs were strictly logical and functional and included data stores and users as well as functional components. So it was possible to model data in flow and at rest, and the characteristics of each, including where it crossed system boundaries.

IMO this was the best diagram format to get an overall view of the system, or reveal which areas needed further analysis.

It sounds to me like what you're describing is a single *tool*, not a single model. Is that possible?

I agree that we need multiple views, but it isn't just a matter of filtering part of a single view - it's also different fundamental primitives that are needed to communicate different kinds of ideas or aspects of a given system.

To me, this seems parallel to the evolution of LLMs into multi-modality by default. Different queries will need different combinations of text, heat maps, highlights, arrows, code snippets, flow charts, architecture diagrams, etc.

It's certainly not easy, but it's exciting to consider :)

UML had the idea. But instead of focusing on the visual aspect they went bananas on trying to turn it into some sort of a programming language.

Also the design tools for it were hilariously expensive and notoriously cumbersome.

That aspect of UML fell out of the development of CASE tools. A very mixed bag of results.

https://en.wikipedia.org/wiki/Computer-aided_software_engine...

> You cannot represent this model on a screen in any meaningful way. Instead you can only get certain "views" into it to understand an aspect or answer specific questions.

It sounds like you're describing: https://www.ilograph.com/blog/posts/concrete-diagramming-mod...

It looks quite limited in what kind of diagrams it produces. What about a class diagram, a state machine, timing behavior, etc?

There is Capella which is a tool (software) and method to design systems. It used the Arcadia method (mbse). It is quite extensible.

I don't understand how you can write an article about system design without mention to enterprise architect or Capella. I've read this as "we need to come up with a solution that already exists".

Reply on news.ycombinator.com