I think the closest that this has come is in the form of GitLab, which pretty famously did a ton of the corporate work in the format of a very open Handbook (https://handbook.gitlab.com/)
In the early years, it was extremely, extremely open and comprehensive. I've definitely looked through it when I wasn't sure how to handle something at work.
As a programmer and founder, I think the idea is incredible, I would just change the understanding of "Code", given that what we've been hearing most lately is that "a markdown file is all you need".
I think it's not too far-fetched to think about standards, cultures, guardrails, compliance, etc. being documented, versioned, but more importantly, verifiable and applicable. In natural language, no code needed.
Isn't this essentially just trying to reinvent ERP (i.e. what SAP has built a 207 billion dollar company at time of writing on and 90% of fortune 500 companies along with endless other large organizations use).
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
I worked in a place where basically everything that happened in the company was implemented as actions within Lotus Notes.
While the choice of implementation and performance were abysmal (Notes was a great/the only choice when the decision was made but 25 years later not so much), the actual idea was amazing and it worked extremely well.
Licensing it as AGPL-v3 throws up an interesting question - given the thing this produces is your company as code, if you use this does your entire company count as a larger work that would need to be open sourced? Or is there an explicit distinction between the "firmware" (excuse me) and the work product?
I suspect hes designed a system for HIS company, which is in a data heavy industry. this doesnt apply to most other types of company, and I suspect when he tries to actually do it, it falls apart when he tries to define any requirement or obligation that stems from legislation. If the law was a coherent and unambiguous specification, thered be no problem, but the reality of it is messy and not so easily defined.
I think that it is a narrow view of a "developer" that imagine reinventing what basically already exist in decade with HR/"people management" management software that are widely distributed.
It is sometimes also done by big ERP and basically available in any big directory and access management platform like Microsoft Entra ID (or whatever is the last current name) and co...
In some big companies, for expenses or performance reviews you have a terrible stack of relationship info and logic involved.
We could even say somehow that the first big entreprise software were creating with that kind of purpose for the modern IT area.
The worst limitation to all of this is users being lazy to input all the info that might be required, or updating it.
For example, how many of you never filled their "address" in their record in the big company internal directory portal because it looks useless and is not mandatory?
It's all cool as long as you keep all of this up to date, and that requires a lot of scrutiny and discipline.
Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.
USM tools is based on Unified Service Management (USM) method, which provides the necessary concepts to take the the vision one step further. The core idea is similar however: everything a company does is a service, and services can be defined as data. The surprising finding from USM is that in practice it is possible to meaningfully define any service only through five types of processes.
As services are data, you can have multiple views on that data. And as all data is in standardized format, it becomes possible to make generic cross-references between USM and for example ISO27K as rules that refer to your data, and those rules can be evaluated. As a result, you can see your ISO27K compliance on a dashboard in real-time.
Well developed and maintained Standard Operating Procedures (SOP) go along way towards repeatable human processes. The hard part is finding the organizational discipline to use/maintain them.
I do this, more or less, for my small law firm. Employee and client information are stored in Recfiles and accessed with GNU Recutils. Adding or changing is a pull request, and all sorts of GitHub actions run. Works pretty well!
Wat, how have I never heard of this! Very cool. Do you have any insights you could share on your own setup, what worked well and what didn't? Are you just storing information in plaintext, or do you use some visualization libraries to make consuming the information a bit easier as well? Very curious about your setup.
- I'm not convinced the graph is necessarily cyclic. Often two codependents are actually dependent on some common bits and otherwise independent.
- this is essentially deterministic propagation of configuration (think dhall, jsonnet, etc) plus reconciliation loops for external state, terraform style — not dissimilar to how the rest of CI/CD should operate, in fact my view is this is an extension of CI/CD practices up the value stream.
I'm definitely strive for something like this when possible.
The DSL described in this post really resonates with me. I recently worked on a programming language that uses similar structures [0]. It lets the user define entities and their shape (Role, OrganisationalUnit, Person in this post) and entries for those entities. It contains a small scripting API that can be used to derive information from these "facts". Company as code could definitely be implemented on top of this.
I always felt the idea of trying to align your code, policy, software and infrastructure so it's easy to do compliance is the bread and butter of devops and devsecops in a regulated environment,
Is this an article by someone who's just done ISO 27001 for the first time and realised that?
I feel like this is kind of missing the point that companies are mainly a group of humans and their roles and responsibilities matter to them emotionally. Managing those expectations and feelings can only be done by other humans that feel empathy (good managers) and abstracting such relationships onto something that can be "versioned, queried, tested, and automatically verified" might create a shitty soulless place to work.
Yes - the author's observations are not wrong. Companies, on paper, are logical. However, as one professor told us in college "All companies are perfect until you introduce the humans".
Humans are messy. Humans work outside of whatever system you create. You can codify all your things all you want, it simply will not capture the operational complexity of a business run by humans.
The problem needs to be flipped on its head. LLMs give us the capacity to do just that. It's far more accurate to analyze what the humans are doing, note deviations and follow up on those where regulatory compliance is required. This captures both written processes as well as their practical implementations.
You're citing the article mid-sentence. The full sentence is:
> Imagine if we could represent our entire organisational structure programmatically instead—not a static picture, but a living, breathing digital representation of our company that can be versioned, queried, tested, and automatically verified.
So yeah, the organisation is living and breathing by virtue of the humans inside of it.
But the representation of its organisational structure refers to a picture of an org chart.
Non-tech people also aspire to have the entire org structure represented digitally.
But in static, proprietary binary formats in file repositories that can only be manually queried.
Our code is already checked into version control and can be programmatically accessed via CI, agents, etc. Our software production environments can already be queried programmatically via APIs. Our issue trackers have hooks that react to support tickets, pull requests, CI. Then there's an airgap where the rest of the org sits with Word documents and pushes digital paper around. Artifacts delivered to customers that must be manually copied, attached, downloaded by hand.
The dream is that modern software development practices would propagate throughout companies.
I've used to do something like this, on a smaller scale and dubbed it "organization as code". As long as you have good enough providers for Terraform/Pulumi you can declaratively specify a lot of the interconnected stuff in a company.
I built this around GitHub as the indentity provider as my interest was declaratively defining repository access control, while also being able to use users public ssh keys to (re)provision services to get them access automatically.
I've done the same thing and I would not call it anywhere near org-as-code either. An organization is much more than a list of responsibilities, people, and compliance requirements.
For the latter, we already have policy-as-code tooling that actually works.
Might be a second language thing. Organization for me is stronger related to the root word organize; label, classify, cluster, etc. than something pertaining to processes and procedures.
> However, when describing and managing our company, we resort to digital paper and tidbits of info distributed across people in the building.
The perception that ISO/IEC 27001:2022 is simply an exercise in document creation and curation is frustrating. It is not, but an auditor cannot be in your company for a year or three, so the result is the next best thing: your auditor looks at written evidence, with things like timestamps, resumes, meeting minutes, agendas, and calendars, and concludes that based on the evidence that you are doing the things you said you're doing in your evidence reviews and interviews.
The consequence if you are not doing these things happens if you get sued, if you get yelled at by the French data protection regulator, or if you go bankrupt due to a security incident you didn't learn from, and your customers are breathing down your neck.
All of the documentation in the world doesn't mean you actually do the things you write down, but we have to be practical: until you consider these things, you aren't aware of them. You can read the standard and just do the best practices, and you'll be fine. The catch is that if you want the piece of paper, you go to an auditor, and people buy things because that paper means that there is now an accountability trail and people theoretically get in trouble if that turns out to be false.
It's like the whole problem with smart contracts is that you can't actually tether them to real world outcomes where the smart aspect falls apart (like relying on some external oracle to tell the contract what to do). Your customers care about ISO because your auditor was accredited by a body like ANAB to audit you correctly, and that reduces the risk of you botching some information security practice. This means that their data is in theory, more safe. And if it isn't, there is a lawsuit on the other end if things go awry.
Um.” Manfred finds it, floating three tiers down an elaborate object hierarchy. It’s flashing for attention. There’s a priority interrupt, an incoming lawsuit that hasn’t propagated up the inheritance tree yet. He prods at the object with a property browser. “I’m afraid I’m not a director of that company, Mr. Glashwiecz. I appear to be retained by it as a technical contractor with nonexecutive power, reporting to the president, but frankly, this is the first time I’ve ever heard of the company. However, I can tell you who’s in charge if you want.” “Yes?” The attorney sounds almost interested. Manfred figures it out; the guy’s in New Jersey. It must be about three in the morning over there. Malice—revenge for waking him up—sharpens Manfred’s voice. “The president of http://agalmic.holdings
.root.184.97.AB5 is http://agalmic.holdings
.root.184.97.201. The secretary is http://agalmic.holdings
.root.184.D5, and the chair is http://agalmic.holdings
.root.184.E8.FF. All the shares are owned by those companies in equal measure, and I can tell you that their regulations are written in Python. Have a nice day, now!”
Interestingly, reading about Yegge's Gas Town got me thinking about this topic. Gas Town aims to create a "dark software factory" where agents organize themselves to build software autonomously with only high-level human direction, so Yegge created a weird rube goldberg fever dream of cats, preachers, diggers, mayors and god knows what else. But why? We already have real human organizations staffed and structured in particular ways that are able to deliver software, why not follow that pattern? With something like this, agents can start with a generic software dev shop and iterate on their own organization, instead of Yegge manually dreaming up what roles and relationships should exist.
A company is more than the function of it's org chart.
There's business description being uncaptured sporadically in every Slack message, watercooler moment and email. (two of those are much easier than the other).
If you boil someone's actual job down to a HR job spec and assume that will suffice... you'll produce both absurdly long HR job specs and still fail to capture the entirety of someone's role.
In the early years, it was extremely, extremely open and comprehensive. I've definitely looked through it when I wasn't sure how to handle something at work.
I think it's not too far-fetched to think about standards, cultures, guardrails, compliance, etc. being documented, versioned, but more importantly, verifiable and applicable. In natural language, no code needed.
One can argue that ERP as code is higher value than whatever it is right now, but to act like this is a totally new idea is insane.
While the choice of implementation and performance were abysmal (Notes was a great/the only choice when the decision was made but 25 years later not so much), the actual idea was amazing and it worked extremely well.
I wrote this post some time ago, and more recently built a thing to do roughly this for my small business: https://github.com/42futures/firm
Had it in practice for about 4 months now and happy so far. It works for me, at my small scale. Hoping to share a follow-up with lessons learned soon.
Licensing it as AGPL-v3 throws up an interesting question - given the thing this produces is your company as code, if you use this does your entire company count as a larger work that would need to be open sourced? Or is there an explicit distinction between the "firmware" (excuse me) and the work product?
Otherwise all software written with a GPLv3 editor would also be GPLv3…or all software built with a GPLv3 compiler would be GPLv3. (Neither are true)
Right down to the low code interface for changes.
In some big companies, for expenses or performance reviews you have a terrible stack of relationship info and logic involved.
We could even say somehow that the first big entreprise software were creating with that kind of purpose for the modern IT area.
The worst limitation to all of this is users being lazy to input all the info that might be required, or updating it. For example, how many of you never filled their "address" in their record in the big company internal directory portal because it looks useless and is not mandatory?
Once I had to go through a security audit at a job I had. Part of it was to show managing secret keys and who had access to them. And then I realized that the list of people who had access to one key was different than the list of the code owners of the service I was looking at, which was yet different than the list of the administrators of that service. 3 different sources of truth about ownership, all in code, all out of sync.
I see only 1.
Admin, access <> ownership.
Fortunately AWS doesn't let you delete S3 buckets with files in them without emptying them first...
USM tools is based on Unified Service Management (USM) method, which provides the necessary concepts to take the the vision one step further. The core idea is similar however: everything a company does is a service, and services can be defined as data. The surprising finding from USM is that in practice it is possible to meaningfully define any service only through five types of processes.
As services are data, you can have multiple views on that data. And as all data is in standardized format, it becomes possible to make generic cross-references between USM and for example ISO27K as rules that refer to your data, and those rules can be evaluated. As a result, you can see your ISO27K compliance on a dashboard in real-time.
Two notes:
- I'm not convinced the graph is necessarily cyclic. Often two codependents are actually dependent on some common bits and otherwise independent.
- this is essentially deterministic propagation of configuration (think dhall, jsonnet, etc) plus reconciliation loops for external state, terraform style — not dissimilar to how the rest of CI/CD should operate, in fact my view is this is an extension of CI/CD practices up the value stream.
I'm definitely strive for something like this when possible.
[0] https://thalo.rejot.dev/blog/plain-text-knowledge-management
Is this an article by someone who's just done ISO 27001 for the first time and realised that?
Humans are messy. Humans work outside of whatever system you create. You can codify all your things all you want, it simply will not capture the operational complexity of a business run by humans.
The problem needs to be flipped on its head. LLMs give us the capacity to do just that. It's far more accurate to analyze what the humans are doing, note deviations and follow up on those where regulatory compliance is required. This captures both written processes as well as their practical implementations.
You're on a tech news website as a reminder.
It is breathing already, in the form of humans doing it.
No need to transform it into a static inflexible code thing.
> Imagine if we could represent our entire organisational structure programmatically instead—not a static picture, but a living, breathing digital representation of our company that can be versioned, queried, tested, and automatically verified.
So yeah, the organisation is living and breathing by virtue of the humans inside of it.
But the representation of its organisational structure refers to a picture of an org chart.
Non-tech people also aspire to have the entire org structure represented digitally.
But in static, proprietary binary formats in file repositories that can only be manually queried.
Our code is already checked into version control and can be programmatically accessed via CI, agents, etc. Our software production environments can already be queried programmatically via APIs. Our issue trackers have hooks that react to support tickets, pull requests, CI. Then there's an airgap where the rest of the org sits with Word documents and pushes digital paper around. Artifacts delivered to customers that must be manually copied, attached, downloaded by hand.
The dream is that modern software development practices would propagate throughout companies.
Automate all the things!
I've used to do something like this, on a smaller scale and dubbed it "organization as code". As long as you have good enough providers for Terraform/Pulumi you can declaratively specify a lot of the interconnected stuff in a company.
I built this around GitHub as the indentity provider as my interest was declaratively defining repository access control, while also being able to use users public ssh keys to (re)provision services to get them access automatically.
For the latter, we already have policy-as-code tooling that actually works.
The perception that ISO/IEC 27001:2022 is simply an exercise in document creation and curation is frustrating. It is not, but an auditor cannot be in your company for a year or three, so the result is the next best thing: your auditor looks at written evidence, with things like timestamps, resumes, meeting minutes, agendas, and calendars, and concludes that based on the evidence that you are doing the things you said you're doing in your evidence reviews and interviews.
The consequence if you are not doing these things happens if you get sued, if you get yelled at by the French data protection regulator, or if you go bankrupt due to a security incident you didn't learn from, and your customers are breathing down your neck.
All of the documentation in the world doesn't mean you actually do the things you write down, but we have to be practical: until you consider these things, you aren't aware of them. You can read the standard and just do the best practices, and you'll be fine. The catch is that if you want the piece of paper, you go to an auditor, and people buy things because that paper means that there is now an accountability trail and people theoretically get in trouble if that turns out to be false.
It's like the whole problem with smart contracts is that you can't actually tether them to real world outcomes where the smart aspect falls apart (like relying on some external oracle to tell the contract what to do). Your customers care about ISO because your auditor was accredited by a body like ANAB to audit you correctly, and that reduces the risk of you botching some information security practice. This means that their data is in theory, more safe. And if it isn't, there is a lawsuit on the other end if things go awry.
Um.” Manfred finds it, floating three tiers down an elaborate object hierarchy. It’s flashing for attention. There’s a priority interrupt, an incoming lawsuit that hasn’t propagated up the inheritance tree yet. He prods at the object with a property browser. “I’m afraid I’m not a director of that company, Mr. Glashwiecz. I appear to be retained by it as a technical contractor with nonexecutive power, reporting to the president, but frankly, this is the first time I’ve ever heard of the company. However, I can tell you who’s in charge if you want.” “Yes?” The attorney sounds almost interested. Manfred figures it out; the guy’s in New Jersey. It must be about three in the morning over there. Malice—revenge for waking him up—sharpens Manfred’s voice. “The president of http://agalmic.holdings .root.184.97.AB5 is http://agalmic.holdings .root.184.97.201. The secretary is http://agalmic.holdings .root.184.D5, and the chair is http://agalmic.holdings .root.184.E8.FF. All the shares are owned by those companies in equal measure, and I can tell you that their regulations are written in Python. Have a nice day, now!”
A company is more than the function of it's org chart.
There's business description being uncaptured sporadically in every Slack message, watercooler moment and email. (two of those are much easier than the other).
If you boil someone's actual job down to a HR job spec and assume that will suffice... you'll produce both absurdly long HR job specs and still fail to capture the entirety of someone's role.