架构师的修炼

尊龙时凯

王保育

经常会听到，，
，现在金融科技在发生巨变，
，开源的技术、、云化的服务、、
、、标准化的架构模式设计等，，服务是由云厂商提供，，开发是由服务组合或API 调用实现，
，，那么架构师岗位或是在简历上印有架构师头衔的IT从业者的未来何在？？？？架构师在今后企业数字化转型过程中还能发挥什么作用？？
？？

其实大数据也好、、云计算也罢，，
，层出不穷的FinTech发展实际上已经远远超出了许多企业的预料和把控，，，，在互联网发展新时代，
，，企业中谁来深刻地理解客户需求变化和业务挑战，，，，并正确地应用创新科技来加以解决？？谁来掌控企业业务架构、、
、
、信息架构、
、、技术架构的总体框架，，并负责实现跨企业内外不同风格的产品、、技术和服务的集成，，
，，以及指导各领域专家进行业务能力组件的详细梳理、、
、、设计、、
、
、开发、、
、
、测试、、、
、部署和上线？
？
？？

实际上，，架构师就是企业里适合专注在上述重要事项的最佳人选，，，架构师用统一的方法论确保企业IT架构的完整性, 他们可以从技术上负责企业IT-业务的关联
、、、、FinTech的跟进和应用、
、、、复杂项目的规划和试点、、、、架构模型
、
、、、开发、、
、决策、、、、风险管理
、、资产创建和重用,并尽早地作出企业级的重要架构决策以便整个团队有章可循。。。架构师通过了解系统当前状态, 关心问题进展, 并在其变为严重程度之前加以解决, 通过广泛的协作来推动企业的业务和技术进步。。。
。

称职的架构师就象好的登山向导一样,不光有更多的经验和技巧以教导其他成员更好地工作,同时始终坚守正确的企业架构方向并领导团队应对企业真正棘手的业务和技术挑战
。。。那么架构师如何修炼？？？
？架构师岗位都有哪些专业领域方向
？？？
？架构师应有怎样的觉悟意识
？？架构师要具备怎样的知识架构？？架构师构建模型的核心重点是什么？
？架构师的能力层级怎样划分？？架构师的职业发展如何进阶？？？

1.

架构师——领域方向

从架构范围和工作侧重的不同来分析，
，，，架构师岗位有三个大的架构方向，，，企业架构、、
、业务架构、、、方案架构。。。。企业架构(Enterprise Architecture)聚焦企业范围、、、宏观战略、、、架构蓝图、、、、业务、
、信息、、应用
、、、技术架构的总体框架
；业务架构(Business Architecture) 关注业务对象交互、、业务场景、
、、业务能力及其组成
；方案架构(IT Architecture)侧重具体项目或应用层面的功能架构设计及其实现。。。。支撑上述三大架构方向的基础是四大关键架构领域能力，，包括应用架构(Application Architecture)、
、、信息架构(Information Architecture)、
、、、技术架构(Technology Architecture)和集成架构(Integration Architecture)，，，，分别专注于架构设计中的应用功能
、、
、、数据管理、、、技术支撑和系统集成
。。架构师专业领域参考如下图所示意，，其中，
，，一个复杂的方案架构设计可能会需要四大架构领域的不同专家的共同参与和支持
。。。

2.

架构师——职责所在

一个复杂的IT系统建设，，需要多种不同技能团队的共同配合，，就像下图中一所房屋的搭建的卡通画所示意，，，，涉及到用户、、项目经理PM、、架构师、、
、、工程师等，，，，用户提出需求
，
，PM 控制工期、
、
、进度，，工程师完成具体的开发和施工，，
，，那么架构师应该做什么？？他/她应该与客户进行有效沟通，，，，梳理清楚客户需求
，，与项目经理、、、
、技术专家和工程师进行讨论，，，，设计出可行的、、、满足客户需求的、、、同时又在预算范围内的架构方案
，，，，并跟进方案实施和解决服务交付中出现的任何架构相关问题
。
。。
。

这期间，，，架构师扮演了方案设计者、、、、技术领导者、、方法论专家、、团队促进者、、、、项目顾问等多重不同的角色
，，如下表所示意
：

3.

架构师——π型人才

以往大家谈架构师等专业人才的知识结构，，，
，大都提到“T型”结构
，，
，，即只要拥有一定的经验和知识广度，，
，以及单一专长的领域和深度就可成功
，，现在看来
，
，，在当今高度竞争的数字化时代，
，，，只有一种专长的领域还是不够的，，，可能很快会被别人迎头赶上；另一方面
，，复杂的架构设计需要多方面平衡的
、、两个或更多领域的深度知识结构
，，
，，因此，，，，架构师必须拥有“两把刷子”，，，，进化到所谓的“π型员工”，，培养出多项专业才能，，才能让自己两只脚稳稳站立在职场之上。。

所谓“π型人才”，
，，， 上面的一横是指员工本身知识广博、、、经验丰富，
，，
，“π”字下面那两竖指至少拥有两种或更多专业技能，，，，并能将多门知识融会贯通的复合能力，，，它可能逐渐会成为21世纪架构人才的标准。。。。“π型人才”对架构师知识的深度和广度都提出了很高要求
，，，如下图所示意。。。。

