企业架构师如何选择技术治理模式？

当组织规模达到一定量级，就会不可避免的陷入到技术选型困境中：新技术是否值得被采用、如何判断可行性、替换成本有多高、隐藏陷阱有哪些等等。

大型企业通常会按不同的部门、区域、驻地和其他独出心裁的维度进行划分，以方便组织业务。这些部门区划往往源自兼并和其他重组，它们带来的遗留问题是：技术、架构和许多其他重要技术决策信息分散无序。而企业架构师必须直面这种技术多样性，并制定出一致性战略。

为了使战略行之有效，企业架构师会审视组织中的各种方案，确定哪种方案最为有效，从而鼓励团队采用最佳方案。但是，在决策的“受益人”心目中，企业架构师的角色往往带有负面色彩，这是他们对治理模式的选择所致。不过，开明的组织最近已开始重新思考治理的作用。

三种治理模式

企业架构师的职责是围绕技术选择进行治理，很遗憾，技术选择却是一个模棱两可的术语。目前，有三种现行的治理模式。

控制式治理

遗憾的是，许多组织采用的都是这种控制式治理。在这种传统的命令与控制治理模式中，企业架构师通过重量级治理模式将其选择强加给团队，例如：

“所有新的 Web 开发都应使用 Angular 的最新版本。”

这种情况还算是温和的。我曾见识过一个大型组织中对每个项目强制执行一个真正的拜占庭式软件栈（包括应用程序服务器、发布框架和工业级数据库），直到他们发现一切都被过度设计了方才醒悟。采用这种治理方法的动机通常来自于企业对软件的更深层次的态度：软件是战略方面的还是运营方面的？如果答案是运营，则企业架构师就能利用治理模式来加强一致性，从而节约运营成本。例如，如果人人都在 Java 或 ReactJS 上实现标准化，那么开发人员就能在不同项目中相互替代，培训和工具就会简化，而成本通常也会降低。

但是，命令与控制治理模式的缺点在于对构建软件的态度千篇一律。

针对不同问题使用相同的软件栈不可避免地会导致需求和价值的不匹配。

我曾在一家超大型企业工作，这家企业要求由企业架构团队决定强制执行的标准技术栈，包括 Oracle 数据库、发布框架、若干 XML 库，重量级 J2EE 分布式对象模式以及许多其他复杂的移动部件。当时，我的任务是帮助他们的开发人员调试系统，解决导致应用程序服务器崩溃的问题。

在对话过程中，一名开发人员承认，有7个用户不太喜欢他们的系统。“7个用户！！！”我惊叫。“好吧，最终将多达 25 个，”他羞怯地承认。雪上加霜的是，这个应用程序仅向用户询问若干形式的信息，还会发布一个项目代码，它们可能是几个高中生用 PHP 语言花几个小时编的，而这个超大型企业为此已经花费了几十万美元…而且系统还无法正常工作。“节省成本式治理”模式一个普遍存在的问题是过度设计。

无意中的过度设计是控制式治理模式一个固有的副作用。假设企业架构师的任务是为企业标准确定一个关系数据库。为了进行尽职调查，企业架构师应该拜访各个团队，确定最具挑战性的数据问题，然后再选择一个他们适用的关系数据库。

企业架构师还必须找出报告最具挑战性的团队，选择能够满足其需求的报告解决方案。整合架构、消息传递、NoSQL 数据库以及企业中的所有其他技术也是如此。但是，其副作用是，每个团队都必须面对针对不同类别的最复杂的解决方案。例如，对于关系数据库，能解决最具挑战性的问题的工具会给具有普通数据存储和检索需求（这种情况可能更常见）的团队带来不必要的复杂性。通过强制各团队对不同类别的单个工具进行标准化，企业架构师就会将每个类别中的最大复杂性强加给各团队。

虽然节省成本通常是节省成本式治理模式的主要目标，但遗憾又有讽刺意味的是，由于过度设计了简单的问题，开发和维护成本却成倍增长。

许多现代架构，包括许多微服务项目，都采用另一种模式，指导式治理。

指导式治理

治理的另一个定义对现代软件项目有更好的阐释：

• 作为先例或决策原则

我们看到，更多的开明的企业架构师选择指导式治理，而不会采用传统的治理模式，对每个团队强加相同的技术栈。这种模式通常用于许多微服务架构中，其中每个服务都可以利用唯一的技术栈。这些项目的架构师完全专注于特定服务可能需要的功能，而不是遵循某种标准。例如，与系统的事务部分相比，应用程序的管理部分可能需要适度的扩展功能。

但是，即使是完全不同的技术栈也需要围绕具体操作问题（例如部署、监控、日志记录以及许多其他合适的耦合点）进行通用化。为此，微服务社区已经普及了服务模板和服务网格，以处理运行软件所引起的操作耦合。

