Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C4 model for visualising software architecture (2017)

c4model.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: The C4 model for visualising software architecture (2017)

#51

Post by lfpeb8b45ez »

IshKebab wrote: post #34
bdg wrote: post #16

Earlier quoted context omitted.

Having structured architecture conventions becomes more important when you have many architecture conversations across multiple people and would like to gain insights from the diagrams too.

But you don't need and official standard that everyone learns. Just use words. If your box is a class, write "class Foo". If your arrow means "contains 1 or more" just write that next to the arrow.

Yes, that’s exactly the convention that C4 specifies: add legends on every diagram and make sure things are labeled in a way that people can understand.

Re: The C4 model for visualising software architecture (2017)

#52

Post by sgt »

wejick wrote: post #12
sgt wrote: post #4

Earlier quoted context omitted.

That's what I do. Boxes and lines between them. It helps a lot when thinking up new concepts and brainstorming too, so that the tool doesn't slow you down. I use Freeform now, which is super simple but works. Mark two objects and cmd-click/right click, then click "add connecting line".

Is it Freeform as the Apple Freeform? I tried it last week to create high Level design, still not as smooth as I expected. Mainly the text editing flow feels not seamless yet, the deal breaker was I couldn't get the file successfully shared thru any available options. To be fair it's still in its early of its time, I'll wait bit longer.

Apple Freeform yes, comes with macOS. Before that I used Keynote.

Re: The C4 model for visualising software architecture (2017)

#53

Post by sgt »

almostnormal wrote: post #13
sgt wrote: post #4

Earlier quoted context omitted.

That's what I do. Boxes and lines between them. It helps a lot when thinking up new concepts and brainstorming too, so that the tool doesn't slow you down. I use Freeform now, which is super simple but works. Mark two objects and cmd-click/right click, then click "add connecting line".

One step further: Powerpoint. Sooner or later the diagrams will usually be needed in a presentation. Having them in a presentable format saves another step, and is a constant reminder to produce something worth presenting. Those diagrams that don't end up in presentations will be write-only anyway, and could be in any random format. No-one is going to read them.

