7 ms·
The TFA correctly lists many sins with architecture diagrams, but misses the proverbial forest over metaphorical trees. IMO the mistakes mentioned in these dia
by friendzis 2y ago
The TFA correctly lists many sins with architecture diagrams, but misses the proverbial forest over metaphorical trees.
IMO the mistakes mentioned in these diagrams stem from them actually being component diagrams disguised as architecture diagrams.
While the astute would be technically correct in calling component diagrams a type of architecture diagrams, focusing on components is what typically leads to diagraming mistakes. Component diagrams are really useful when determining what competencies, licenses/subscriptions, etc. are required when for example evaluating fit of project inside of an existing ecosystem.
However, when managing the system or making changes to it, you rarely care whether data is stored on S3 or local minio cluster, because at an interface level S3 merely a protocol. Yet, you do care about data dependencies and control boundaries.
A component diagram may easily just connect application backend to S3-compatible storage component and call it a day, however in a full architectural diagram you would really want to see where e.g. the auth thingie comes from.
- guccihat 2y agoI would say most of the examples in TFA are deployment diagrams, not (software) component diagrams. For all the flaws of UML, at least it taught us to be quite specific in which aspect of the system we are currently modelling.
- biofox 2y agoThe challenge is getting software engineers to learn and use UML properly. As a discipline, we seem to be in a perpetual state of reinventing the wheel, when we have plenty of mature tools and established best practices that people don't care to learn.
- decasia 2y agoI have to confess I am guilty of this — I used to just draw some unstructured circles and arrows on a whiteboard and call it enough. Lately I've been trying to work my way through lots of different diagram types from https://plantuml.com/ https://plantuml.com/, and it does help to wrap my mind around the existing options.
- photonthug 2y agoThere’s truth in what you say and UML has some good ideas, but it’s not the one true way. One problem with it is that even if engineers can read it properly, diagrams often need to do several jobs at once, and communicate something to non-engineers, otherwise you are making diagrams all day!
- opello 2y agoThe various times I've encountered effective UML, it's been an organization's take on how to use it. I can't remember if the UML Distilled book references this kind of dialectic use but it seems like the only way I've seen buy-in for use and maintaining the diagrams as documentation.
- friendzis 2y agoA related issue that we, software engineering people, ignore the design-implement workflow other engineering areas successfully use, mainly because that is not agile enoughtm. Unless teams are bound by some ISO to have design documentation timestamped earlier than feature DoD, engineering process gets flipped on its head and design docs are quite likely to be simply braindumps of some uninterested party rather than formal-ish specifications driving the implementation. > when we have plenty of mature tools and established best practices that people don't care to learn. Hyper-fixation on agile and "move fast and break things" attitude is in part to blame here. You can't really put a timebox on "learn how to use mature tooling" or storypoint "design architecture", when only implementation is rewarded.