《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架构师可获得相关认证的一些行动指南。

第1章 什么是IT架构

笔者最近要在老家修个门楼，工作忙，希望全包，就找包工头讲了我的想法，包工头实际测量了门楼位置的长度和宽度，询问了门楼的层数和高度，根据他的经验就给出了报价和工期。等我在外地工作了五个月回老家，门楼总体上已经完成了，除了一些内部的装修工作还在做。我非常奇怪，我想一般建筑工程都得有设计图纸，包工头从来没有给我任何图纸，连手画的草图都没有见到，只是中间打了几个电话询问我门楼二层上放的房间，建议我放一个卧室、一个卫生间、一个书房，朝南放一个阳台，我觉得很合理就同意了。我就很好奇，问了泥瓦工，你没有图纸怎么就知道墙的高度砌到哪，门窗放在哪，阳台挑空多少呢？泥瓦工说，包工头定期过来讲一下，他就心领神会了，不需要图纸。我很感慨，可以说包工头是个很好的项目经理和架构师，跟着他的泥瓦工、水电工都是很好的程序员，只需寥寥几句就领会清楚了。

但是我们如果新建一座小区，毋容置疑建筑公司一定是要跟房产开发商拿到建设图纸的，开发商也是需要请专业的建筑设计公司进行各个楼栋的设计，小区环境的设计，管网的设计，如果是精装修的话，各层室内的设计也需要由专业的装修设计公司来完成。

如果范围再扩大到一个城市，就更需要进行规划和设计了，笔者就曾经在2010年参与过一个城市新区的规划咨询项目，一个城市新区除了进行新区的总体规划，控制性详细规划外，还进行相关的专项规划，比如水系统、通信、综合交通，另外还从低碳、生态、智慧三个方面进行了专项规划，笔者参与的是智慧新区的专项规划。

不难看到，大到一座城市，一个小区，小到一栋建筑，范围越大，涉及利益相关方越多，越需要从不同的关注点进行规划设计，以期在相关方间达成共识。IT架构也一样，越是复杂的系统，涉及面广的系统，越需要进行前期架构设计，预先形成广泛共识，才能保证最终完成解决方案的成功部署。

1.1 IT架构的上下文

架构通常存在两个级别，一个是企业级架构，一个是解决方案级架构。企业级架构是从企业整体的视角来架构建模各领域架构的关注点，包括企业级业务架构和企业级IT架构。解决方案级架构是针对企业各领域架构的架构构建块或者一组架构构建块，进行的解决方案架构设计。企业架构描述的是企业是什么，需要什么能力，而解决方案架构回答的是如何实现和用什么方法、工具实现这些能力，比如是基于现有系统改造，还是全部自开发，还是通过购买套装软件实现这些架构构建块。IT解决方案最终表现为一个个的IT系统或平台的落地实现。本书所指的IT架构是IT解决方案级的系统架构。

图1 本书所指IT架构是系统级别的IT解决方案架构

这里所说的企业可以是以营利为目的的公司，也可以是不以盈利为目的的公益性组织。如上图所示，企业存在于各种外部环境中，这些外部环境包括市场环境、监管环境、社会环境、人才技能水平以及技术进步水平。在外部环境下，企业结合其愿景、使命为实现其价值主张制定了企业战略，据此业务部门和IT部门结合业务机会和可用的技术和借鉴同行、同业实践，制定了业务战略和IT战略以支持企业战略的实现。业务战略和IT战略要落地，需要进行企业级架构规划，以识别和定义出所需的业务能力和IT能力，这些业务能力和IT能力的落地可以确保业务战略和IT战略的落地。那么如何规划出企业级的业务架构和IT架构呢，以及再前面关于如何进行战略规划，在这本书不会继续讲述 ，作者会在另外的业务架构师成长和认证指南，以及企业架构师成长和认证指南等书中进行详细阐述。