微服务模式和命令与控制的整合模式相反。尽管它在隔离架构问题方面具有优势，但也要直面传统方法。许多公司都将金发姑娘治理采取折衷的态度。

金发姑娘式治理

在《演进式架构》一书中，我们以童话故事《金发姑娘和三只熊》里的金发姑娘命名一种治理模式，因为遵循这种模式的架构师力求与童话故事金发姑娘达到相同的结果：找到“恰当”的指导与控制水平。

每个开发团队都拥有唯一的技术栈会产生大量运营成本，并且也几乎不可能让团队成员的技能、运营支持成为复用资产，还会产生一系列其他棘手问题。因此，许多大型企业的企业架构师已采用更细致的方法，在先前的“一招鲜”模式和“荒野西部”微服务模式之间进行细分。

在金发姑娘原则治理模式中，企业架构师选择若干合适的技术栈，评估哪种栈最适合新项目开发。例如，某公司可能会确定适用于大中小不同项目的技术栈，相应地为项目提供指导。这就能使团队和技术与项目之间实现一些互换，同时还所能设法避免强加过度设计。

当然，金发姑娘原则治理模式并不能阻止意志坚定的企业架构师继续施加过于严格的控制。但是，它有望鼓励他们在从更多本地项目层面上考虑技术的价值，抑制在企业层面上过度要求同质化的冲动。

无论企业架构师使用哪种治理模式，大多数公司都面临着如何传播其调查结果的挑战。 这就是 ThoughtWorks 技术雷达的用武之地。

广播式治理

公司规模与沟通详细信息的难度之间存在关联。大型公司的企业架构师面临的困难是：如何使开发人员知道采用什么技术有效，什么未经试用以及应该避免什么。

技术雷达提供了一种在公司内广播这种信息的强大机制。在使用 ThoughtWorks 构建自己的技术雷达工具时，它将创建一个网站，每个条目都是一个超链接，这样就为获取该技术的更多背景信息提供了方便。我们已经看到，应用技术雷达构建技术图谱的团队已经在这些链接背后建立了丰富的资源。

例如，假设一家公司正在试验使用一种 Bob 的 Web 框架。企业架构师需要验证此框架是否能处理他们所需的各种常见应用程序，是否支持操作限制，是否与现有技术选择（例如安全性）以及其他许多注意事项完美配合。他们让三个团队使用新框架来构建应用程序，并在其治理雷达上的相关提示下记录其进度。当开发人员询问 Bob 的 Web 框架时，他们可以指向正在进行的实验，并通过雷达广播初步结果。

在ThoughtWorks官方的技术雷达设计中，我们将技术条目放在不同的环中，以表示团队对这一技术的采纳程度。企业架构师可以轻松地将其重新用于表示治理层级。例如，我们有几个客户用现有类别表示以下内容，构建了治理雷达：

• 采纳：经证明可在企业中使用、并得到良好支持的技术
• 试验：我们正在一个或多个项目上试用的、有前途的工具或技术。我们几个客户在实验中纳入了项目的链接，方便读者深入探究更多细节。
• 评估：企业架构师正在评估的、可能试用的新工具或新技术，其中包括正在积极研究的对象
• 暂缓：就像在 ThoughtWorks 雷达中一样，暂缓并不意味着“立即放弃”，而是“启动新项目时不要使用”。“暂缓”表示企业已弃用此工具或技术，并且提供了更好的替代方法

我们已经看到，企业架构师使用“试验”环为各团队的新试验设置 WIP（在制品）限制。这样，他们就能在团队层面进行有序的试验，同时对其他团队也有清晰的了解，并为“采纳”环获得成功的试验。

使用雷达，企业架构师和其他选择该技术的人员就能向他人展示他们当前的想法。在这种情况下，创建自己的技术雷达并不在于向外界展示自己的技术图谱，而只是作为内部趋势的动态文档。使用这种方法的客户会定期重发布其治理雷达，以确保自己的团队获得最新信息。

尽管在长久以来的工作中，企业架构师一直在进行这种评估，但受其决策影响的开发人员最终却发现，传统的流程并不透明。通过使用雷达创建简便的广播机制，企业架构师就能提供透明度，享受到随之而来的好处。例如，具备某种技术经验的开发人员可以将其经验（无论好坏）插入对话中。使用雷达突出显示试验，可以将架构师以前的象牙塔练习变成任何有关各方之间的社交协作，从而改善意见的多样性。我们鼓励企业架构师将雷达作为治理手段，促进其决策过程的讨论，增强透明度。

第21期技术雷达已经发布，请移步 https://www.thoughtworks.com/radar

本文转载自 ThoughtWorks 洞见。

原文链接：

https://mp.weixin.qq.com/s/6MnzStMOh6lLEYv-Mg9E1Q