传统的企业架构设计工作，将生成大量的交付物，具体如：流程层次图、流程集成图、流程架构卡、流程清单、业务对象清单、流程步骤与流程角色映射表、关键控制点清单、业务能力框架、数据资产目录、数据标准、数据模型、数据流图、信息流图、应用分层目录、功能清单、应用全景、业务/应用矩阵、角色/功能矩阵、技术标准、技术服务目录、技术组件清单，等等，数量上可能有几百，甚至上千个之多。然而，从表现形式来看，上述架构工件主要是Word文档、PPT文档、Visio图、Excel表，概而言之，都是非结构化信息，这就导致架构工件的结构化和可管理性较差，从而大大削弱企业架构的指导性和可遵从性，这就助推了“架构即代码”等新型架构理念和实践形式的出现。

架构即代码”（Architecture as Code，AaC），是DevOps文化向企业架构领域延伸的理念和产物，其核心思想是将架构工件（架构图、模型、决策记录、元数据等）视为可以通过版本控制予以管理、可以通过自动化工具生成和验证的“代码”。也唯有此，企业架构才有可能适应快速变化的外围环境。

“架构即代码”的核心内涵

内涵一：架构模型文本化

架构模型文本化，就是在企业架构实践中，使用基于文本的架构建模语言（如ArchiMate的Exchange File格式、C4模型的DSL、Structurizr），将架构模型存储为文本文件，进而使用Git进行版本控制、跟踪每次变更，支持代码审查（Pull Request）流程，并可以自动化生成图表（如PlantUML、Mermaid）。

内涵二：架构验证自动化

架构验证自动化，就是在企业架构实践中，借助ArchUnit等工具或自定义脚本，编写自动化测试脚本，以验证架构模型是否满足预定义的规则和约束，验证的内容包括：架构完整性（是否所有必需的视角都有覆盖）、架构一致性（架构模型内部是否存在循环依赖等矛盾）、架构合规性（是否违反“禁止直接数据库访问”等架构原则）、架构与实现的对应（代码是否实现了架构中定义的服务），等等。

内涵三：架构决策记录（ADR）

架构决策记录（Architectrue Decision Records，简称ADR），就是在企业架构实践中，将重要的架构决策记录为独立的、可追溯的文档，并将之存储在代码仓库中。ADR要求不仅要记录“是什么”，还要记录“为什么”。ADR还要支持架构决策的追溯和复盘，支持新人可以通过ADR理解架构演进的脉络，等等。

内涵四：“架构即代码”的CI/CD集成

“架构即代码”的CI/CD集成，就是将架构验证集成到CI/CD流水线中，以实现持续架构合规，其具体做法有：在代码提交环节，架构师修改架构模型文件（DSL）或ADR文件，提交Pull Request；在自动化验证环节，CI流水线自动运行架构验证脚本（完整性、一致性、合规性）；在代码审查环节，架构师审查变更，重点关注验证报告中的问题；在合并环节，通过后合并到主干分支；在自动发布环节，将架构模型自动发布到架构存储库，更新在线文档和图表；等等。

“架构即代码”的业务价值

商业企业，尤其是集团型或大规模制造企业，其IT环境往往比较复杂，尤其呈现出碎片化特征。在企业架构实践中，采取“架构即代码”的做法，可以为此类企业带来如下业务价值：

价值一：多工厂架构一致性

制造企业通常有多个工厂，每个工厂可能有本地部署、功能相似的MES、WMS、SCADA等IT系统。通过“架构即代码”，可以将“标准工厂架构”定义为可复用的模板（如Terraform模块），所有工厂可以基于该模板做实例化，从而确保架构的一致性。

价值二：OT/IT融合的版本管理

OT/IT融合通常是制造企业数字化建设的重点和难点。在传统的企业架构中，OT系统的配置（如PLC程序、SCADA画面），往往缺乏版本管理。通过“架构即代码”的实践，可以将OT配置纳入到与IT架构相同的版本控制体系中予以管理，进而实现OT/IT的统一治理。

价值三：合规审计自动化

制造企业通常面临ISO 9001、IATF 16949等质量体系认证，以及GDPR、网络安全法等法规要求。通过“架构即代码”的实践，可以将合规要求编码为自动化验证规则，在每次架构变更时自动检查，审计时则自动生成合规报告。

转载自公众号-数字化演易