《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架构思维（四）

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

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

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

本书第一章介绍了IT架构思维需要从三个不同的维度进行思考，满足不同利益相关方的关切，进行架构建模，以支撑起“屋顶”上的功能性需求和非功能性需求。进一步地，我们将架构活动分解成了需求规格化、架构设计、架构验证和架构管理四大部分。本节介绍IT架构活动的全景图，通过全景图，我们可以清楚地看到IT架构活动。

3.8 IT架构活动全景图

一旦赞助方和各利益相关方对意向架构概览达成统一认知并认可后，IT架构师就可以开展具体的架构设计了。在展开描述如何进行具体的架构设计前，我们把3.4节IT架构相关活动进行展开，从而对整个项目的IT架构活动全貌有一个整体的认识和回顾。

图3-11 IT架构活动和制品全貌

可以看到在需求规格化活动中，IT架构师对系统的范围有了明确的界定，对系统功能性需求和非功能性需求也进行了规格化，并且得到了赞助方和关键相关方的确认，架构师也分析了架构设计的相关约束，这些约束可能是来自于业务层面的约束，比如用户的地理分布，使用习惯；也有来自于技术层面的约束，比如企业架构层面的原则要求。

IT架构师接着进行架构思维活动，基于系统范围和需求及约束，结合架构资产，如参考架构、架构框架，形成初步的意向架构方案，即架构概览或称为一页纸架构。在同赞助方和关键利益相关方取得架构方案的一致意见后，IT架构师就可以着手从两个方面进行架构设计，一是建构设计态的系统，二是设计部署态的系统。

设计态系统关注于系统的结构，更多是从业务功能的角度出发，满足用户功能性需求，确定系统主要构成组件和组件间的关系，确定系统所管理或所需要的主要数据实体和它们之间的关系；部署态系统关注于系统如何运行，更多则是从非功能性需求满足的角度出发，确定需要什么样的资源运行系统，各功能如何布放在各资源节点上，确保性能、可用性和安全等系统非功能性需求得到满足。

对于复杂的项目，还可能会设计性能模型，性能模型的建立需要给予非功能性需求的输入，比如不同业务交易的峰值交易量；性能模型的建立需要依赖于组件模型，比如系统划分成的子系统，子系统包含的组件；性能模型还依赖于运用模型的架构输入，比如组件如何分布于部署节点上，采用什么型号的机器和端点作为物理部署节点，这些节点之间是如何进行网络连接的，以及一个典型的业务交易由哪些技术交易组成；性能模型还依赖于原型验证测试出来的性能benchmark输入，比如典型业务交易在实际的部署架构下的跨越各技术节点时各技术交易所消耗的cpu毫秒数。

性能模型可以估算出各个物理节点所需要的规格要求，如CPU数，或者物理节点需要配备的数量，以确保各物理节点在峰值压力下合理的CPU利用率和业务交易和技术交易的合理响应时间。性能模型估算出来的物理节点配置要求则可以作为物理运用模型的输入，用作生产环境资源的采购、搭建和运维等目的。

同样地，复杂项目还会有可用性设计和安全设计，确保可用性目标和系统的安全合规性。这些模型和相关的架构活动会在后面的章节中展开进行说明。

在架构资产里，有对架构建模各模型的规格化要求，也即模型的模型，我们称为架构元模型。

对于组件模型、数据模型和运用模型都有具体的元模型进行约束，我们在进行三种模型建模时需要遵循元模型的要求，元模型就是架构师的通用语言。基于元模型建模的架构模型可以在架构师间无障碍地流通和传阅。

对于如何描述模型，IT架构通常会以UML模型为通用语言，在该通用语言上针对具体的模型特点进行一定地原型化（prototyping）。后面讲到各个架构模型时会对该模型会使用到的元模型表示法有具体地说明。

对于一些新的架构设计，或者较为复杂的架构，或者性能要求较高的架构，在进行大规模功能开发之前，IT架构师可能会先做出一个概念验证原型，通过原型对架构方案进行重要关切的验证，包括方案可行性和性能。

