管理架构决策：谁构建谁运维，与架构委员会护栏模式

作者不喜欢僵化的技术标准，主张项目团队应该有选择工具的自由——大多数情况下，是否需要工作流引擎最好由团队自己决定，因为如果COE和灯塔项目已经做了足够的内部营销，团队理应了解引擎的好处，能做出理性判断。但完全放任每个团队自选也有风险：决定可能被技术潮流、炒作、个人偏好左右，或者只是有人想试试”早就想玩”的新技术；更重要的是必须让所有人意识到，某些技术选型是几年甚至几十年的长期承诺，其决定和后续维护会影响的不只是当下的团队。一个行之有效的做法是把”选择自由”和”生产环境运维、支持这套方案”的责任绑定在一起，即”谁构建，谁运维”（you build it, you run it）——这个基本原则会让团队清楚意识到他们要为自己的决定负责，从而做出更审慎的选择，更倾向于选择Dan McKinley所说的”无聊的技术”（boring technology，即成熟稳定、没有太多惊喜的技术）。另一种常见方法是成立一个架构委员会，负责定义一些”护栏”：理想情况下这个委员会不规定具体标准，而是维护一份工具/框架的准入清单，团队想用清单之外的技术时必须与委员会讨论，说明需要的框架及理由——这个过程有可能让团队接触到没考虑过的替代方案或维护隐患，也可能说服委员会获得批准；关键是委员会不能拖慢项目进度，要么决策必须足够快，要么允许团队未经批准先行推进（但要清楚知道，如果决定明显离谱，之后可能被要求重新考虑）。作者还见过更严格的管控，特别是针对容易被滥用的过渡性技术——比如某大客户要求任何想用RPA的团队必须先提出具体使用案例，明确让团队意识到自己正在增加技术债务，并要求给出偿还这笔债务的计划（比如日后迁移到正式API）。