by argoeris on 7/16/24, 3:09 PM with 99 comments
by bunsenhoneydew on 7/16/24, 8:31 PM
I can’t find the right video at the moment but Simon Brown (creator of C4) gives a great talk about creating his DSL, Structurizr, for C4, which he developed during COVID lockdown (if memory serves). There are many videos on YouTube of Simon talking about “C4 Models as Code” so I’m sure any one of those will suffice.
The focus is on creating the model of your system architecture, from which the diagrams you extract are a specific projection of that model. Rather than a diagram be the main artifact. It’s a simple but very powerful concept that I’m always surprised isn’t more widely used.
Structurizr models can also be exported to display as ilograph diagrams, mermaid diagrams and more. Also very much worth a mention is icepanel, a lovely tool for architectural model that implements the C4 model heavily.
I saw Simon talk at a conference in Sydney about 10-15 years ago and heard about C4 for the first time in that talk, it’s been one of the most influential talks I’ve been to in my career as it made a lot of fuzzy things in my head all start to come together in a way that just made sense.
by jawns on 7/16/24, 6:56 PM
* Devs: We need a better language than Javascript as the lingua franca of the web!
* Users: Sure, use whatever language you want -- just make sure it compiles to Javascript, which is already the lingua franca of the web.
Keep in mind that the consumers of technical diagrams are often non-technical folks. And they don't care about how they get their diagrams. They just want to be able to understand, at a high level, what's going on in the black box.
You can either convince every single one of them that devs need to focus on better system design tools ... or you can continue to give them the diagrams they want, just using a smarter process to generate them.
Or you can treat them as entirely separate problems, because fundamentally system design tools are building tools, and system diagrams are communication tools. In most cases you can improve them independently.
by yuliyp on 7/17/24, 1:10 AM
That's not really all that useful. Diagrams, like other forms of documentation, are a format for communicating something to the reader. It means that they should spend more space on the important flows rather than the exceptional ones. They'll explain the meaningful parts of a sequence rather than just giving a series of function calls. The various tools we have for doing this (boxes showing what systems talk to what, sequence diagrams, database schema diagrams) provide a rich enough language for that communication.
Death star diagrams are bad because they spend a bunch of time and effort to convey one piece of information: "there are a lot of systems here" rather than anything actually useful for someone attempting to navigate a specific part of the system.
by steve1977 on 7/17/24, 4:59 AM
by gtirloni on 7/16/24, 6:23 PM
by RcouF1uZ4gsC on 7/16/24, 6:43 PM
One issue is that diagrams in general are pretty universal. As long as your tool can makes shapes and connect them, you can use it for any kind of architecture. For example it will work flow charts for 50 year old Fortran to UML from the 90s to microservices diagrams from now and I bet to whatever is common 50 years from now.
by tomjohnson3 on 7/17/24, 4:02 PM
We’re language and environment agnostic and you can start with a napkin sketch or a photo of your whiteboard. And this is just the start, we have many plans for how to evolve system design tooling including supporting popular integrations and models like C4.
It’s early days for us. I’d love to hear what you think: https://www.multiplayer.app/ (It’s free!)
by dennisy on 7/16/24, 6:42 PM
by airbreather on 7/21/24, 8:25 PM
It was meant to be the next step forward from IEC 61131 that described the five PLC control languages, but far ahead of it's time.
61499 introduced the concept of an executable specification, and went on develop tie ins with XML and OPC. The executable specification is a particularly interesting idea, effectively emerging as no code these days
But two decades on is still only starting to get traction, seemingly because it was so far ahead of it's time, and the target audience was potentially mostly only just branching out into software because they were now programming ladder logic, instead of designing panel boards with hundred of relays and timers.
But, it is worth a look for some ideas in the space, particularly the executable specification concept (you know this can only lead to a DSL of some kind), but also including their diagramming that looks a lot like UML but maybe works better, along with 4Diac software package, consideration of how some of the more esoteric aspects of OPC fit into all this, and more slightly obliquely, TLA+.
by bitwize on 7/16/24, 9:40 PM
In the 80s, they marketed PRIDE/ASDM, which combines PRIDE with Automated Systems Design Methodology, a suite of system design tools written in COBOL for mainframes. Far from being mere diagramming tools, they assisted in all aspects of an information systems design from initial requirements down through coding and database management. A key component of ASDM was the Information Resource Manager (IRM), a searchable central database of all of the information artifacts described above along with their documentation. Another component was Automated Instructional Materials (AIM), the online documentation facility, which not only provided instructions on how to use the system, it also provided step-by-step directions (called "playscripts" in PRIDE-speak) for each member of the development team to follow, in order to see a business system through from abstract design down to software implementation and deployment. Provided the directions were followed, it was next to impossible to screw up a system or subsystem implemented through PRIDE/ASDM.
This level of comprehensiveness and clarity is the gold standard for business IS development. And it seems to be nearly lost to time.
by ranger_danger on 7/16/24, 7:56 PM
Does anything like that exist already?
by canterburry on 7/16/24, 7:17 PM
Everyone seems to look for answers involving not having to spend any time learning anything new.
UML, BPMN, 4+1 view, it can do it all. Just learn it and make sure everyone else in your team does too.
by danjl on 7/16/24, 10:27 PM
by agumonkey on 7/16/24, 8:19 PM
Languages changed a bit, more types, more concurrency, more functional idioms. Yet I feel we're not going anywhere.
by kmerroll on 7/17/24, 10:11 PM
More directly, the need for the special snowflakes and the ensuing complex system design processes will be reduced as we drive towards more automation N(A) frameworks.
by SrslyJosh on 7/16/24, 7:32 PM
by webprofusion on 7/17/24, 5:27 AM
Systems and requirements go hand in hand but the reality is requirements are eventually codified, and after a point only the system matters because the system is the reality and the requirements were just the formal inspiration.
I would love to see automated requirement analysis and verification from code.
by digger495 on 7/16/24, 10:48 PM
by Veuxdo on 7/16/24, 8:01 PM
by port19 on 7/17/24, 7:26 AM
by qwerty456127 on 7/16/24, 7:53 PM