本书的关注重点是如何进行解决方案级IT系统的架构设计。爱因斯坦曾经说过，“在产生问题的层次上永远也解决不了问题”，我们要很好地进行解决方案架构的设计，需要将解决方案放到企业架构的角度来看。我们所要架构的IT解决方案其处于企业架构的上下文下，所以企业架构层面的架构原则，架构构建块的界定和定义、构建块相互间交互定义，都形成了解决方案IT系统的范围边界和来在于企业架构的架构约束；企业级架构演进和过渡计划也直接影响到了解决方案级IT系统的工程建设路径和优先级。

我们以城市规划和建筑设计为例。企业架构就相当于进行城市规划，企业架构会从业务架构、应用架构、数据架构、技术架构和安全架构各架构领域方面对企业进行建模，这相当于进行城市的各专项规划，如道路交通、城市功能、雨水排水、公共事业等进行规划；而解决方案IT系统架构需要进行功能性架构设计，以及非功能性方面如性能、可用性、安全进行架构设计，这相当于对一个建筑从建筑的功用性，抗震性，幕墙外观等方面进行设计。所以本书关注的重点是如何进行如“上海中心”这样的大型建筑或者“港珠澳大桥”这样的基础设施的架构设计。另外，本书作为IT架构师认证指南，还会从IT架构师认证的角度来看，IT解决方案架构师通过不同级别的认证所需要具备的架构技能和素养。

1.2 IT架构的定义

国际组织ISO/IEC/IEEE 42010: 2011 对架构的定义是“系统在环境中的基本概念或属性，并体现为要素、关系、设计和演进原则中。”

TOGAF[1]对架构的定义是“组件的结构、它们的相互关系以及管理其设计和随时间演变的原则和准则。”

从架构的定义上不难看出其主要包括三部分的内容，一是静态的元素、元素同元素间的关系，二是如何设计这些元素和元素间的关系，三是这些元素和元素间的关系怎样随时间进行演进。

IT架构的对象是一个系统，系统运行在一定的环境中，需要满足业务和ICT[2]的各种功能性需求和非功能性需求，满足周边环境对系统的各种约束。IT架构就是要说明清楚满足这些需求和约束的要求下，系统重要的组成元素即组件，厘清组件和组件间的关系，说明清楚组件如何部署和运行，并对需求和约束的满足情况进行验证确认，能按照要求成功交付价值，IT架构还需要随着需求和约束的变化做调整优化，形成持续的价值交付。

IT架构是一种动静结合体，作为工程制品，表现为一种静态结构上的关系，也表现为各种动态的行为能力，以及结构关系和行为能力随时间不断做出适应环境的改变描述。架构还是一种工程学科，研究如何为业务问题设计IT 系统解决方案的方法，最好地平衡各利益相关方的关注点，满足功能和非功能需求和环境约束。

综合这两方面的含义，笔者对IT架构的定义为：“在一定的环境下，系统为满足功能和非功能需求和环境约束，平衡各利益相关方的关注点，从设计时和运行时角度进行的组件化设计，这种对组件、组件关系及其行为、演进的模型化表达，以及相关模型化的工程方法称为IT架构”。

1.3 IT架构的价值

跟建筑行业的架构一样，对于如建造门楼这样的简单系统的构建，可能不需要非常正式的架构设计。一个简单系统的搭建，虽然没有纸上的架构设计图，但设计框架也一定在程序员的头脑中，程序员心中也会有基本的架构分层思想，将功能分解到各层组件上进行开发实现，对于简单系统一两个程序员协作能够完成的事情，做正式架构可能也没有太大的必要。然后现实中我们面对的系统一般功能都较为复杂，需要不同角色的人员参与其中，他们可能是项目或产品的赞助方，企业架构师，参与项目或产品设计和部署的业务人员、IT人员，负责系统日常运维的人员，或者是项目或产品的外部合作伙伴，另外系统同系统间也存在大量的逻辑和数据交互，系统还会有不同的分级，如安保等级，可用性等级，灾备等级等。

