Company is code: What you lack is not a process, but a versionable "organizational DSL"

God Translation Bureau is a compilation team under 36Kr, focusing on fields such as technology, business, the workplace, and life. It mainly introduces new technologies, new ideas, and new trends from abroad.

Editor's note: When code is devouring the world, why does the company itself still remain in the "paper era"? Perhaps programming the organizational structure is the ultimate solution to end management inefficiencies. This article is from a compilation.

Last week, when I sat across from the ISO 27001 information security auditors and watched them struggle to review our documents, a thought suddenly flashed through my mind:

As a software company, almost all of our business operations are completed in interconnected digital systems. However, the core of our business - those policies, processes, and organizational structures - is just a collection of basic documents.

This feels very ironic. We use advanced tools to automate compliance checks, store code in version control repositories, and manage infrastructure in a "code-based" way. However, when it comes to describing and managing the company itself, we regress to the "electronic paper" era, relying on fragmented information scattered throughout the company and passed on orally.

When I reflect on our daily processes, this disconnect becomes even more obvious: 90% of our products, documents, communications, and decisions exist in digital channels. These are all data. They are stored in the cloud and distributed across SaaS solutions focused on handling specific workflows - and all these systems have powerful APIs and programmatic access.

However, at the center of all this sits an island made of documents: filled with our ambitions, goals, policies, and formal structures. And I believe these are the most crucial things.

Actually, even before considering ISO 27001, our security posture was already quite solid because we've always been working hard to meet our customers' needs. But in the process of collecting control evidence, arguing over and updating policy wording, reviewing documents, and conducting the actual audit, we spent an additional hundreds of man-hours - which could have been used to create greater products for our users.

The Missing Link

If we pursue such rich operational data, why do we tolerate the lack of organizational data? We've revolutionized the way we handle infrastructure through "Infrastructure as Code" (IaC), managed deployments through GitOps, and addressed security issues through "Policy as Code".

We've reaped the benefits.

But when it comes to presenting our organization (the core of how our business operates), we still use old-fashioned methods.

Imagine if we could present the entire organizational structure programmatically - not as a static picture, but as a living, breathing digital copy of the company that can be versioned, queried, tested, and automatically verified. In this system, policy changes can be tracked like code commits, compliance can be continuously monitored, and the relationships between people, processes, and technology can be clearly mapped and understood.

A Bigger Vision

Existing solutions (such as HRIS systems) can manage personnel data but struggle to handle policy associations; GRC tools can track compliance but rarely establish substantial connections with the organizational structure. I propose that we look further ahead. We should create a comprehensive programmatic representation for the entire organization: a "Company Manifest", serving as the single source of truth for the organizational structure, policies, and operations.

Consider its great help in the following scenarios:

• Compliance audits: Auditors don't need to manually piece together evidence from various systems but can directly query the Company Manifest to achieve clear traceability between policies and their implementation.

• Policy changes: Updates can be version-controlled, and automated impact analysis can show which teams and processes will be affected.

• Organizational design: Leadership can simulate and model in a "staging environment" before implementing structural adjustments, thus gaining a deeper understanding of how these changes will have a chain reaction across the entire company.

Why Isn't This a Reality Yet?

As this idea kept swirling in my mind, I found that there were more questions than answers.

Has anyone tried it? If not, why?

Is it because the organization is inherently too complex and dynamic to be represented by code? If so, it seems to go against regulations and standards - because we expect corporate activities to be so unified and programmatic that we can reliably label them as compliant, non-compliant, legal, or illegal.

Is it because we haven't found the right level of abstraction - like what "Infrastructure as Code" did for system management?

The tools and concepts are actually already available: graph databases for presenting organizational relationships, domain-specific languages for describing business rules, and API-first architectures for integration.

Perhaps what's missing is just a framework that can integrate these ideas, making it both powerful, practical, and easy to use.

Putting It into Practice

Let's think about how this could work.

In this section, I'll envision what I expect from "Company as Code". Then, I'll map it to some system components that can meet these requirements.

As an engineer and business stakeholder, I hope the company model has the following characteristics:

Queryability

The system must be able to track the relationships between people, policies, and systems - similar to code dependency tracking. Users should be able to easily view the organization from different perspectives, such as which people are affected by a certain policy and who is responsible for that policy.

Versionability

Clearly track organizational changes, including who made the changes, what was changed, and why. This is crucial for audits and understanding the evolution of the organization.

Integration

Seamlessly exchange data with existing tools (such as Azure, Slack, etc.) to maintain an up-to-date organizational picture and enforce tool configurations according to policies.

