《IT架构师成长和认证指南》简介及第3章 IT架构思维（五）

作者写了一本关于IT架构师成长和认证的书，希望先通过连载的形式拿出来分享，结合读者的反馈来不断调整完善。本书希望对于那些想成长为架构师，并在架构师职业发展道路上不断进阶的读者们有所借鉴和指导，也欢迎业内专家不吝赐教和斧正。

目前作者在参与信通院企业架构推进中心企业架构相关成熟度模型标准的制定工作中发现，我们目前不少的企业对于企业架构、解决方案架构（或者系统架构）的概念和范围理解上还存在混淆、偏差和不一致的地方，作者也是希望通过个人和相关业内专家的共同努力，推动企业架构和解决方案架构更加系统性、结构化、标准化，并且开放化地发展。

作者一直以为企业架构理论和实践的发展离不开企业（2B）和个人（2C），企业的架构最终还是需要由具备企业架构思维的人才进行架构运用和实践，所以企业乃至整个社会，对于架构师人才梯队的培养也是非常重要的一环。本人是IBM L3 Thought Leader 级别认证架构师，The Open Group的L3认证杰出架构师，也是TOGAF企业架构，OAA开放敏捷企业架构，以及银行业架构网络BIAN认证架构师。曾任The Open Group 架构标准组合本地化联席主席，负责领导了OAA开放敏捷企业架构标准的本地化、推动TOGAF10标准的本地化、翻译和推动BIAN相关标准的本地化工作；也作为全球企业架构师联合会（AEA）架构师执业证规范特邀专家进行了L1~L3企业架构师及各领域架构师的遵从性标准的制定工作。作者本人也是期望结合自身的架构师成长实践，为企业架构和架构师社区尽自己的一点绵薄之力。

《IT架构师成长和认证指南》全书分成两大部分共十二个章节。

第一部分讲了IT架构是什么，以及如何去做IT架构，包括IT架构思维及不同视角、方面的架构模型和方法。

架构视角包括功能视角的组件模型、数据视角的数据模型、运营使用视角的运用模型；架构方面包括关键的非功能性方面工程学，如性能工程、可用性工程和安全架构。

在架构知识体系化的介绍过程中贯穿以实际的案例，并提供了任务级别的架构模型开发方法和相关的架构制品，确保架构方法的可落地性和实践指导性。

另外还介绍了历来不同的架构风格，流行的架构建模语言和工具，方便读者对当今各种架构的来龙去脉有全面深入的理解，并能够熟练运用各种架构语言进行架构制品的产出，方便在架构社区的交流。

第二部分讲了考察一个架构师的角色和素养有哪些，基于此构建出架构师能力六边形模型，并介绍了IT架构师可获得相关认证的一些行动指南。

《IT架构师成长和认证指南》简介和第一章 什么是IT架构

《IT架构师成长和认证指南》简介及第2章 IT架构师角色和素养

《IT架构师成长和认证指南》简介及第3章 IT架构思维（一）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（二）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（三）

《IT架构师成长和认证指南》简介及第3章 IT架构思维（四）

接上一篇 第3章 IT架构思维（四）

本书第一章介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。在3.5节介绍完如何进行功能性需求和非功能性需求规格化后，本节将介绍架构管理中的一项贯穿IT解决方案架构全生命周期的活动：架构决策，以及作为决策依据之一的架构原则。

3.6 架构决策和原则

梳理和规格化IT需求后，在进行架构设计工作之前，我们需要了解一个贯穿IT解决方案全生命周期的架构管理活动 -- 架构决策。作为一个架构师，无时无刻不面临架构决策，其中有些是影响到整个系统架构的重大决策。面对架构决策，架构师需要有相关的可选方案，并且按照一定的决策依据进行方案决策，一个非常关键的决策依据就是架构原则。所以在进行架构设计活动之前，本节将首先介绍关系到所有架构设计活动的一个架构管理活动--架构决策，以及与之相关联的架构原则。

3.6.1 架构决策

在正式进行架构设计前，我们先了解一个重要的解决方案级的架构制品 – 架构决策（Architecture Decision）。顾名思义，架构决策是在项目或产品架构工作过程中所做的各种决策，这个制品会记录架构决策的整个过程，包括问题背景，假设，决策选项，最终决策，决策依据，以及影响。架构决策会贯穿架构师进行IT解决方案架构的整个过程，从方案建议，到架构开发，再到架构验证。

我们在进行解决方案架构时，可能会面临不同方面的决策，一个决策往往也会有多个选择，比如选择什么样的中间件作为消息中间件，自己搭建缓存服务还是使用云服务商的缓存服务，如何进行数据备份，是基于云厂商的PaaS平台实施，还是基于现有的解决方案。

