[架构之路-6]：架构师 - 架构师应该具备的架构思维

目录

前言：架构师的位置

一、客户业务与需求分析环节

1.1 客户痛点、问题 VS 软件设计本身

1.2 客户价值 VS 架构设计

二、规范与设计环节

2.1 完美 VS 适合

2.2 适合VS 前瞻性+潜在演进

2.3 持续演进 VS 稳定性

2.4 功能性需要 VS 非功能性需求

2.5定性 VS 定量

三、开发与测试环节

3.1让听到炮火声的人决策

3.2 架构的改进必须支持可测试、可验证的

四、端到端的系统思考

4.1 端到端思维 VS 软件设计

4.2 架构是各种技术性功能组件的结构化交互

4.3架构是包含各种非技术因素的权衡

五、非技术新思维

5.1 技术是架构师的立足之本

5.2沟通协调的思维

5.3领导力和影响力思维

5.4 创建和变革力

5.5 持续学习

5.6坚守与拓展

5.7持续改进自己

前言：架构师的位置

本文探讨，作为贯穿产品开发的多个环节的产品或软件架构师，通常需要哪些架构思维。

架构是贯穿始终：客户-》需求-》规范-》设计-》开发（硬件、软件、测试）

一、客户业务与需求分析环节

1.1 客户痛点、问题 VS 软件设计本身

架构不仅仅是没有生命的目标软件/硬件系统，它也承载着公司的长期的价值，承载这为客户解决问题的职责。因此，在分析一个新的需求对现有系统的影响时，需要清晰的知道，该需求到底解决什么样的客户的痛点和问题。明白客户的痛点，明白后续是否有相关的持续性的新的需求，明白当前的架构方案是否能够能够解决客户的痛点和问题，才能更有针对性地在众多架构方案中进行权衡和选择。

架构不是单纯脱离用户痛点的软件或目标系统的架构设计问题，不单纯的是技术问题。

1.2 客户价值 VS 架构设计

无论是设计架构，还是架构设计时内部方案的争论和选择，还是不同优先级功能的实现的顺序，或者判断需要是否是伪需求、真正的需求，一个最重要的决策依据之一就是对客户价值的大小。

1.3 需求收集与需求分析

参考：

/hiwangwenbing/category_11994217.html

二、规范与设计环节

2.1 完美 VS 适合

架构设计不要追求最先进、最高大尚、最复杂。

如果业务目标是建一个小学校，就没有必要设计成宫殿的架构。

如果业务目标是建一个商场，就没有必要设计成教堂的架构。

适合是架构设计的基本原则，要能接收不完美，不要过度设计。

2.2 适合VS 前瞻性+潜在演进

适合的架构设计，是指不要过度设计，并不是说，我们不需要前瞻性和扩展性设计。

我们需要根据当前客户的需求，推测客户的问题与痛点，并根据当前的需求，推测客户未来有可能基于当前的需求和痛点，提出新的增量需求。因此，我们在设计架构时，需要有前瞻性和扩展性，避免当前设计的架构僵化，不能扩展，当有新的相关联的需求时，需要进行大的改动。

2.3 持续演进 VS 稳定性

适合的架构设计，是指不要过度设计，并不是说，我们不需要持续的演进。

实际上，一个系统的架构，需要进行持续的演进才能保持系统的生命力。

持续演进的原则有：

（1）前沿性：尽量采用业内新的最佳实践，而不是最追求新的没有尝试过的小众设计。

（2）有增量价值：如性能的提升、可维护性的提升等等。

（3）承担一定的风险：任何价值的改动，都会带来一定的风险，几乎不存在没有任何风险的架构的改进。为了能够长期演进，长期保持旺盛的生命力，需要承担一定的风险。

2.4 功能性需要 VS 非功能性需求

架构的演进，一方面是由于客户功能性的需求驱动的；另一方面是由非功能的需求驱动的。

非功能性需要是隐性的，容易被客户、产品经理、项目经理等忽略。

这些非功能性的隐性的特征包括：

（1）架构的可维护

（2）架构的可演进性

（3）架构的可扩展

（4）架构的可移植

