> Visualize your systems, discover architecture from code, and keep everything in sync.
Not everything.
Lock up your c4 models in a proprietary platform instead of a diagrams-as-code.
Connect to git not to bidirectionally sync c4 models in a preservable text format, but to slurp more info into the golden-handcuffs source of truth.
Avoid detailing how invention intellectual property disclosure and platform security reconnaissance are protected against.
(On the outbound sync, see Structurizer or plant uml c4 for text portable examples, or icepanel.io for JSON metadata export of full models.)
It's a beautiful product and we'd authorize our teams to use it instantly, except for the philosophical and practical non-starters, and we'd need to have a deep understanding for the security model around keys-to-the-kingdom systems.
1. We don't aim to replace diagrams-as-code or lock teams out of portable formats. Archyl focuses on discovering and keeping architecture in sync with reality: export and text-based representations are on the roadmap because portability matters.
2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
3. We do not treat Archyl as a "golden source of truth" for code or IP. The goal is derived metadata and visualization, not ownership of your system definition.
4. Security is taken seriously: scoped access, least-privilege credentials, and no persistence of sensitive source artifacts beyond what's required for analysis. We're working on publishing a deeper security model to make this more explicit.
The philosophy tension you're pointing out is real, and we're trying to earn trust there rather than hand-wave it away. Appreciate the thoughtful critique.
> 2. Git integration today is read-only by design. We intentionally avoid bidirectional mutation of source or models until we can guarantee determinism and auditability.
Our CI/CD regenerates our business and tech knowledge site with full business, product, system, and code docs on every build.
Lack of sync makes your product unusable for us, even though we're your most target market since we are entirely sold on, and practicing, the ethos that leads to this product.
We were among the first users/supporters of Structurizer. We were among the first users of icepanel.io, found it couldn't support our scope*, but ... paid for it anyway (!!!) just to support the concept.
[* Note: It only took them a couple quarters of work to be able to support our or anyone's, scope.]
Also support the work other teams are doing to make smarter (more humane) layouts, we even pay for commercial layout engines if they are drop-in for open source.
We do all this not just because this is the right way to do it even as a solo engineer, but anyone working in this space is contributing towards making architectural thinking and communication as common and portable as markdown, necessary to bridge the silos within most organizations of any scale.
OTOH, if the product doesn't squarely support an ecosystem rather than silo philosophy, we can't (won't) back it. Still, whatever your direction, we applaud working to make a business in this space.
A bit off topic, but I am curious about your experience with Structurizer. My experience wasn't so positive (albeit the general incentive that it's open-source and local).
I am currently working on a new open-source project, completely free to help enterprise manage their authorizations on a ce realized application: https://www.authz.fr/
Main benefits whereas existing projects is the simplicity of use and the frontend web UI which is generally in paid offers.
It comes with Service Development Kits in multiple languages (Go, NodeJS, PHP, Python) and more to come soon.
I hope someone could find something interesting here :)
I just started a month ago. Man, I literally became again a full time developer. No stress, only ideas, beautiful code that is a little bit verbose but really understandable. I think I could explain my code ELI7.
I recommend https://golangnews.com/ too, Not just because of its utility or that it has HN interface but also because Kenny Grant has been contributing to the Go ecosystem for a long time and his code is a pleasure to read.
Doh! Sorry, my bad. There are too many posts like this and for a library, the phrasing is a little odd since I would expect a Go library to be primarily written in Go. I suppose a Go library could be a wrapper around a C or other type of library, but that would not be something worth emphasizing, IMHO.
reply