1.2 剖析架构师角色
架构设计被认为是从问题领域到解决方案的一种桥梁，如图1-9所示。从图中我们可以看到架构设计活动与代表问题域的需求分析活动和代表解决域的软件开发活动都有直接交集，连接着两个软件开发的核心领域。
图1-9 架构设计的桥梁作用
架构师是架构设计的执行者，架构设计的桥梁作用给架构师带来了挑战，意味着架构师需要同时具备处理两个核心领域的能力，即架构师需要能够从问题领域出发推导出满足业务需求的架构体系，同时又能够从实现方法入手设计出能够满足业务架构需求的技术架构体系，最终实现业务架构和技术架构的统一。
1.2.1 架构师角色
1.架构师的活动与系统工程
架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。通常，这个角色需要完成以下4项工作。
（1）识别干系人并让他们参与进来
干系人是业务需求的源头，识别正确的干系人能够确保业务需求的正确性，让干系人参与能够确保业务需求的实时性和有效控制需求变更。
（2）理解和记录系统功能和非功能相关的关注点
通过需求分析，架构师梳理并抽象系统的各项功能性和非功能性需求，并对这些需求进行系统建模。
（3）创建并拥有应对这些关注点的架构定义
对功能性和非功能性需求，从扩展性（Extensibility）、性能（Performance）、可用性（Availability）、安全性（Security）、伸缩性（Scalability）等架构设计的基本要素出发定义架构。
（4）在把架构实现为具体系统的过程中起主要作用
推动架构设计活动按照项目和产品计划有序进行，参与需求、设计评审等各种技术评审过程，并管理系统设计和开发团队的日常工作。
就一个完整的系统开发生命周期而言，架构设计活动有其时效性。图1-10体现了传统瀑布（Waterfall）模型下的系统开发生命周期与架构师参与情况。从图中可以看出在由需求分析和系统建模所构成的系统初始阶段，以及由服务集成和产品接受所构成的最后交付阶段，架构师会较多地参与到系统建设过程中去。具体参与程度取决于系统本身的特征及生命周期模型。
对于类似Scrum的敏捷开发模型，如果把一个个迭代看成是小型的Water-Scrum-Fall模型的话，架构师参与程度实际上也与图1-10所示的结果相类似，即重点参与迭代计划阶段和迭代演示回顾阶段。
图1-10 系统开发生命周期与架构师参与情况
从系统工程维度，架构师根据干系人的业务需求捕获系统功能和非功能相关的关注点，并创建架构描述。架构师对架构描述这一架构设计产物具有拥有权，意味着架构师有权力更有责任维护架构描述并管理其实时性和有效性。同时，架构设计表现在系统过程中是一系列架构定义过程。架构过程的正确性决定着架构结果的正确性，架构师需要跟踪并验证架构定义过程的时机、参与者、技术评审和各项阶段性成果。添加了架构师角色及其职责的系统工程如图1-11所示。
图1-11 架构师与系统工程
2.架构师的分类
基于以上关于架构师的工作内容、参与程度和系统工程的分析，可以看到架构师根据其作用、职责和对系统关注层次的不同，可以分成很多类型。狭义上的架构师往往偏重于技术架构设计。但从广义上讲，业界对架构师的划分有一定的体系，表现在以下3个方面。
（1）根据作用
根据所发挥的核心作用，可以把架构师划分成设计型、救火型、布道型、极客型等类型。相较于传统意义上的设计型架构师，救火型、布道型、极客型等类型的架构师更加偏重于执行某一项特定的架构任务，并不一定会完整参与系统开发生命周期，更不一定会从系统工程的角度去看问题。
（2）根据职责
产品型、基础设施型和应用型等架构师是从其所处的业务和职责出发进行分类的结果。产品型架构师偏重于进行业务架构设计，往往在系统开发前期会重点参与；基础设施型架构师偏重于进行技术基础框架设计，一般采用独立于系统开发生命周期的特有开发模式；常见的系统架构师指的是应用型架构师，正如前文所述，负责将问题领域进行建模并转变成解决方案。
（3）根据关注层次
架构师关注的层次有很多，不同的架构师关注的层次会有所不同，包括但不限于功能、非功能、团队组织和管理、产品运营等方面。
本书所阐述的架构师角色，从作用上讲指的是设计型架构师，从职责上讲偏重于应用开发，并关注于功能、非功能、团队组织和管理等层次。
3.架构师的技能和职责
作为一名合格的架构师，完备的技术领域知识是必备的技能，包括我们在1.1.2节架构演进理论中提到过的分布式系统、缓存、消息中间件、企业服务总线、搜索引擎和批量数据处理等各种目前业务主流的技术体系，也包括软件架构体系结构中所蕴含的架构风格、架构模式和架构模型思想。但针对应用设计型架构师，所需的技能不仅仅限于了解和掌握技术体系，也需要从另外两个层面进行技能拓展。
（1）业务领域知识
在应用程序开发过程中，业务架构驱动技术架构现象非常普遍。提升业务领域知识和提升技术领域知识一样，都对架构设计有直接影响。从这个角度讲，架构师应该具备跨领域的技能。
（2）软技能
无论是传统型软件还是互联网应用，当前的开发模式已不再崇尚靠能力出众的个人来决定系统的产出，而是要靠团队。架构设计同样面临着项目计划同步、第三方服务集成、外部团队协作等团队性活动需求，很多场景下，架构师需要与内部团队、外部团队统一协作才能设计出适合业务发展方向的系统架构。从这个角度讲，架构师应该具备跨团队的技能。
如果一名架构师具备以上能力，那他就可以从事架构设计工作。对于具体的工作内容，任何一名团队成员都应明确其职责并赋予相应的权力，架构师自然也不例外。架构师的基本职责有3点。
●作为技术负责人，从问题领域出发进行抽象和建模并提供系统解决方案。
●与项目经理合作，制定计划、分配资源、组建团队。
●通过自身影响力和协作能力，保证项目按既定计划和成本完成。
定义并记录系统的架构、构建和部署系统的策略、确保架构满足系统的质量属性、促进系统级别决定的产出、确保相关决定与干系人的期望一致、对架构方面的各项指标做平衡性的判断并确保达成一致意见等都是架构师的职责示例。
1.2.2 当程序员遇到架构师
当程序员遇到架构师能否碰撞出火花？我们从程序员的特点和架构师的要求两方面出发做一下对比，对比项包含以下12项。
（1）思维模式
程序员、尤其是年轻的程序员的一大特征就是情绪化思维，对碰到的问题倾向于使用主观意识去寻找方法，同时又有一些顽固，钻牛角尖的场景并不少见。而架构师通常具备全面的思考和分析模式，倾向于使用换位思考从问题的内因、外因出发，找到团队内部和外部能够解决问题的资源，确保问题得以高效解决。
（2）沟通
程序员普遍不善交流，表现在不善于听取别人的意见，更不善于表达自身的想法。而对于架构师而言，了解团队和组织文化，把握政治方向，具备沟通和协商能力是基本要求。
（3）学习
程序员学习积极性高，能力也强，但过于依赖个人经验，并不能很好把握住学习的方向，缺少系统的学习计划和目标。架构师通常具备较强的自我提升意识，明白要学什么及怎么学。
（4）协作
程序员创造力强，但在团队和组织氛围下，缺乏一定纪律性，往往从个人出发思考问题和开展活动。而架构师作为技术负责人，需要通过系统的工程学方法，应用项目管理知识领域及相关工程实践开展团队协作。
（5）推动力
程序员独立思考，有好的想法但并不喜欢分享，更加不会作为推动者去主动落实这些想法。而架构师应具备领导力与推动力，除了技术演进，在团队价值取向、组织趋势把握、组织运营和人才发展等各个方面都可能需要发挥其主导性。
（6）全局高度
程序员由于意识形态和经验的缺失，普遍过多关注细节而缺少大局观。而架构师具备全局观，拥有独特的基于系统架构设计的视图和视角。
（7）方法论
程序员开发能力出众，但缺乏设计和建模的方法论。而架构师善于把握架构设计和系统建模的角度和切入点，并使用一组用于确保成功的手段、方式和流程。
（8）业务
程序员相比业务更喜欢钻研技术，通常不关注业务，不善于从干系人角度出发理解业务并进行抽象。而对于架构师而言，理解干系人的业务痛点，并基于业务需求进行业务抽象和系统建模是其基本工作内容之一。
（9）时间管理
程序员有很强的时间观念，但又不善于管理时间。而架构师善于采用敏捷、迭代的过程来合理安排时间，规避时间管理上的风险。
（10）系统化
程序员拼命工作而不是聪明的工作，因为缺少系统化的工作规程。而架构师需要从系统工程角度出发，对软件开发、项目管理和过程改进等系统过程进行合理规划，形成统一的工作模式，确保团队成员都能在同一节奏上开展开发工作。
（11）产品交付
程序员只关注写“高效”的代码，却不关心“高效”的产品交付。而架构师基于产品交付模型和工具进行产品的快速迭代及实现系统的自动化交付。
（12）实用主义
程序员写“聪明”的代码而不是“简单”的代码，“聪明”的代码并不意味着一定能够带来更好的性能和可维护性，有时候反而成为团队知识传递的一种障碍。而架构师关注实用主义，追求成功而不是完美。
这12项对比中包含的思想和方法论在本书中都会一一展开。接下来，我们先来看一下架构师所应具备的视图和视角。