神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：当代码吞噬世界，公司本身为何还停留在“纸质时代”？将组织架构程序化，或许是终结管理内耗的终极方案。文章来自编译。
上周，当我坐在 ISO 27001 信息安全审核员对面，看着他们费力地查阅我们的文档时，一个念头突然闪过我的脑海：
我们作为一家软件公司，几乎所有的业务运行都在互联的数字系统中完成，然而我们业务的核心——那些政策、流程和组织架构——竟然只是一堆基础文档的集合。
这感觉非常讽刺。我们利用先进工具来实现合规性检查的自动化，将代码存储在版本控制库中，并以“代码化”的方式管理基础设施。然而，在描述和管理公司本身时，我们却退回到了“电子纸张”时代，依靠散落在公司各个角落、口耳相传的零碎信息。
当我反思我们的日常流程时，这种脱节变得愈发明显：我们 90% 的产品、文档、沟通和决策都存在于数字渠道中。这些都是数据。它们存在于云端，分布在专注于处理特定工作流程的 SaaS 解决方案中——而所有这些系统都拥有强大的 API 和程序化访问权限。
然而，在这一切的中心，却坐落着一座由文档构成的孤岛：里面装着我们的雄心壮志、目标、政策和正式架构。而我认为，这些才是至关重要的东西。
其实在考虑 ISO 27001 之前，我们的安全态势就已经很稳固了，因为我们一直在努力满足客户的需求。但在收集控制证据、争论并更新政策措辞、审查文档以及实际审计的过程中，我们额外耗费了数百个人时——而这些时间本可以用在为用户创造更伟大的产品上。
如果我们追求如此丰富的运营数据，为什么能容忍组织数据的匮乏？我们已经通过“基础设施即代码”（IaC）彻底改变了基础设施处理方式，通过 GitOps 管理部署，通过“策略即代码”处理安全问题。
我们看到了其中的红利。
但在呈现我们的组织（即业务运作的核心命脉）时，我们却依然沿用老派的方法。
想象一下，如果我们能以程序化的方式呈现整个组织架构——不是一张静态图片，而是一个有生命、会呼吸的公司数字副本，可以被版本化、查询、测试和自动验证。在这个系统中，政策的变更可以像代码提交一样被追踪，合规性可以被持续监控，人、流程与技术之间的关系也能被清晰地映射和理解。
现有的解决方案（如 HRIS 系统）虽然管理人员数据，但在处理政策关联方面显得力不从心；GRC 工具虽然追踪合规性，却很少能与组织架构建立实质性的联系。我提议我们的眼光要更长远一些。我们要为整个组织创建一个全方位的程序化表示：一份“公司清单（Company Manifest）”，作为组织架构、政策和运营的唯一事实来源。
考虑到这在以下场景中的巨大帮助：
合规审计：审计员无需从各个系统中手动拼凑证据，而是可以直接查询公司清单，在政策与其执行情况之间实现清晰的可追溯性。
政策变更：更新可以进行版本控制，自动化的影响分析可以显示哪些团队和流程会受到波及。
组织设计：领导层可以在实施结构调整前，先在“分级环境（staging environment）”中进行模拟建模，从而更深入地了解这些变动将如何在全公司范围内产生连锁反应。
随着这个想法在脑海中不断盘旋，我发现问题远比答案多。
有没有人尝试过？如果没有，原因是什么？
是因为组织本质上太复杂、太动态，无法用代码表示吗？如果是这样，那似乎与监管和标准背道而驰——因为我们期望企业活动是如此统一且程序化，以至于我们可以可靠地将其贴上合规、违规、合法或非法的标签。
是因为我们还没找到合适的抽象层级——就像“基础设施即代码”为系统管理所做的那样？
工具和概念其实已经具备了：用于呈现组织关系的图数据库、用于描述业务规则的领域专用语言，以及用于集成的 API 优先架构。
也许缺失的只是一个框架，能将这些想法整合在一起，使其既强大实用，又简单易用。
让我们思考一下怎么做才行得通。
在这一节中，我会畅想我对“公司即代码”的期待。然后，我会将其映射到一些能够满足这些需求的系统组件上。
作为一名工程师和业务利益相关者，我希望公司模型具备以下特性：
系统必须能够追踪人、政策和系统之间的关系——类似于代码依赖项追踪。用户应该能轻松地从不同角度审视组织，例如哪些人受某项政策影响，以及谁是该政策的责任人。
明确追踪组织变革，包括操作人、变更内容以及原因。这对于审计和理解组织的演进至关重要。
与现有工具（如 Azure、Slack 等）进行无缝数据交换，以维持最新的组织图景，并根据政策强制执行工具配置。
提供一个“分级环境”，在正式实施前对组织变更进行建模，支持对单个规则和控制项进行自动化测试。
虽然底层由代码驱动，但界面应当足够直观，以便非技术背景的领导层也能有效使用。
要将这一愿景变为现实，需要几块拼图。每个组件都必须解决特定的需求，从而构建出一个既强大又相对简单的系统。
受 Terraform 等“基础设施即代码”工具的启发，让我们想象一种声明式领域专用语言（DSL），读起来很自然，同时能表达正式的结构。
基础语法遵循清晰的模式：
```
EntityType "Identifier" {
References = AnotherEntity.Identifier
Attribute = Value
ListAttribute = [
"Item One",
"Item Two"
]
}
```
每个实体由类型、唯一标识符和一组属性定义。实体之间可以使用点符号相互引用，从而创建出一个构成组织图谱的关系网。
让我们看看如何用这种语言定义一个小型的工程团队：
1.定义组织中存在的角色：
```
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. 为我们的团队创建一个组织单元：
```
OrganisationalUnit "EngineeringTeam" {
Department = "Engineering"
CostCenter = "ENG-001"
}
```
3. 有了这些结构，我们就可以定义具体的人员及其关系：
```
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. 政策定义为合规性构建了框架：
```
PolicyGroup "SecurityPolicies" {
Owner = Person.AliceSmith
}
PolicyRule "MFARequired" {
Group = PolicyGroup.SecurityPolicies
Enforcement = "Mandatory"
ComplianceLevel = "Critical"
}
```
5. 我们可以将这些政策映射到外部要求：
```
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]
}
```
从高层架构到具体的个人政策及其监管含义，这种声明式的方法允许我们构建出组织的完整图景。每个定义都是清晰且自解释的，而实体间的引用形成了一个关系图谱，可以用来分析、验证并用于自动化组织流程。
DSL 中声明的实体构成了一个图谱。
通过这种呈现方式，我们可以受益于将定义组织到逻辑文件和目录中，像处理代码变更一样处理组织变更：在应用之前进行版本化、审查和验证。
这使得通过 Pull Request 审查变更、在发布前测试政策修改、自动生成合规文档，以及随时间推移追踪组织架构演进等实践成为可能。
虽然像 Terraform 这样的“基础设施即代码”工具使用“有向无环图（DAGs）”来确定部署顺序，但组织的结构本质上互联性更强。人管理其他人，政策引用活动，而活动又指向政策，团队之间存在复杂的相互依赖关系。这就需要一个“无向有环图”模型来呈现这些丰富的关系。
```
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: Find all requirements impacted by changing a policy
public IEnumerable<Node> GetImpactedRequirements(string policyId) =>
_nodes[policyId].Relations
.Where(e => e.RelationType == "ImplementsRequirement")
.Select(e => _nodes[e.FromId == policyId ? e.ToId : e.FromId])
.Where(req => req.Type == "ExternalRequirement");
}
```
上面的示例展示了一个基于声明式 DSL 的可查询图结构的初步实现。这种表示方式使得回答结构中涉及多个引用的问题变得更加容易，比方说：“如果我们更改 MFA 政策，哪些外部要求会受到影响？”
DSL 可以定义组织的架构和规则，但模型必须与现实数据相连才有用。这需要一种能够实现以下目标的存储策略：
持久化组织图谱本身
存储与图谱实体相关联的数据（如证据）
允许对拟议的变更进行验证
一种大规模实现的方法是结合几种数据存储：用图数据库存储组织模型，用关系数据库存储关联数据，用事件存储处理审计轨迹和变更追踪。如果你想从小规模开始，也可以将所有这些信息序列化到本地文件系统中。
为了激活外部数据，我们需要一个具有插件架构的集成框架，来桥接组织模型与生产系统。这将处理三个关键方面：（1）从集成的系统（如 GitHub 或 Azure）中收集数据，将证据映射到图谱中的节点；（2）政策验证，通过程序检查收集到的证据是否符合规则；以及（3）政策执行，即组织变更自动触发已连接系统的更新——包括从员工入职配置到访问权限变更不等。
DSL 将通过内置模块或用户提供的插件来提供这些功能，以执行与其他系统交互所需的工作。让我们设想 DSL 里面有一个“控制（Control）”实体，该实体使用自定义脚本对 MFA 使用情况进行常规检查，并将结果链接到合规性映射：
```
Control "MFAMonitoring" {
Implements = ComplianceMapping.MFACompliance
Verify {
Script = "Security/mfa-checks.js"
Methods = [
"allUsersHaveMfaEnabled"
]
Frequency = "Daily"
}
}
```
然后在 security/mfa-checks.js 中：
```
export async function allUsersHaveMfaEnabled() {
const users = await myAuthClient.listUsers()
return users.every(user => user.mfaEnabled)
}
```
该解决方案应当是开放且可扩展的，以最大化其效用，允许自定义集成、验证和自动化。Terraform 的“提供商（Providers）”插件架构在这方面做得很好，尽管在企业系统中检查和修改数据的集成可能需要支持更多的自定义脚本。
对于想要尝试这种方法的组织，可以从小处着手：
仅对组织架构和汇报关系建模。
添加关键政策和合规性映射。
开始连接你最关键的系统。
基于代码的组织声明为技术人员提供了强大的能力，但我们也必须承认，许多业务利益相关者并不具备“代码思维”。
DSL 的优雅之处不应仅限于那些习惯使用文本编辑器和版本控制软件的人。一个真正可用的“公司即代码”解决方案，必须在程序化表达与那些日常做出组织架构、政策和合规决策的业务用户之间建立联系。
这可以通过低代码/无代码界面来解决，其中：
业务领导层通过拖放组织实体和汇报结构进行操作，而系统在后台生成代码声明。
合规官员使用简单的表单定义政策，并能即时通过可视化了解政策影响的业务板块。当法规变更时，他们可以通过视觉高亮快速识别缺口或冲突。
技术人员维护代码库的整洁，并提供数据集成和工具，以在外部系统中落地政策。
通过这种方法，我们既能保持代码模型的严谨性，又能让每个人都能上手使用。通过界面进行的更改会更新底层代码，从而保留那个可以版本化和验证的唯一事实来源。
除了技术可行性之外，真正的希望在于组织层面的收益：更快的审计、更清晰的决策，以及在实施变革前对其影响有更深入的了解。原本花费在合规文档上的数百个小时，本可以投入到创造价值中去。
在这篇文章中，我希望能证明“组织架构代码化”这一环节的缺失，并且它是可以构建出来的。实用吗？还不确定。可行吗？我没有答案。但能否构建出来？是的，我相信可以。
译者：boxi。
发布时间：2026-03-12 08:21
立即订购
在线咨询
返回顶部