7 ms·

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong.

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong. The 'what does this element do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'. I highly suggest folks take a look at the C4 Model: https://c4model.com/ https://c4model.com/

grogenaut 3y ago
None of the visuals in the examples are distinct. Usually I have like chrome to a box labeled alb... I'm not sure what c4 is getting me over that
mipselaer 3y ago
Great article. So you could say the current version is just a bunch of icons. Next step is adding meta info to the recourses. I'm currently working on a auto import funcion like you can use in Cloudcraft.
ahoka 3y ago
What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t trust anything that is designed someone who last did real projects in the 2000’s OOP Java enterprise craze.
- mkl95 3y ago
  It's not a hard science. Take the parts that work for your team and scrap the ones that don't.
  - politelemon 3y ago
    This is the important bit. C4 in its entirety isn't useful to many orgs and teams, and can be unnecessary overkill. You might end up picking 1 or 2 layers for yourself. You don't have to stick to their software either, use DrawIO if that's what you prefer, but understand the main concepts that C4 is trying to impart about the separation, what goes on the arrows, and how useless icons can be.
  - npsimons 3y ago
    > Take the parts that work for your team and scrap the ones that don't. Precisely. Any time someone utters the descriptor "best practice", at best, you do yourself a favor by examining it with a critical eye and judge whether it is a good practice to follow (and a good fit for your project) or not. At worst, you beat back the consultants framing it as "the one and only way to do things (with the implication that everything else is wrong)."
  - happytiger 3y ago
    The voice of reason always comes from the trenches.
- lwhi 3y ago
  I don't know whether your comment is useful or not because all you're doing is ranting and providing personal opinion. Your comment is useless to me; so ultimately I'm not likely to give it any credence.
- arcbyte 3y ago
  It's 4 diagrams. You can't get much less engineered than that. Whats your background that you have simpler alternatives?
- lionkor 3y ago
  So so much agree with this. People who think in terms of OOP and design patterns (i.e. bandaids) will think "how else are you supposed to model solutions"? But yes, this is fundamentally an OOP thing, and especially the component layer is very much just fantasy. In no real OOP software do these meat reusable components not have super strong binding to each other. Yeah you may have the SignIn controller and the ResetPassword controller both talking to the SecurityComponent, but in the end that's guaranteed to be implemented in such a way that you cant use any of them without all the others connected, and its likely that testing this means writing a mock for each of them that is so complex it may as well have its own tests. They are thinking of their problem, and building their solution entirely out of blocks made from the words that make up the problem. "We need users to be able to sign in and reset their password" becomes SignIn component and ResetPassword component, when really this is just a matter of changing a hash and possibly some encryption keys, and could just be a handful of validate(), reset() et al functions on the security module.
  - lwhi 3y ago
    Architecture covers the macro, not the micro.
forgotusername6 3y ago
I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.
- Roritharr 3y ago
  From my experience what you are experiencing is a case of "the current architectural best practices disagree with what we are doing successfully" which many organizations and Senior Engineers interpret as reason enough to introduce change. You will probably receive comments along those lines, be in arguments around this. You could also actively ignore this for half a decade and see if the tides are changing again. I can almost taste a push towards "lower amounts of abstraction levels and system boundaries lead to smaller stack traces which have xyz advantages" on the horizon. Hang in there, solve the problems you have.
  - quickthrower2 3y ago
    Just need a new name for monolith. “Partition Tolerant System Design” perhaps.
    - alemanek 3y ago
      I like that. We could always dust off “Modulith” as well.
    - hnlmorg 3y ago
      I assume the PTSD acronym was intentional? Either way, it’s a genius name.
      - chrisweekly 3y ago
        haha, yes, had to be intentional. pitch-perfect.