2.5定性 VS 定量

由于下列原因，项目经理和产品经理推动架构的演进的动机并不是那么强烈。

（1）架构的演进，并不一定直接带来用户功能上的增加。

（2）架构的演进需要承担一定的风险

（3）架构改进带来的巨大的非功能性的客户价值是隐性的。

因此，要推动架构的演进，是有一定的难度和阻力的。为了推动架构的演进，我们除了提供定性的说明，说明架构带来的好处之外，还需要提供定量化、数字、仿真的数据，来支撑我们推动架构的改进。

有了数据作为支撑，就可以把隐性的价值，显性化。有助于我们推动架构的长期演进。

三、开发与测试环节

3.1让听到炮火声的人决策

并非所有的有争议技术的决策都要架构师，实际上，很多架构相关的决策，需要听取开发领域的技术专家和代码专家的意见。他们是直接编写代码的人，他们是最前线的战士，他们的能够带来架构是看不到的信息和建议。

如果说，系统工程师可以勉强不需要看代码，但架构师是必须熟悉代码。大多数情况下，脱离代码的架构师，并不是一个好的架构师，特别是一线的架构师、软件实现层面的架构师。当然，纯业务层面的架构师，是可以不需要研究代码的。

3.2 架构的改进必须支持可测试、可验证的

当设计一个新的业务需求时，当在多种功能进行权衡时，必须要考虑新的改动是可测试、可验证的 。一个新功能的改动、架构的改动是不可测试的是非常危险的、潜在极大的风险。

四、端到端的系统思考

4.1 端到端思维 VS 软件设计

产品或软件的架构与需求不同，需要在产品或软件开发的前端。

有一种错误的思维，认为架构发生在是在产品或软件的设计阶段，是在需要和开发之间的一个环节。

实际上，架构是贯穿始终：客户-》需求-》规范-》设计-》开发（硬件、软件、测试）中的每个环节，散布在目标系统的每个毛孔和肌肤。架构不仅仅是没有生命的目标软件/硬件系统，它也承载着公司的长期的价值，承载这为客户解决问题的职责。因此，架构师在进行架构设计和影响分析时，需要有这种端到端的思维。

4.2 架构是各种技术性功能组件的结构化交互

在一个目标系统中，整个系统是由无数个纵向和水平切分的组件构成的，组件与组件之间存在大量的动态的交互。因此，在设计一个新的功能需要时，架构师必须思考：

（1）新增加的功能需求对直接关联的功能组件的影响，这是容易考虑到的。

（2）新增加的功能需求依赖哪些其他的功能需求。--dependency

（3）新增加的功能需求对哪些非直接关联的组件有影响？--interaction

4.3架构是包含各种非技术因素的权衡

很多技术人员认为，架构是纯技术性的问题。然后，在一个组织内，除了技术性约束之外，还有很多因素制约着架构影响的方案选择，有时候，这些因素才是真正决定架构决策的主要因素：

（1）项目时间：在时间有限的情况下，有时候，就只能在架构上做出一定程度的牺牲。

（2）功能范围：在功能范围的情况下，有时候，就只能在架构上做出一定程度的牺牲。

（3）项目费用：在费用限定的情况下，有时候，就只能在架构上做出一定程度的牺牲。

（4）质量要求：有时候，项目管理对bugs的数量有严格的限制，因架构改进引入的风险就会被抑制。

（5）客户业务价值：当多种功能发生冲突时，架构师会选择对客户更有价值的功能需要和架构改进上。

（6）非功能性需求（前面已经探讨过）

五、非技术新思维

5.1 技术是架构师的立足之本

虽然，本章节探讨的是非技术性思维，但必须要先声明的是：技术才是架构师立足之本；是架构师的核心竞争力。

当然，一个架构师，只有技术核心，是远远不够的。

一个人，只有大脑，没有身体的其他方面，只能称为大脑，无法称为人。

一台汽车，只要发动机，没有其他部分，只能称为是发动机，不能称为汽车。

一个架构师，没有技术，没有非技术性思维，只能称为技术员，不能称为架构师。

5.2沟通协调的思维