架构决策的目的是可以让架构师以正式的文档记录影响架构方案的那些关键选择，也让其他人可以了解为什么解决方案长成现在这个样子。还有一个重要的目的是，架构师在平衡不同参与方的关切点和利益时，以架构决策的方式，同所有利益相关方达成关于方案选择的一致性的书面证明。

因而架构决策会包括以下几个重要方面：

1. 决策要解决的问题和相关限制因素。
2. 可选的方案和最后所选择的方案。
3. 选择该方案的理由和造成的影响。
4. 各利益相关方对决策内容认可的签名。

一般架构决策包括以下要素：

1. 架构决策陈述，最后决策方案的陈述。如系统使用消息机制同XYZ系统通信。
2. 唯一索引，架构决策作为重要的交付件，需统一进行管理和编号。如AD-001。
3. 问题描述，决策要解决的问题的前因后果，问题的现状。如系统需要跟XYZ系统间进行大量的信息交换，在保证吞吐量、时效性的前提下，本系统基于什么通信机制实现同XYZ系统通信。
4. 假设和依赖，问题上下文里哪些是必备条件，存在什么样的假设和依赖。如XYZ系统目前支持多种通信方式，包括消息接口，存在消息中间件设施。
5. 可选方案，所有可能的选择方案的列表和说明。如 1-同步实时 2-异步消息 3-文件。
6. 最终决定。如选择 2-异步消息。
7. 选择依据。为什么做这样的选择，可能需要从多个维度进行各可选方案的对比分析，不仅仅从技术层面，可能还有依据的原则，实施成本、时间，风险等的考量。如考虑到通信特征如高频突发性，通信要求如可靠性，实施成本和周期。
8. 影响，做这样的方案决定会带来的影响。如需要引入中间层，对性能存在一定影响，在部署架构时需要考虑新增集成服务器节点部署消息中间件。

要记录以上信息，标准的做法是使用架构决策模板，一个典型的架构决策模板如下表所示。

表3-6 IT架构决策模板

我们看到在进行架构决策时，选择的对比维度可以是多方面的，其中一个很重要的维度是从企业架构约束考虑，其中就包括架构原则、标准规范、专题设计要求。如果最终架构决策违背了架构原则或专题设计的要求，需要上升到企业架构层面进行特例批准。通常对于行业及企业级标准规范，项目或产品层面则需要无条件遵从，不得违反。

3.6.2 架构原则

架构决策是在项目或产品进行架构方案设计时提出的，而架构原则通常是项目或产品外的提出的，架构原则属于企业架构的范畴。如果一个架构决策具有通用的指导意义，可以经过企业架构讨论后提升为企业级的架构原则。

项目或产品架构师需要对企业架构原则有所了解，架构原则作为企业架构的制品，主要由企业架构师和关键利益相关方制定，其往往从企业整体出发，确保企业各解决方案能相互契合。解决方案架构的设计需要遵循原则的要求，如若违背，需要经过企业架构师的确认和批准。

企业通常包括两种类型的架构原则，一种是企业原则，其反映企业是如何实现使命的，如“只在需要不同的时候才允许差异化”、“企业能力服务化”、 “数据是资产”；另一种称为架构原则，反映如何开发、维护、使用企业架构，如“服务开放标准化”、“应用需保持技术中立性”、 “控制技术的多样性”、“安全零信任”，可以从不同的架构领域提出。

一般一个架构原则的描述通常包括以下要素：

1. 1. 原则陈述：原则是什么。
2. 2. 动机和理由：企业原则如何支持战略目标，业务目标，IT目标，保障战略举措、战略主题的。为什么企业希望系统以这样的方式架构，带来的好处。
3. 3. 影响：采用原则给企业和项目带来的影响。从企业整体考虑，原则的采用会带来正面效果，会降低总体的拥有成本，但在项目层面可能会有额外的负担和成本。

企业架构原则需要具备以下几个质量要求：

1. 1. 可理解性：原则的陈述清晰明了，无歧义。
2. 2. 稳健性：原则可以作为项目里的架构决策的依据。
3. 3. 完整性：原则能够适用于不同的情形。
4. 4. 一致性：原则可以灵活解释，确保语义的一致。
5. 5. 稳定性：原则在一定的时间跨度里是稳定的，能够适应变化。企业存在架构原则的修改流程，可以让原则适应环境的变化保持更新。

比如，对于架构原则“应用需保持技术的中立性”，其陈述没有二义性，任何应用都不应该依赖于特定的技术组件，依赖于具体的技术产品来实现。其动机是确保企业的业务能力实现的独立性，不被锁死在特定技术或者不得不依赖于某技术提供商。比如，企业的应用不应该只能在某个公有云服务商部署，其应该具备在不同的公有云灵活迁移的能力。