bunsenhoneydew 3y ago
I really like the C4 model as part of a larger toolset. If you’re also using it then I recommend looking at https://icepanel.io/ https://icepanel.io/ Great tooling strongly based on C4, I use it a lot.
jillesvangurp 3y ago
Depends on the target audience. Mostly the audience is hand wavy types that just want to point at a beautiful thing in a slide to point out "we have stuff with icons that you might know! Look at how beautiful this is. It almost looks like we know what we are doing!". Exaggerating here but anything that fits on a single slide is completely useless to an expert. Not worth drawing unless the goal is to impress non experts like that. It's a marketing tool in that case. The level of detail required for this is "a power point slide". In companies/organizations that are large enough you always get a certain amount of project bureaucracy, ass coverage, and other documentation that doesn't technically do anything more than impress easily impressible types. But it's rarely actually useful. I usually just go straight to the code repositories and ignore things like wikis and other crap. Complete waste of time usually. Show me what you really have. I'll figure it out in no time. Two mistakes people make with these tools: 1. Spending lots of time using them believing that the output is actually useful/valuable to engineers. Your time is more valuable. You should be doing more productive things. Minimize time you spend on drawing pretty pictures. They didn't hire you for your graphical design skills. This is of course subjective and context dependent. Sometimes it's just required to have diagrams. E.g. operations people like having good documentation just as a way to ensure that they can follow strict processes and make good decisions as to what is in their scope and what needs escalating. There's also a certain amount of impressing the customer, senior management, or other stake holders that "we have stuff". The bigger the company, the bigger the need for project bureaucracy like this. But it is bureaucracy and you want to be efficient with it. Quick and easy. 2. Believing that these are design tools. They are not. They are documentation tools. You use them after you build the thing. Before you build the thing, you use something like a white board. Or pen and paper. A napkin. Anything fast and easy that doesn't slow you down. It's transient stuff and when you start building the thing you'll realize half a dozen topics you did not take into account. So, other than as a record of all the design mistakes you are making, such diagrams have no long term value. You document the solution after you found, solved, implemented, and tested all the design problems. Not before. Friendly reminder that the places where you are least likely to find diagrams: - Any kind of large open source project. Or any open source project really. Just not a thing. The bigger and more complicated they are, the less likely it is to have diagrams. Reason: they are redundant and absolutely nobody volunteers to sit down and do them. Just ask yourself: "what would Linus Torvalds say when asked to provide diagrams for the linux kernel". I imagine a fair bit of cursing would happen. - Especially open source projects that are about producing diagram tools. I personally find this highly ironic. People won't eat their own dog food when the dog food is diagramming tools. Diagramming tools are something you build for others to use. Go look for it on Github if you don't believe it. All you will find is toy examples but nothing actually documenting these tools in any level of detail. - Small startups or other companies that are highly innovative and have a fast pace of change happening all the time. Reason: people have better things to do than mess around with diagrams. The rainy afternoon where you really have nothing more valuable than messing around with boxes and arrows to do never really happen. Where do you find people messing around with diagrams? Bloated engineering teams in corporate situations. The more boring the company, the more useless types they employ, the more diagrams you will find. People insisting to each other that "somebody" (not them) should do a diagram. I usually just bounce the question when it comes up. "Great idea, when can you have it done?" Usually the implied suggestion is that I should sit down and waste my time doing a diagram for them that they will never even look at for more than a few seconds. It's write only documentation.
diegoveralli 3y ago
I can't say using vendor specific icons is wrong, clearly a lot of people need just that, but I always miss more generic architectural components in these diagramming tools. That's the problem I have with the `diagrams` Python package (https://pypi.org/project/diagrams/ https://pypi.org/project/diagrams/), I find it extremely useful, but the "Generic" section doesn't even include a "Queue" component, and the "OnPrem" section only includes specific queue products. That Python package is exactly how I like to create diagrams, so I keep using it, but I always have to add my own badly-designed custom icons to it, which look so bad that I wouldn't dare send a PR to add them upstream.
- cmclaughlin 3y ago
  That Python library looks great! Thanks for sharing it.
chrisweekly 3y ago
See HN front-page peer discussion for more on c4model: https://news.ycombinator.com/item?id=37974021 https://news.ycombinator.com/item?id=37974021
deleted 3y ago
[deleted]

grogenaut 3y ago

None of the visuals in the examples are distinct. Usually I have like chrome to a box labeled alb... I'm not sure what c4 is getting me over that

mipselaer 3y ago

Great article. So you could say the current version is just a bunch of icons. Next step is adding meta info to the recourses. I'm currently working on a auto import funcion like you can use in Cloudcraft.

ahoka 3y ago

What a useless crap. It’s an over engineered documentation framework focusing on all the wrong things so some agile consultant can sell more cool aid. I don’t trust anything that is designed someone who last did real projects in the 2000’s OOP Java enterprise craze.

mkl95 3y ago
It's not a hard science. Take the parts that work for your team and scrap the ones that don't.
- politelemon 3y ago
  This is the important bit. C4 in its entirety isn't useful to many orgs and teams, and can be unnecessary overkill. You might end up picking 1 or 2 layers for yourself. You don't have to stick to their software either, use DrawIO if that's what you prefer, but understand the main concepts that C4 is trying to impart about the separation, what goes on the arrows, and how useless icons can be.
- npsimons 3y ago
  > Take the parts that work for your team and scrap the ones that don't. Precisely. Any time someone utters the descriptor "best practice", at best, you do yourself a favor by examining it with a critical eye and judge whether it is a good practice to follow (and a good fit for your project) or not. At worst, you beat back the consultants framing it as "the one and only way to do things (with the implication that everything else is wrong)."
- happytiger 3y ago
  The voice of reason always comes from the trenches.
lwhi 3y ago
I don't know whether your comment is useful or not because all you're doing is ranting and providing personal opinion. Your comment is useless to me; so ultimately I'm not likely to give it any credence.
arcbyte 3y ago
It's 4 diagrams. You can't get much less engineered than that. Whats your background that you have simpler alternatives?
lionkor 3y ago
So so much agree with this. People who think in terms of OOP and design patterns (i.e. bandaids) will think "how else are you supposed to model solutions"? But yes, this is fundamentally an OOP thing, and especially the component layer is very much just fantasy. In no real OOP software do these meat reusable components not have super strong binding to each other. Yeah you may have the SignIn controller and the ResetPassword controller both talking to the SecurityComponent, but in the end that's guaranteed to be implemented in such a way that you cant use any of them without all the others connected, and its likely that testing this means writing a mock for each of them that is so complex it may as well have its own tests. They are thinking of their problem, and building their solution entirely out of blocks made from the words that make up the problem. "We need users to be able to sign in and reset their password" becomes SignIn component and ResetPassword component, when really this is just a matter of changing a hash and possibly some encryption keys, and could just be a handful of validate(), reset() et al functions on the security module.
- lwhi 3y ago
  Architecture covers the macro, not the micro.

forgotusername6 3y ago

I read this article and I'm left with the feeling that my entire application has no layer 3 i.e. the component layer. No single (useful) part of the application can be said to have a well defined interface or to be self contained. The strange thing is that I'm not actually that unhappy about that. I'm now sitting here thinking whether I should be more worried.

Roritharr 3y ago
From my experience what you are experiencing is a case of "the current architectural best practices disagree with what we are doing successfully" which many organizations and Senior Engineers interpret as reason enough to introduce change. You will probably receive comments along those lines, be in arguments around this. You could also actively ignore this for half a decade and see if the tides are changing again. I can almost taste a push towards "lower amounts of abstraction levels and system boundaries lead to smaller stack traces which have xyz advantages" on the horizon. Hang in there, solve the problems you have.
- quickthrower2 3y ago
  Just need a new name for monolith. “Partition Tolerant System Design” perhaps.
  - alemanek 3y ago
    I like that. We could always dust off “Modulith” as well.
  - hnlmorg 3y ago
    I assume the PTSD acronym was intentional? Either way, it’s a genius name.
    - chrisweekly 3y ago
      haha, yes, had to be intentional. pitch-perfect.

bunsenhoneydew 3y ago

I really like the C4 model as part of a larger toolset. If you’re also using it then I recommend looking at https://icepanel.io/ https://icepanel.io/ Great tooling strongly based on C4, I use it a lot.

jillesvangurp 3y ago

Depends on the target audience. Mostly the audience is hand wavy types that just want to point at a beautiful thing in a slide to point out "we have stuff with icons that you might know! Look at how beautiful this is. It almost looks like we know what we are doing!". Exaggerating here but anything that fits on a single slide is completely useless to an expert. Not worth drawing unless the goal is to impress non experts like that. It's a marketing tool in that case. The level of detail required for this is "a power point slide". In companies/organizations that are large enough you always get a certain amount of project bureaucracy, ass coverage, and other documentation that doesn't technically do anything more than impress easily impressible types. But it's rarely actually useful. I usually just go straight to the code repositories and ignore things like wikis and other crap. Complete waste of time usually. Show me what you really have. I'll figure it out in no time. Two mistakes people make with these tools: 1. Spending lots of time using them believing that the output is actually useful/valuable to engineers. Your time is more valuable. You should be doing more productive things. Minimize time you spend on drawing pretty pictures. They didn't hire you for your graphical design skills. This is of course subjective and context dependent. Sometimes it's just required to have diagrams. E.g. operations people like having good documentation just as a way to ensure that they can follow strict processes and make good decisions as to what is in their scope and what needs escalating. There's also a certain amount of impressing the customer, senior management, or other stake holders that "we have stuff". The bigger the company, the bigger the need for project bureaucracy like this. But it is bureaucracy and you want to be efficient with it. Quick and easy. 2. Believing that these are design tools. They are not. They are documentation tools. You use them after you build the thing. Before you build the thing, you use something like a white board. Or pen and paper. A napkin. Anything fast and easy that doesn't slow you down. It's transient stuff and when you start building the thing you'll realize half a dozen topics you did not take into account. So, other than as a record of all the design mistakes you are making, such diagrams have no long term value. You document the solution after you found, solved, implemented, and tested all the design problems. Not before. Friendly reminder that the places where you are least likely to find diagrams: - Any kind of large open source project. Or any open source project really. Just not a thing. The bigger and more complicated they are, the less likely it is to have diagrams. Reason: they are redundant and absolutely nobody volunteers to sit down and do them. Just ask yourself: "what would Linus Torvalds say when asked to provide diagrams for the linux kernel". I imagine a fair bit of cursing would happen. - Especially open source projects that are about producing diagram tools. I personally find this highly ironic. People won't eat their own dog food when the dog food is diagramming tools. Diagramming tools are something you build for others to use. Go look for it on Github if you don't believe it. All you will find is toy examples but nothing actually documenting these tools in any level of detail. - Small startups or other companies that are highly innovative and have a fast pace of change happening all the time. Reason: people have better things to do than mess around with diagrams. The rainy afternoon where you really have nothing more valuable than messing around with boxes and arrows to do never really happen. Where do you find people messing around with diagrams? Bloated engineering teams in corporate situations. The more boring the company, the more useless types they employ, the more diagrams you will find. People insisting to each other that "somebody" (not them) should do a diagram. I usually just bounce the question when it comes up. "Great idea, when can you have it done?" Usually the implied suggestion is that I should sit down and waste my time doing a diagram for them that they will never even look at for more than a few seconds. It's write only documentation.

diegoveralli 3y ago

I can't say using vendor specific icons is wrong, clearly a lot of people need just that, but I always miss more generic architectural components in these diagramming tools. That's the problem I have with the `diagrams` Python package (https://pypi.org/project/diagrams/ https://pypi.org/project/diagrams/), I find it extremely useful, but the "Generic" section doesn't even include a "Queue" component, and the "OnPrem" section only includes specific queue products. That Python package is exactly how I like to create diagrams, so I keep using it, but I always have to add my own badly-designed custom icons to it, which look so bad that I wouldn't dare send a PR to add them upstream.

cmclaughlin 3y ago
That Python library looks great! Thanks for sharing it.

chrisweekly 3y ago

See HN front-page peer discussion for more on c4model: https://news.ycombinator.com/item?id=37974021 https://news.ycombinator.com/item?id=37974021

deleted 3y ago

[deleted]