Freeform is basically a simplified Keynote, which it is based on. I used Keynote before. Might actually return to it since Freeform is pretty basic right now (it's pretty new).

Re: The C4 model for visualising software architecture (2017)

#54

Post by FourthProtocol »

Admittedly I'm a greybeard. Wrote my first app in 1984. Moved through the ranks, from support to dev roles, application architecture, enterprise architecture and finially process optimisation.

And so wow, those diagrams in the links - how does one even manage all those boxes?!?

Architecture is easier than coding, if you stay away from more/bigger/but_my_app_is_a_special_little_snowflake mantras. Consider the age-old, tried, tested, proven architecture models of yore (other than their most excellent diagram notations, stay away from UML).

Architecture (design) is layered, not spaghetti thrown at a wall, hoping something sticks. Most (99.9%) software domains can be divided into three horizontal layers -

1. UI

2. Application/business layer

3. Data layer

(note that both internal and external service layers sit at the same level as data layers, allowing them to be called from the application layer)

Finally, there are vertical layers (shared across the initial three layers) These typically include -

4. Communication

5. Exception management

6. Security

7. Logs

Start with that as an overview/index of the entire solution, and when the beast needs to grow, just grow it. But grow it wisely. Use the standard 3-tiered architecture model. Re-use those cross-cutting concens in new applications.

Federate identities. Standardise access/permissions management.

Finally, don't feel compelled to use all the things - if the solution is services-based, don't code a UI for it. Simply connect your client to the relevant, existing service. Yes, services can be tiered, assuming your management processes are mature.

As to the management issue. Governance is what keeps your estate from turning into a hairball. Make extensive and judicious use of

1. Risk management

2. Change management

3. Stakeholder management

4. Design reviews

5. Project review (where team members grade managers)

Establish a technical design authority. The TDA concerns itself with broadly technical matters that facilitate a system-wide perspective. This might include -

1. Systems and solutions

2. Data

3. Communications

4. Quality objectives, including security

5. Development and development operations (devops)

6. Infrastructure (including but not limited to directories; networks; servers, both on-site and remote/in clouds; workstations and mobile devices).

7. Testing (Tools, techniques, platforms, languages and frameworks)

8. Locations

Re: The C4 model for visualising software architecture (2017)

#55

Post by pjmlp »

nitwit005 wrote: post #42
pjmlp wrote: post #5

Earlier quoted context omitted.

UML is still highly used at the architecture command deck, even if the dream to generate code from diagrams failed. Just a couple of months ago I finalized yet another archictecture document, with enough class diagrams, sequence diagrams and use cases on it.

Try testing if people can comprehend the diagrams by asking a question after showing them a somewhat complicated one. You'll likely be disappointed. We don't seem to be using them because they work.

As it happens, most people understand easier a standard notation that can refer to, and get a book at the library, than NIH boxes and lines.

Now people straigth out of bootcamps calling themselves engineers, without having a Software Engineer degree, yeah maybe not.

Then again, they can get that book I just mentioned, and in the process maybe discover other goodies at the local library, or just ask ChatGPT.

Re: The C4 model for visualising software architecture (2017)

#56

Post by IAmGraydon »

The talk about programmatically creating these diagrams is interesting, but it would be more interesting to use this in reverse with AI. Create a C4 diagram with a GUI, programmatically factor it down to some kind of text-based format and use that as an input for a code-generating AI. Imagine rewriting vast chunks of code by just editing the structure diagram.

Re: The C4 model for visualising software architecture (2017)

#57

Post by bane »

C4 is very interesting and I think tackles certain problems related to software architecture really well. It sort of turns the lower levels of an architecture, which is mostly hardware and system software, into broad abstractions and focuses the effort on the stuff that sits above that in the stack. Which turns out to be surprisingly suitable for today's cloud-based/containerized scalable approaches.

Related, Archimate is also very good and there's a lot of overlap, but grounds itself more into the infrastructure bits. I've used some version of diagram approaches similar to Archimate in the past to really great effect to deconflict systems and data sources and demonstrate how all the stuff we're buying and gluing together supports specific business and user workflow needs.

Comments here about how this stuff all gets out of sync with the codebase are absolutely correct. But I've found that they can be excellent tools for use when you need to analyze a complex system or communicate systems and plans to a larger group.

It's surprising how often there isn't really any form of cohesive documentation and just sitting down for a couple weeks and drawing boxes with lines connecting them can unblock and simplify failing and frustrated efforts to move forward, especially when teams are working in the same playpen.

C4, Archimate, UML, whatever are really just good constrained diagramming languages you can use to capture specific things you wish to communicate, analyze, or memorialize. I think they aren't very good as preplanning and design tools.

Many of us suffered from the big UML push days where every facet of a system down to class definitions were supposed to be laid out in excruciating detail by some chief architect's office before a line of code was laid down. Madness like "we'll just generate the code from the diagrams" caused millions to suffer. When coding actually did start, those thousands of hours of planning usually were just ignored and the developers just did what they wanted anyways.

Re: The C4 model for visualising software architecture (2017)

#58

Post by dpflan »

IAmGraydon wrote: post #56

The talk about programmatically creating these diagrams is interesting, but it would be more interesting to use this in reverse with AI. Create a C4 diagram with a GUI, programmatically factor it down to some kind of text-based format and use that as an input for a code-generating AI. Imagine rewriting vast chunks of code by just editing the structure diagram.

I've seen some cool results when asking GenAI (here it was ChatGPT) to create code based upon a sequence diagram and vice versa. The goal is to have an abstraction to generate code from. Or at least build the 80% of the text for something to be a seed for generating code.

Re: The C4 model for visualising software architecture (2017)

#59

Post by d--b »

> Ask somebody in the building industry to visually communicate the architecture of a building and you'll be presented with site plans, floor plans, elevation views, cross-section views and detail drawings.

Well ask an architect to visually communicate “how the building is going to work”, ie, where do pilots go, how security works, how long will the waiting line be. What happnes to people missing the plane after they go through security. Then we’ll talk about those software diagrams.

Re: The C4 model for visualising software architecture (2017)

#60

Post by manicennui »

jackblemming wrote: post #49

You can see a crappy house that’s falling apart pretty easily. Conversely management cannot see a crappy codebase that’s rife with technical debt. Maybe they would make more intelligent decisions if they could visualize the problem.

Code quality does not seem to have any correlation with business success. Why should business care?
Post reply on HN