31–40 of 60 posts
Diagrams are where architecture goes to die. In my experience as a former head IT architect, the value of an architectural process is in management and communications. For example, finding out and documenting where your thought leaders are going (a technology acquisition plan) and how they plan to get there (a technology implementation plan). Those are from COBIT 4 BTW.
Big fan of C4. It's so simple most devs can contribute once some groundwork (initial diagrams) are done. Benefit is that software architecture is owned by the team, not just the architect. Haven't used arc42. Seems mostly a German thing. Has anyone outside German speaking countries experience with it?
Do you have any tools or guides to recommend for devs wanting to learn how to create "C4" documentation?
If "how can I work in software without coding" was an article.
If you value periods of deep focus or 'flow' then believe me, having concise, accurate documentation that explains why, how and what you are building pays off - if only to help you separate the planning from execution process in your own workflow. I don't think any moderately complex software can be written without some degree of planning - but maybe your experience differs
This feels like another scrum workshop or whatever they teach to non tech managers. Forcing a specific workflow without ever explaining why (context -> containers -> components -> code), not a single mention about the problem domain but just a generic framework you are expected to fit all problem domains into. You learn more about the framework before you learn about the problem. Example: "Here's a container! It is e…
This is all I'm typically looking for to fully grok a system: -Working (or whatever is close) application I can play with (sandbox ideally) -Readme with where all the docs are -State Diagram, Flowchart, UML, (show me how & where data flows) -Repo links (Maybe a cloned VM of a dev environment)
For me that’s where diagrams can really shine, plus things like a project‘s roadmap
As with arc42 a colleague phrased it best: “it sounds good, but I have yet to find a good arc42 document“
I have adopted over the last two years to use ArchiMate for application architecture and that works surprisingly well.
Big fan of C4. It's so simple most devs can contribute once some groundwork (initial diagrams) are done. Benefit is that software architecture is owned by the team, not just the architect. Haven't used arc42. Seems mostly a German thing. Has anyone outside German speaking countries experience with it?
The C4 model felt very comprehensive, but by being comprehensive, it failed to actually represent the salient points of the systems we were describing. Move up a layer, and you failed to capture some extremely relevant detail, move down a layer, and you had a bunch of extraneous information all over the place. In practice, most of our diagrams would be zoomed in on a handful of components, and represent other components as a kind of convenient lie. Which obviously wouldn't work if you wanted to understand the whole system at once, but that was rarely out goal when using diagrams.
I think it just felt more focused on the formalism rather than the expression, like drawing flowers according to a guide for drawing roses, and then getting into difficulties when you need tulips.
If "how can I work in software without coding" was an article.
Coding is the tip of the 'working in software' iceberg. If you don't see value in being able to communicate the reasons behind the technical choices and trade-offs you've made, both within your own team and to other stakeholders then you'll quickly find that your coding time is quickly eaten up by people asking you to explain it. If you value periods of deep focus or 'flow' then believe me, having concise, accurate d…