架构越来越复杂，总架构师应该如何应对

我前面写过一系列文章：《架构师的十八班武艺》、《架构误区系列》、《我理解的可演进架构》，更多的是针对架构师这个角色的一些方法论。但是，随着业务的增长，IT 架构也会随之变大变复杂。而随着架构越来越复杂，总架构师如何定位以及开展工作变得困难。看到太多因为架构的增长，一个好好的架构师逐步沦落为 PM 的例子。

首先，先界定一下架构师和 PM 的区别。架构师也会管人，也会管理风险、跟踪进度，所以这方面不是架构师和 PM 的本质区别。架构师和 PM 的本质区别就是肚子里面有没有货，对于一个 IT 系统有没有专业的认识，对一个项目能不能产生实体上的贡献。说白了就是实和虚的区别。一个架构师“成长”为 PM 是很可怕的事情，对组织、系统、个人都有不可逆的危害。

岔开说一个好玩的事情：「2001 年 7 月。一天，Larry Page 突然决定解雇所有的谷歌项目经理。所有的。」虽然 Larry 这种天才做事情都有点偏激，所以后来才有 Eric Schmidt 的出现。但是，几乎所有的架构师和 PM 都有或多或少有冲突的情况。同时，随着「卓越工程」和「平台工程」的兴起，我们的研发自动化程度越来越过的情况下，PM 在一个项目中的作用只会越来越小。

言归正传。如果要做一个大型系统的架构师，需要怎么取舍，才能真正包括住系统的架构走向，避免做成一个大 PM 呢？

第一，需要对系统做合理的分类和抽象。一个人的精力是有限的，如果关注点过于分散，最终的结果就一定是失控。分类指的是对于所有的应用和服务，需要进行合理的分类和分级。分类的标准可以是展示层、业务服务层、中台服务层、基础架构层这样的层次结构；也可以是客户管理、交易核心、内部运营支撑、合规监管这样的领域划分。在分类的同时还需要进行分级，将应用按照重要程度区分等级，重点关注高等级的应用。一般来说，最高等级的应用最好不要超过 10 个。架构师另外一个很重要的能力就是抽象。架构师需要屏蔽一些底层的技术细节。例如我们在设计一个系统的时候，会重点关注在系统的模型和服务，以及对外部系统的依赖，而刻意的屏蔽一些内部的编码逻辑。对于大型系统的总架构师来说，也是一样的，无非关注的是更高级的应用维度，定位每个应用的主要职责、应用和应用之间的职责边界、应用提供的主要服务（为主链路服务的，辅助的需要刻意的屏蔽一下）。

第二，关注模型和服务。无论是单个系统还是一个大型的 IT 系统集群，服务和模型一定是灵魂。所以，总架构师其他什么都不做，第一优先级一定要对业务架构和数据架构进行把控。当然，随着系统规模的增加，服务和模型规模也会变得非常庞大，所以在这上面也要进行合理的分层。对于模型，需要分成大的业务领域模型和应用内部的模型两个层次。总架构师需要在业务的层面对模型进行把控，对于关键的业务领域，需要对概念模型的设计进行指导和把控。同时，需要对于数据字典和建模标准进行规范，这部分工作可以在总架构的指导下由专门的团队完成。对于服务，服务其实就是产品的技术体现，所以首先需要对产品进行 L1/L2/L3 的分级。总架构重点关注 L1 产品在技术上映射的相应服务的定义和质量标准。如果是对外暴露的服务，一定在关注的范围内。对于服务的关注，首先需要明确服务的标准，是不是用 Restful 方式。其次要对服务的通用数据类型定义进行指导。再次要对服务返回的错误码分类进行指导。最后对于每个重点的服务，一定要参与最终的评审。

第三，实施架构决策。在架构领域，标准和原则是不作数的，只有 case by case 的架构决策才是把控架构方向的最重要手段。所以，总架构再忙，也需要在对外服务、业务模型、系统边界、外部集成方面的重点架构可以进行最终的决策。决策可以有两种方式。如果总架构是带团队的，可以将部分的架构决策下放到团队成员来实施，自己通过团队内部 Review 会议的方式对决策的结论进行复盘和调整。否则就亲自做。不管是那种方式，所有的架构决策都应该有明确的文字记录，包括：背景、可选架构、对比分析、最终结论、后续变化可能。有太多的架构师因为这个事情的繁琐和花精力，将通过架构决策把控架构变成了通过架构标准，最终无法对标准的落地程度进行闭环，很自然的活成了 PM。法律条款很重要，但是没有判例就无法把握司法尺度。所以架构原则可以在大团队或者总架构团队内部达成一致，作为架构决策的理论指导，但是实际的架构决策执行更重要更必不可少。

第四，沟通。这里的沟通包括和业务的沟通，和产品的沟通，以及和各子域架构以及一线研发的沟通。

架构需要满足业务的要求，所以需要和业务在业务重点、业务未来演进方向、市场环境、监管要求等方面进行交流，达成一致。

除非是外包领域，都是用产品的方式来支撑业务。总架构首选需要是一个合格的产品。需要对产品价值主张、产品设计、用户体验上有自己的想法并影响产品经理的工作。模型设计和服务设计会对用户体验产生巨大的影响，这方面需要做双向的沟通。

和子域架构的沟通，首先需要将架构原则进行植入。否则，架构决策过程中会有太多的反复，影响团队效率。然后需要对各子域架构的能力进行考量，查漏补缺。

和一线研发的沟通，是一个双向的过程。首先需要从一线研发的视角了解架构、流程、质量标准上的问题。其次需要将一些架构的最佳实践穿透给到一线研发。

第五，测试和验收。系统的交付质量是生命线。所以总架构一定要在质量形成闭环，不能只管架构设计不管质量交付。首选需要明确质量的流程和标准，比如 CI 覆盖率、契约测试场景覆盖率等指标。其次，对于大的产品建设的主测试的测试分析，需要参与并提出意见。最后对于最终的交付物，需要和产品一起进行验收。如果有业务验收、灰度等环节，需要了解进展以及其中的卡点、问题。

最后，总结。这个不管对架构师本人还是对于团队，都是一个积累。只有写下来的东西才是想清楚的。也只有写下来的东西才能形成互动和交流。