这样架构方案就不仅是停留在纸面上，而是通过原型进行架构可行性和重要架构关切点的验证，这样的做法称为概念验证（Prove of Concept， PoC）。PoC通常会实现一到两个典型的业务功能，基于典型的业务场景，进行相应的可行性验证和非功能性测试。并且在这个过程中会基于验证和测试结果对架构方案模型、工作任务项、作业方法进行调整，确保整个架构骨架、工作方法是可以满足关键功能性和非功能性需求的。

通常通过这个概念原型的性能测试，可以得到一个性能基准（Performance Benchmark），这是非常重要的基准，基于这个基准，IT架构师可以进行更加精确的资源估算，有助于架构师给出部署和运行架构各项资源更加精确的配置要求。性能的估算有多种方式，这在后面章节会讲到，原型验证应该是所有性能估算方法最精确的了。

软件开发工程师根据IT架构师的架构设计进行系统的功能实现，或基于套装软件进行适应性开发，或对现有系统进行封装重构，或进行全新代码开发。系统工程师根据IT架构师的部署和运行架构设计，构建和配置测试环境和生产环境，安装和配置硬件、各种系统软件、中间件系统等，将开发出来的代码或程序组织成各种部署单元，部署到测试环境和生产环境的各部署节点上。

软件测试工程师和IT架构师一起，基于功能性需求和非功能性需求设计各种测试方案和计划，合理安排各测试环境和测试计划任务，对系统进行全方位的测试，完成架构验证。进行组件测试、集成测试和用户验收测试以验证功能性需求得到满足，可以移交给系统的业务部门；进行性能和容量测试、故障测试、安全测试、渗透性测试、系统验收测试以验证系统的各项非功能性需求得到满足，并且可以移交给系统的IT运维部门。

通常情况下，从需求到架构设计，再到架构验证是顺序的过程，如图上的实现箭头所示，然而我们也需要考虑到其反向作用，比如架构设计时，对需求的合理性，需求的优先级或者需求的优化都能给出反馈。在架构验证时，对架构设计也可以提出更加切合实际的修改意见，比如基于原型验证和原型典型场景的性能测试，对物理运用模型中部署节点的尺寸调整（sizing），如单个节点规格和部署节点数的调整。比如基于安全测试，需要在物理运用架构增加安全组件等。

在架构设计和架构验证这两个主要的架构活动中，对于存在争议或者多个方案选择时，可以通过架构决策活动进行决定。架构决策文档作为关键的架构交付件，支持系统的架构设计和架构验证的全过程。在架构设计和验证的整个过程，一系列的架构决策文档支撑起了系统当前架构所呈现出来的样子。

另外，架构师一个很重要的工作就是维护风险和问题日志文档，以便对识别出来的架构和技术方面的风险、问题、假设和依赖进行跟踪解决。可以将风险和问题的解决方案同相应的架构决策文档进行关联，以确保问题可以得到合理的解决，或者风险得到缓解。

架构决策和架构风险管理是IT架构师架构管理活动的两个主要工作内容。

清楚了架构工作的全貌后，我们后面再从架构的各个视角来逐个说明。

（未完待续）

新书推荐：《银行业架构网络BIAN：全球数字化时代金融服务业框架》

（ISBN：978-7-302-67227-2）

《银行业架构网络BIAN（全球数字化时代金融服务业框架）（数字化转型与创新管理丛书）》(（荷）BIAN协会（BIAN Association）著；庄鹏) - 当当图书 (https://product.dangdang.com/29786214.html)

《银行业架构网络BIAN（全球数字化时代金融服务业框架）（数字化转型与创新管理丛书）》([荷]BIAN协会（BIAN,Association）) - 京东图书 (https://item.jd.com/14798518.html)

《银行业架构网络BIAN：全球数字化时代金融服务业框架》译者序 了解本书详情