广度层面: 不同范围的经验、、、、宏观的视角眼界、、知识广博的通才、、善于吸取不同意见
、
、、对不同议题保持最新的理解、、
、了解如何学习和过滤、
、商业和技术的直觉和感知、、、很好的人脉。。
。。

深度层面: 业务和技术某些领域相当的精深和著名、、、、保持跟进最前沿的科技业务发展、
、、专家级以上的技能、、、实际的技术应用和最佳实践经验、、社区或圈子中的公认技术地位、
、、、众人经常请教
、、听取观点的专家、、、不断学习保持专长技能的更新。。。。

4.

架构师——构建模型

对于架构，，大家并不陌生
，，， 例如常见的建筑架构，，，它是指用建筑材料(石材、、木材或钢筋水泥)搭建的一种用于居住和使用的物体结构, 那么IT架构有什么不同之处
？？？

行业共识的IT架构就是系统的结构或结构集合, 由软件和硬件元素组成，，，，包括它们的外部属性及相互关系。。。架构不仅是系统结构
、
、组件、、、接口交互的简单描述, 它也是一个社交性的构件，
，因为它不但依赖于软件
，，而且依赖于相关方对其系统组成的重要事情的共同理解。。。。

部分企业过去对IT架构重视不够，，，，认为架构就是几张蓝图或Word 文档、、、架构跟基础设施是一码事、、、架构与设计差不多
。
。。其实，，，，架构包含结构、、、组成、、接口，
，
，它比结构内涵丰富，
，，，因为它有动态特征
，，，，例如架构决策；架构不等同于简单的结构
，，它有严格的思考逻辑和活动产出物；架构和设计不同，，，架构创建结构
，，设计细化内容。
。。架构更宏观，，
，描述的是结构, 定义了设计边界, 设计更具体，，，
，描述并实现了架构组成元素的内部行为和细节
；架构设置了设计的大背景并驱动开发，，，，设计通过创建架构元素的内部表现行为并增加架构定义关系的额外细节来实现系统架构的目标；架构也不简单是基础设施，，基础设施是架构重要的和整合的一部分, 但是架构比基础设施涉及更多内容，，，狭隘的架构视角会导致在设计中不能有效地解决问题。。

1995 年, Rational公司的Philippe Kruchten 发表了著名的软件架构"4+1"模型, Architectural Blueprints—The “4+1” View Model of Software Architecture, 描述了软件型系统架构如何基于多个并行视角来满足不同干系人需求, 后来有了IEEE 1471推荐标准，，，之后IBM 公司扩展了视图
、
、视角框架, 推动了架构模型设计的进步，，，架构模型的最佳实践如下：

●模型：是现实的简化和系统的抽象，， 用以更好地理解要创建的系统
；

●视角
：视角是从干系人的关心出发, 提供构建和使用视图的习惯规格，，定义用于构

建架构描述的模型、、、
、术语和技巧；

●视图：整个系统从某个关注角度的一个表达，
，定义一个或多个按照视角中规则创建的架构描述，，
，视图有时也被称为观点
。。。。

一个模型通过一个或多个视图来记录和表达, 一个视角从一组干系人的具体要求出发，，， 给出了解决干系人顾虑的要求和规格，，一个视图遵从这个视角并将总体系统从不同关注点的角度进行表达, 模型、、、
、视图、、视角的关系如下图所示：

架构视图与视角的模型途径可能听上去有些抽象，，
，，为便于理解，，，我们举例来看复杂的建筑设计是如何实现的，
，，，例如
，
，北京奥运会场馆鸟巢建筑，，
，，其中规划
、、运行、、环保、、
、建设等许多部门都对场馆建筑提出了不同要求，，
，对于这些观点要求，，
，我们通过视角的规格描述来要求整个系统的设计、、
、建设等部门做到一一满足
，，也就是设计系统模型的不同视图要遵从上述环境、、造型
、、灯光
、、、、结构视角的要求，，，并且还要综合考虑这些不同视角要求之间的兼容和协调，，，，这其实就是模型-视图-视角架构途径在现实生活中的一个实际应用，，如下图所示：

同样IT架构模型也可以从不同方式和角度来观察，，，，所得到的结果依赖于要表达的视角和上下文，，并因干系人而变。
。。观察架构时，，将架构视角分为基本视角(每行)和交叉视角(每列)，， 基本视角描述可以观察的事物类型和记录方式，，交叉视角控制实际看到的内容
，，它是描述投射到基本视角的过滤器，，，，记录基本视图的工件描述，
，，，其中干系人的顾虑决定交叉视角, 横向的基本视角(行)和纵向的交叉视角(列)相交有很多交叉处, 他们表达了架构设计的特别关注并提供对解决方案的洞察，，，，同时也是架构设计不同视图要达到的目标，
，包括系统会做什么
？
？？？系统如何去做？？？
？以及系统如何被验证? 如下图所示意
。。。。具体实现时是通过架构方法论的过程步骤去完成用例模型
、、系统关系、
、、
、组件模型、、运行模型等架构工件设计。。
。。