Testability

Provide a "staging environment" to model organizational changes before formal implementation and support automated testing of individual rules and controls.

Usability

Although driven by code at the bottom layer, the interface should be intuitive enough for non-technical leadership to use effectively.

To turn this vision into reality, several pieces are needed. Each component must address specific needs to build a system that is both powerful and relatively simple.

The Declarative Language of the Organization

Inspired by "Infrastructure as Code" tools like Terraform, let's imagine a declarative domain-specific language (DSL) that reads naturally while expressing formal structures.

The basic syntax follows a clear pattern:

EntityType "Identifier" {

    References = AnotherEntity.Identifier

    Attribute = Value

    ListAttribute = [

        "Item One",

        "Item Two"

    ]

}

 

Each entity is defined by its type, a unique identifier, and a set of attributes. Entities can reference each other using dot notation, thus creating a network of relationships that form the organizational graph.

Defining the Organization

Let's see how to define a small engineering team using this language:

1. Define the roles that exist in the organization:

Role "SoftwareEngineer" {

    Responsibilities = [

        "Write clean, maintainable code",

        "Participate in code reviews",

        "Document technical decisions"

    ]

}

 

Role "EngineeringManager" {

    Responsibilities = [

        "Provide technical leadership",

        "Conduct performance reviews",

        "Manage team resources"

    ]

}

 

2. Create an organizational unit for our team:

OrganisationalUnit "EngineeringTeam" {

    Department = "Engineering"

    CostCenter = "ENG-001"

}

 

3. With these structures in place, we can define specific people and their relationships:

Person "AliceSmith" {

    FullName = "Alice Smith"

    Role = Role.EngineeringManager

    Unit = OrganisationalUnit.EngineeringTeam

    Email = "alice.smith@company.com"

}

 

Person "BobJohnson" {

    FullName = "Bob Johnson"

    Role = Role.SoftwareEngineer

    Unit = OrganisationalUnit.EngineeringTeam

    Manager = Person.AliceSmith

    Email = "bob.johnson@company.com"

}

 

4. Policy definitions build a framework for compliance:

PolicyGroup "SecurityPolicies" {

    Owner = Person.AliceSmith

}

 

PolicyRule "MFARequired" {

    Group = PolicyGroup.SecurityPolicies

    Enforcement = "Mandatory"

    ComplianceLevel = "Critical"

}

 

5. We can map these policies to external requirements:

 

ExternalRequirement "ISO27001_A9_4_1" {

    Standard = "ISO 27001:2013"

    Control = "A.9.4.1"

    ComplianceLevel = "Mandatory"

}

 

ComplianceMapping "MFACompliance" {

    Requirement = ExternalRequirement.ISO27001_A9_4_1

    ImplementingPolicies = [PolicyRule.MFARequired]

}

 

From the high-level architecture to specific individual policies and their regulatory implications, this declarative approach allows us to build a complete picture of the organization. Each definition is clear and self-explanatory, and the references between entities form a relationship graph that can be used to analyze, verify, and automate organizational processes.

The entities declared in the DSL form a graph.

Through this presentation, we can benefit from organizing the definitions of the organization into logical files and directories and handling organizational changes like code changes: versioning, reviewing, and verifying before application.

This makes it possible to review changes through Pull Requests, test policy modifications before release, automatically generate compliance documents, and track the evolution of the organizational structure over time.

Building the Model

While "Infrastructure as Code" tools like Terraform use "directed acyclic graphs (DAGs)" to determine the deployment order, the structure of an organization is inherently more interconnected. People manage others, policies reference activities, and activities point back to policies, and there are complex interdependencies between teams. This requires an "undirected cyclic graph" model to present these rich relationships.

public record Node(

    string Id,          // e.g. "Person.AliceSmith"

    string Type,        // e.g. "Person", "PolicyRule"

    List<Edge> Relations = null

);

 

public record Edge(

    string FromId,

    string ToId,

    string RelationType, // e.g. "ManagedBy"

);

 

public class CompanyGraph

{

    private Dictionary<string, Node> _nodes = new();

    private List<Edge> _edges = new();

 

    public void AddNode(string id, string type) =>

        _nodes[id] = new Node(id, type);

 

    public void AddRelation(string fromId, string toId, string type)

    {

        var edge = new Edge(fromId, toId, type);

        _edges.Add(edge);

        (_nodes[fromId].Relations ??= new()).Add(edge);

        (_nodes[toId].Relations ??= new()).Add(edge);

    }

 

    // Example