I agree very strongly with this, but I build tools in this space, so I'm obviously biased.
IMO, Architecture Diagrams should be code, but there's additional value in describing those diagrams in a way that lets us use metadata to interact with the systems they're describing.
ie: OpenAPI describes an API, and lets me interact with it - it's limited in that it doesn't descirbe how two independent APIs (eg., Microservices) are related. I also believe that OpenAPI has a very poor signal-to-noise ratio, meaning it's hard to read & grok.
I'm one of the creators of Taxi (https://taxilang.org), which provides a language for modelling systems and data.
We also build Voyager (https://voyager.vyne.co) which visualises those models into pretty diagrams.
We also build Vyne (https://vyne.co), which lets you use those some models to run queries against those systems, and handles all the integration for you.
If you're interested in anything in this space, hit me up.
IMO, Architecture Diagrams should be code, but there's additional value in describing those diagrams in a way that lets us use metadata to interact with the systems they're describing.
ie: OpenAPI describes an API, and lets me interact with it - it's limited in that it doesn't descirbe how two independent APIs (eg., Microservices) are related. I also believe that OpenAPI has a very poor signal-to-noise ratio, meaning it's hard to read & grok.
I'm one of the creators of Taxi (https://taxilang.org), which provides a language for modelling systems and data.
We also build Voyager (https://voyager.vyne.co) which visualises those models into pretty diagrams.
We also build Vyne (https://vyne.co), which lets you use those some models to run queries against those systems, and handles all the integration for you.
If you're interested in anything in this space, hit me up.