5.

架构师——进阶之道

常去星巴克的人们可能看到，，，，星巴克员工的围裙常见有4种颜色
：绿色、、黑色
、
、、咖啡色
、、、紫色
，
，，如下图所示意，，
，，显然这些颜色都有各自的意义，，，并不是所有员工都能穿黑围裙或者特殊的红围裙。。。。这其实是星巴克内部的一种等级制度
，，代表了初级、、、进阶、、高级、、特殊高级，，
，是需要通过进修和比赛等过程才能晋级的。。

架构师也同样有不同的能力等级划分，，包括初级、、、、中级、、高级和大咖级，，差别如下：

●大咖级 IT 架构师 – 思想领袖级 (Executive IT Architect)

■具有创建集成 IT 解决方案以响应客户大型复杂项目需求的综合能力

■具有行业影响力
，，帮助公司业务战略发展并带动高、、、中级架构师的成长

■具有业务技术创新能力，，成为国内外公认的技术领导者并为行业发展做出贡献

●高级 IT 架构师 – 专业级 (Senior IT Architect)

■具有作为 IT 架构师独立实践的能力和生产经验

■在解决方案设计和交付项目中担任首席 IT 架构师角色

■架构设计获得该专业高级成员的认可，，
，，并可以指导中
、、、低级架构师工作

●中级 IT 架构师 – 经验级 (Associate IT Architect)

■具有必备的所有架构师所需要的核心能力

■开始积极实践 IT 架构师角色的一些重点架构设计

■有时还需要一些导师或架构团队负责人的部分指导

●初级IT 架构师 – 入门级 (Junior IT Architect)

■具有一个或多个技术或产品领域的技术技能

■具有IT架构师独立实践所需的基础架构能力

■通常在导师或架构团队负责人的指导下工作

架构师的成长同样是需要时间的打磨和实践的积累
，，有时也需要一些难得的机缘和修炼氛围，
，，，包括好的客户、、好的项目、、、、好的导师、、好的团队等等
。。。
。架构师的修炼是个漫长的过程，，，，起步阶段，
，架构师需要有坚实的理论基础，，，，包括架构设计方法论、、项目管理、、、咨询表达、
、
、行业知识等
，
，，，主要可以通过课程培训去学习
；发展阶段
，，架构师需要方法论实践和架构设计的生产检验，
，，
，主要可以通过项目实战(On Job Training)去提高；提升阶段，，
，架构师需要呈现技术领导力
、、方案创新力和行业影响力，，，主要通过导师指导(Mentoring)去完成
，，
，
，架构师进阶途径如下图所示意：

综上所述
，
，
，架构师在企业扮演着重要角色并在一定程度上影响甚至是决定着数字化转型的进度和成败。。金融科技为企业带来了巨大机遇和挑战，
，如此庞大而快速发展的FinTech架构元素，，，企业如何选择和更好地利用
，
，架构师的工作任重而道远。。。

一个优秀的架构师需要秉持开放的学习心态
，，，，包括遵循行业开放标准，，例如企业架构(TOGAF)、、、、银行业务架构(BIAN)
、、、、标准建模(UML、、ArchiMate)等
，，而不是闭门造车和孤芳自赏。。。。架构师要帮助企业把所有相关的IT元素搭建一个强壮的IT系统，，
，，完成功能和非功能需求，，
，他们要把握方案的静态结构，，，，包括系统的形式、
、、、架构组成及这些元素如何组成一个整体
，，，同时更要掌控系统的动态结构
，，，，包括系统如何实际工作、、、、如何互相交互满足系统需求等。。

一个优秀的架构师要持续坚持自我修炼及顿悟，，，
，不断克服自身的一些缺点，，例如：专注自己擅长领域而忽略其他方面; 相信技术万能, 容易被技术所迷惑; 追求完美，，，不停的设计变动，，，不能在范围
、、、时间、、、资源之间取得平衡; 不习惯重用，
，认为自己能做一切等等，，
，，这样架构师才能适应数字化时代的发展和不断进步，，真正做到知行合一、、、
、宏观和微观相结合及系统化思考，，架构师能力地图参考如下图所示意：

ThoughtWorks 首席科学家 Martin Fowler 在其著名的 “谁需要架构师”《who needs an architect?》一文中提到了一个令人印象深刻的观点：与实体建筑不同, 软件不受制于物理的限制, 软件受限于想象力、
、设计和组织，，，，简单来讲
，，，软件受限于人的特性
，，而非世界的特性，
， “我们已经遇到了敌人，，他就是我们自己” 。。

参考文献

1.企业架构-TOGAF：www.togaf.org

2.业务架构-BIAN： www.bian.org

3.IT 架构-IBM： 《企业数字化转型架构》王保育著
，， 电子工业出版社

4.银行模型-ArchiMate: 《银行业架构网络(BIAN)的ArchiMate®建模符号》王保育译，，The Open Group and BIAN