良好的IT架构，有助于在各个利益相关方之间对解决方案进行更好地沟通，促进各利益相关方的关注点达成平衡。一个复杂的系统，不同的参与者关注的内容往往不同，缺乏从关注者角度描述的系统架构，架构师很难同参与方沟通并达成一致。

另外，如果没有对架构框架和架构组件的规格化说明，程序员可能会从自身的理解和经验出发进行开发，这会导致系统的范围不可控，边界不清晰，层次混乱，代码耦合度高，进而导致系统很难维护，很难集成。如果没有对系统的部署环境和运行要素要求给出规格化的描述，很多运行风险将无法提前识别和得到弥补，真正上线运行后往往会出现系统资源估计不足或过量，安全控制不足，系统可用性和业务连续性考虑不足，进而造成性能和容量瓶颈或者资源浪费，严重的会导致系统崩溃，数据泄漏，数据丢失，造成重大安全生产事故，最终项目或产品失败。

IT架构还有助于识别项目或产品后续开展的任务项，识别任务项的依赖关系，有助于项目计划的制定，对人员资源的要求和合理安排，有利于对项目或产品的成本和预算的估计。

有人会说，敏捷工程方法就不需要IT架构了。其实不然，对于敏捷实践项目，敏捷的IT架构强调的是不做大量的前期架构，但是需要有做初步架构，或者称之为最小可行性架构（Minimum Viability Architecture），确保系统能够在相对明确的架构护栏（Guardrail）内进行开发和部署。对于敏捷项目的架构师，心中更需要有IT架构的全局，在适当的冲刺（Sprint）周期内，识别、安排并完成架构相关的待办事项（backlog），以确保在更加紧凑的周期里完成产品的能力增量部署上线。

也有人说，我买的是商业套件，我就不需要IT架构了。这并不一定正确，商业套件有自己的IT架构设计，然而一个企业往往会存在多种类型的系统，有些是套装软件，有些是SaaS，有些则是自开发系统，如何确保这些系统能无缝衔接，除了好的企业架构设计和原则外，还需要能从需求层面出发进行解决方案构建块的IT架构设计，这样商业套件才可以很好地集成在企业环境中，或者确定套件的哪些功能需要购买以满足IT架构特定方面的需求，更好地将套件融入到解决方案中，融入到企业整体的IT环境中。

还有人说，通过设计思维研讨形成方案就不需要IT架构了。这是不正确的，设计思维更多的是从用户需求出发形成产品需求方案，需要IT架构回答如何做和怎么做的问题，回答成本和实施周期的问题，比如解决方案是怎样的？是否可行？有没有什么风险？

架构工作并不是堆叠文档，一个不维护的文档是没有任何意义的，架构是对可运行系统的镜像反映，是运行系统的模型孪生体。

1.4 本章小结

本章首先说明了本书的IT架构是解决方案级的系统架构设计。然后说明了IT架构是什么。IT架构可以从两种视角来定义，一是IT架构的内容视角，架构的内容包括三个方面，系统或产品的静态结构，动态行为，以及演进变化，需要从功能性需求，非功能性需求，约束的满足几方面评价IT架构的好坏和成功与否。二是IT架构的方法视角，IT架构方法包括IT架构师角色和架构活动，架构活动的输入和输出制品。后续章节会对这两种视角的主要内容进行详细的解读。

IT架构的价值主要体现在利益相关方的沟通和关注点平衡、为项目计划或产品待办事项提供任务输入和时间和成本的估算、为程序员、运维人员提供指导工作的规格化的说明，确保项目或产品范围的可控性，架构要素需求的明确性，架构解决方案的可行性，项目和产品成功要素的可测量性。

[1]The Open Group TOGAF standard, https://publications.opengroup.org/standards/togaf/specifications。

[2]Information Communication Technology的缩写，即信息通信技术。