Great article - You are describing some concepts that fit under the umbrella of everything as code. Some elements like infrastructure as code are mature ideas. Others, like Policy as code are more emerging ideas that are less broadly implemented. One of the main benefits of this approach is the ability for LLMs to natively understand the underlying rules and definitions. The current world of human crafted documents are effectively prose. They are written for humans who use their expertise and judgement to interpret them and act accordingly. There is a lot of nuance to these documents. When these documents are put in code (think json, yaml, markdown) they drive more deterministic and accurate outcomes. They allow for automation by LLM’s.
Nice post. I suspect the reason we still rely on text documents is that they handle 'edge cases' (human messiness) much better than code ever can. Code is precise, but that makes it brittle; every tweak requires a validation dance and a data migration.
That said, I'd love to see a proof of concept. You could probably model this quite easily using Python and dbzero (https://dbzero.io) instead of inventing a new DSL. It keeps the barrier to entry low and plays nicely with existing tools.
If you haven't already, you should definitely check out Holocracy. It predates your idea by roughly a decade, but is based around the same ideas - just with a lot of additions. There's also software that you can use to define your company, roles, responsibilities, etc. - if I remember correctly, it was written by a computer scientist as well. It's quite comprehensive and very systemic - and tends to not work in reality, because... humans, and their non-systemic behavior.
My company has been developing usm.tools for some years now. usm.tools is based on Unified Service Management (USM) method and being piloted by several organizations.
In usm.tools, the data is in a database, and not in git, so that it can be edited through UIs by service managers, and we can also refer to other data imported from various Systems of Record in standardized way.
But the core idea is very similar: when your services and processes are defined as structured data, you can provide multiple views to it. But we take it a little bit further. When you define your services based on USM model, you have common concepts that enable the full potential of that DSL vision.
Many other things are already in the pipeline as well, based on similar DSL thinking, including a way to cross-reference between various standards (such as ISO27K) and the USM model. Based on this, it is becomes possible for example to make a dashboard that shows you your level of ISO27K compliance in real time. Or even compliance of your sub-contractor network if you operate in a SIAM setup.
Ever heard of Drata - these are not new concepts and are already commercialised.
Great article - You are describing some concepts that fit under the umbrella of everything as code. Some elements like infrastructure as code are mature ideas. Others, like Policy as code are more emerging ideas that are less broadly implemented. One of the main benefits of this approach is the ability for LLMs to natively understand the underlying rules and definitions. The current world of human crafted documents are effectively prose. They are written for humans who use their expertise and judgement to interpret them and act accordingly. There is a lot of nuance to these documents. When these documents are put in code (think json, yaml, markdown) they drive more deterministic and accurate outcomes. They allow for automation by LLM’s.
Nice post. I suspect the reason we still rely on text documents is that they handle 'edge cases' (human messiness) much better than code ever can. Code is precise, but that makes it brittle; every tweak requires a validation dance and a data migration.
That said, I'd love to see a proof of concept. You could probably model this quite easily using Python and dbzero (https://dbzero.io) instead of inventing a new DSL. It keeps the barrier to entry low and plays nicely with existing tools.
If you haven't already, you should definitely check out Holocracy. It predates your idea by roughly a decade, but is based around the same ideas - just with a lot of additions. There's also software that you can use to define your company, roles, responsibilities, etc. - if I remember correctly, it was written by a computer scientist as well. It's quite comprehensive and very systemic - and tends to not work in reality, because... humans, and their non-systemic behavior.
My company has been developing usm.tools for some years now. usm.tools is based on Unified Service Management (USM) method and being piloted by several organizations.
In usm.tools, the data is in a database, and not in git, so that it can be edited through UIs by service managers, and we can also refer to other data imported from various Systems of Record in standardized way.
But the core idea is very similar: when your services and processes are defined as structured data, you can provide multiple views to it. But we take it a little bit further. When you define your services based on USM model, you have common concepts that enable the full potential of that DSL vision.
Many other things are already in the pipeline as well, based on similar DSL thinking, including a way to cross-reference between various standards (such as ISO27K) and the USM model. Based on this, it is becomes possible for example to make a dashboard that shows you your level of ISO27K compliance in real time. Or even compliance of your sub-contractor network if you operate in a SIAM setup.
https://usm.tools/public/landing/