在一个小公司内，架构师既充当产品经理、业务员、也充当需求分析工程师、软件设计师、甚至编码的程序员和测试工程师，想怎么做，一个人说得说，自己做就可以了。

在一个大型的组织内，一个软件代码或架构的改动，哪怕是一行代码的改动，涉及到角色和人员非常多，包括产品经理以及相关的产品管理人员、项目经理以及相关的项目管理人员、多个职能部门经理以及开发人员，以及其他的架构师，每个人，在流程的驱动下，像一个大机器中的齿轮一样在转动。架构师无法强行推动架构的演进，也无法自己直接完成代码的编写。因此，架构师要推动架构的改动是非常困难的，如果架构的改进不是来自于对客户有显性的价值，这个难度更大。

架构师要推动架构的改进，必须发挥自己与外界的各种人员的沟通能力，并考虑如下因素：

（1）语言表达能力

（2）沟通方式

（3）不同的文化

（4）人的个性

5.3领导力和影响力思维

架构的改进并不是项目管理者、开发职能部门、产品经理的责任 ，他们也没有这个动力。

在加上架构师没有职务上的权力，架构师要想推动架构上的进展，必须发挥自己的领导力和影响力。

（1）长期建立自己技术的影响力

（2）长期建立自己被别人信任的能力

（3）与同行保持长期的良好的合作关系

5.4 创建和变革力

架构是一个系统的框架，它关系到一个系统长期的生命力。

且架构推动的难度比做一个功能的难度要大很多。

因此，架构师必须要有强烈的创新和变革意识，实时跟踪行业架构的最新动态。

（1）要勇于承担一定的风险，有勇气推动架构的演进。

（2）并且，要把风险控制在可控的范围内，避免架构的改进造成项目和产品持续发布的重大风险，导致客户满意度的降低、避免造成对客户的损失 。

5.5 持续学习

整个行业技术都在飞速的发展，而架构是整个目标系统的骨架，关系到整个目标系统的长期生命力。而作为构建架构的架构师们，如果不持续地学习，就会落后，而落后的影响，不仅仅是个人，也影响整个目标系统，影响一群人，甚至影响整个公司。

目标系统架构的生命力和先进性，不是项目管理人员、职能部门的管理人员或产品经理有能力来预见和实施的，也不是技术人员和技术专家的能力所能及的地方。只有架构师才能承担这样的职责，只有架构师有能力推动目标系统架构的持续演进和保持旺盛的生命力。架构师需要持续的学习来提升自己的能力：

（1）持续学习、提升自己、修炼自己（20%的工作时间）

（2）通过公司的培训系统提升自己的能力

（3）通过各种技术交流活动提升自己的能力

（4）对世界保持好奇心，好奇心是一个人持续学习的前提，好奇心是我们探索新生事物的动力。承担重要使命的架构师们，需要抱有一颗好奇心，承认自己的对新生事物的无知，持续的学习，持续的改进自己的知识架构，同时改进目标系统的架构，与不同的人合作，构建强大生命力的目标系统的架构。

5.6 坚守与拓展

技术才是架构师立足之本；是架构师的核心竞争力。

有时候，为了长期的价值，在项目执行中，当多方力量发生冲突时，架构师需要坚守、坚持正确的技术判断，做好自己的本职工作，尽到自己的本职的职能，然后不断的扩展自己的边界。

立足本职职责-》扩展团队关心问题-》扩展到部门关心问题-》扩展公司关心问题-》扩展到行业关心问题-》扩展到客户关心问题。

拓展自己的能力边界、拓展自己的工作边界、拓展自己的职责边界、拓展自己的影响力边界、同时也拓展的自己的薪资边界，你的边界越宽，你能支配的资源越多，不确定性越多，可能性越多，实施自己架构的可能性就越大。

5.7持续改进自己

架构师必须坚持阶段性（一周、一月、一季度、一年）的复盘、总结、反思。

在复盘、总结、反思中使得自己不断的精进，使得自己保持旺盛、顽强的生命力。

在挫折、失败中成长与前行，在挫折、失败中推动目标系统架构的改进与演进 。