5.2 架构师的核心能力
5.2.1 经验
架构师的经验很重要，若没有丰富的实战经验，在架构设计或指导开发时就很难预见哪些地方可能出问题。因为只有经历过才能更深入地理解痛点以及繁华表面的背后所需要填的“坑”。但是，比经验更重要的是要具备深入思考的能力，只有时常对从事的专题领域进行思考总结，才能跳出本位看全局，不断提升自己的判断和分析能力。
在做分析或思考总结时，一般采用结构化思维方法：
●首先梳理目标，理清目标与现在或将来发展的关系。
●其次做现状分析，知道有什么、缺什么、现状与目标的差距，以及眼下首要的任务是什么。
●接下来是路线与措施分析，并制定可以保证有效执行的方案。
●最后是下定决心以较高的执行力来实践。
下面以传统企业几年前的服务治理为例，分析企业机构服务治理的过程。
●目标：改善目前无序的现状，建立服务及交易标准，构建符合企业发展需要的SOA服务平台，为灵活多变的业务提供支撑。
●现状：企业创立多年，已经积累了大大小小几百个系统，因为建设之初上线时间要求得比较紧张，所以大部分套件是采购的成熟的、基于垂直架构体系的商业套件，长期下来，系统如烟囱一样一个一个建立。为了解决信息孤岛，采用了系统集成方案，但是由于在执行过程中接口缺少统一的管理，所以导致系统边界、模块边界模糊不清。解决生产问题的过程中，需要相关或无关的人员一起参与进来才能定位问题，问题排查慢，且需要耗费大量人力。因此当前最重要的是，先建立服务及交易标准，规范新建系统对接，再制定计划指导历史遗留系统改造。
●路线：如何执行是需要好好规划的，具体的规划步骤可以是“找出差距——差距图，明确整改措施——整改图，制定时间表——行动路线图”。
一般来说，传统企业在开始考虑做服务治理时，已经积累了大量接口。接口改造和测试的耗费巨大而且周期长，其中部分系统可能是外包出去的，难以控制。综合企业环境和团队人员等因素，服务治理分阶段执行是比较合适的。第一阶段，通过统一的服务总线和监控平台实现交易的监控，这就需要选择比较成熟的产品和经验丰富的实施商（根据以往经验，有时候有经验的实施商比产品重要），制定交易线服务接入接出规范，并进行服务接入；第二阶段，深入服务治理，将一些基础服务下沉为平台，将流程服务放入BPM（Business Process Management），提高可管理性，为服务自治和预警提供有效手段。图5.1简要描述了服务治理需要考虑的各个方面。
图5.1
5.2.2 沟通
架构师的沟通能力也很重要。在执行决策前，先听取相关干系人的诉求并进行分析，对相关问题进行沟通协调，获得其支持并能够一起合作，这要比单纯的编程能力更为重要，因为编程只是手段，而最终取得好的结果才是目标。架构师还要具备一定的商业头脑，只有这样，才能很好地理解企业战略目标，制定能够帮助企业赢得市场的技术路线，使技术路线与企业战略相匹配。
5.2.3 快速学习
架构师的知识面很广，需要快速地学习知识、快速地掌握并运用，经常将知识沉淀为经验并分享给伙伴，并督导团队执行和创新。关于如何构建自己的知识体系，有如下几点建议。
●保持好奇心和阅读习惯，坚持做笔记。
●深入思考问题背后的根源，学习并掌握原理和方法论。
●经常与人交流，查看知名博主的博客。
●经常总结并分类管理与分享。
表5.1是几年前在没有使用APM类监控工具时，人工排查问题的排查列表（该表展示了一个Web应用对客户反馈生产问题的分析过程，当不知道问题出在哪里时，可以利用这个表对交易线上的每一个点进行确认，不能确认没问题的点就是下一步需要重点分析的地方，经过多轮筛选后一般可以定位到真正的问题）。表中的第五步“知识积累”部分用来对常见问题进行分类总结并保存到知识库，如果团队中有新人加入，则新人可以根据知识库中的材料了解前人的经验。
表5.1
5.2.4 解决问题的能力
架构师的好奇心比较强，喜欢研究问题（很多时候这也是架构师的职责）。然而做技术容易先入为主，会觉得技术的重要程度排在第一位。比如，你所在的项目组接到一个新的接口开发需求，作为架构师你如何处理？
建议以如下的思维方式来考虑问题。
●要不要做（是否与长期IT规划相匹配）。
●应该由谁来做（涉及系统边界问题）。
●如何做（涉及技术栈选择、方案设计等）。
●什么时候做合适（变更的关联分析）。
●如果做了，那么对将来有什么影响（跳出当前局限，站在未来的角度考虑可能有哪些变更，哪些需要当前做兼容设计）。
作为技术管理者，架构师应该在不同的场景内跳入、逃出，着眼大格局，从细节入手，并时时总结，尽量规避先入为主的执行思维（比如，首先考虑使用什么协议及接口规范、如何执行、要多久才能完成、如何规避风险等。并不是说这些不重要，而是不仅限于这些）。