关键词：
目录
前言：架构师的位置
本文探讨，作为贯穿产品开发的多个环节的产品或软件架构师，通常需要哪些架构思维。
架构是贯穿始终：客户-》需求-》规范-》设计-》开发（硬件、软件、测试）
一、客户业务与需求分析环节
1.1 客户痛点、问题 VS 软件设计本身
架构不仅仅是没有生命的目标软件/硬件系统，它也承载着公司的长期的价值，承载这为客户解决问题的职责。因此，在分析一个新的需求对现有系统的影响时，需要清晰的知道，该需求到底解决什么样的客户的痛点和问题。明白客户的痛点，明白后续是否有相关的持续性的新的需求，明白当前的架构方案是否能够能够解决客户的痛点和问题，才能更有针对性地在众多架构方案中进行权衡和选择。
架构不是单纯脱离用户痛点的软件或目标系统的架构设计问题，不单纯的是技术问题。
1.2 客户价值 VS 架构设计
无论是设计架构，还是架构设计时内部方案的争论和选择，还是不同优先级功能的实现的顺序，或者判断需要是否是伪需求、真正的需求，一个最重要的决策依据之一就是对客户价值的大小。
1.3 需求收集与需求分析
参考：
https://blog.csdn.net/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 持续改进自己
架构师必须坚持阶段性（一周、一月、一季度、一年）的复盘、总结、反思。
在复盘、总结、反思中使得自己不断的精进，使得自己保持旺盛、顽强的生命力。
在挫折、失败中成长与前行，在挫折、失败中推动目标系统架构的改进与演进 。
java架构师之路
Java架构师之路：从Java码农到年薪八十万的架构师对于工作多年的程序员而言，日后的职业发展无非是继续专精技术、转型管理和晋升架构师三种选择。架构师在一家公司有多重要、优秀架构师需要具备怎样的素质以及架构师的... 查看详情
云架构师的进阶之路
原文:云架构师的进阶之路一、架构的三个维度和六个层面1.1、三大架构在互联网时代，要做好一个合格的云架构师，需要熟悉三大架构。第一个是IT架构，其实就是计算，网络，存储。这是云架构师的基本功，也是最传统的云架... 查看详情
java架构师之路：从java码农到年薪八十万的架构师，最牛java架构师进阶路线
从Java码农到年薪八十万的架构师，资深架构师大牛给予Java技术提升学习路线建议，如何成为一名资深Java架构师？ 对于工作多年的程序员而言，日后的职业发展无非是继续专精技术、转型管理和晋升架构师三种选择。架构师... 查看详情
[架构之路-4]：架构师-架构师的四大架构价值等级与架构师全面成长之路
目录第1章架构师的四大架构价值等级第一等级L1:一知半解型（入门架构师）--辅助价值第二等级L2:拆解还原型（初级架构师）--表层价值、协调价值第三等级L3:革新型（中级架构师）--核心价值、优化价值... 查看详情
[架构之路-90]：《软件架构设计：程序员向架构师转型必备》-1-总结
...的瓶颈，即如何从普通开发人员转型成高层次的系统架构师和技术管理人员。想成为一名架构师，应当具备全面的知识体系?需要进行系统的学习和实践？很多开发人员有往架构师转型的强烈意愿，但苦于找不到好... 查看详情
构设计杂谈004——架构师
什么是架构设师架构师是：负责系统架构设计的人、团队或组织架构师主要干什么●架构师是技术领导，领导并负责架构设计，负责做决策●架构师可以是团队或组织，这个时候通常会有首席架构师●架构师必须掌握足够的技术... 查看详情
[架构之路-90]：《软件架构设计：程序员向架构师转型必备》-0-总结
...的瓶颈，即如何从普通开发人员转型成高层次的系统架构师和技术管理人员。想成为一名架构师，应当具备全面的知识体系?需要进行系统的学习和实践？很多开发人员有往架构师转型的强烈意愿，但苦于找不到好... 查看详情
架构设计杂谈004——架构师
什么是架构设师 架构师是：负责系统架构设计的人、团队或组织 架构师主要干什么 ●架构师是技术领导，领导并负责架构设计，负责做决策 ●架构师可以是团队或组织，这个时候... 查看详情
架构师之路系列文章
目录文章目录目录企业数字化转型架构师之路业务架构应用架构API经济数据库设计设计模式系统架构分布式系统RPC远程调用分布式消息队列分布式任务队列微服务架构ServiceComb部署架构高可靠、高可用、高并发、高性能、高可扩... 查看详情
[架构之路-2]：架构师-八种不同领域的架构，什么是架构与架构师？
目录第1章什么是架构？1.1架构的原初定义-建筑物架构1.2公司的组织架构1.2公司的股权架构1.3 项目的组织架构1.4 持续5GDevOps开发架构1.5 CPU的体系架构1.6 计算机系统的硬件体系架构1.7嵌入式系统的体系架构1.8 大数据平台... 查看详情
优秀软件架构师成长之路(代码片段)
成为一名优秀架构师，是很多程序员努力的方向。相关的讨论也从没停过，除了大家说烂了的那些架构师的特质和需要具备的技能外，还有很多是我们可以在工作和学习过程中重点培养和关注的能力。1.在软件工程师... 查看详情
架构师成长之路--什么是架构师(目标)
...想每个人都有自己对这三个问题的认知。如果我们要成为架构师，我们自己要面临的三大问题：找准自己定位：我是谁？在哪里？怎样做好架构师：我要做什么？如何搭建架构师知识体系：我该怎么做？这里面就是做事方法论：... 查看详情
架构师的责任（架构师的成长之路---第3篇）
作为架构师，首先要明确架构师的责任，要不然会再多的技术也是枉然。 简单的说，带领方向和难点攻克。 带领方向是指架构师应不断地多读书，多学习，跟随最新技术，不断地升华自己，并不停的为... 查看详情
架构师成长之路--如何成为架构师（方法）
...想每个人都有自己对这三个问题的认知。如果我们要成为架构师，我们自己要面临的三大问题：找准自己定位：我是谁？在哪里？怎样做好架构师：我要做什么？如何搭建架构师知识体系：我该怎么做？这里面就是做事方法论：... 查看详情
架构师成长之路--架构师必备技能（目标）
...想每个人都有自己对这三个问题的认知。如果我们要成为架构师，我们自己要面临的三大问题：找准自己定位：我是谁？在哪里？怎样做好架构师：我要做什么？如何搭建架构师知识体系：我该怎么做？这里面就是做事方法论：... 查看详情
如何成为一名架构师,架构师成长之路（转）
...自http://blog.csdn.net/fei33423/article/details/61934514如何成为一名架构师,架构师成长之路原创 2017年03月13日22:50:343116大量阅读别人的系统实现文章(架构=模块图+模块流程图(启动和主流程,可以用拟物tag)或者模块时序图)动态+静态.对象... 查看详情
架构师成长之路--什么是架构师(代码片段)
...想每个人都有自己对这三个问题的认知。如果我们要成为架构师，我们自己要面临的三大问题：找准自己定位：我是谁？在哪里？怎样做好架构师：我要做什么？如何搭建架构师知识体系：我该怎么做？这里面就是做事方法论：... 查看详情
架构师之路
...。。。。。。闲的无聊，看起了pdf,在网上找的，好多的架构师都会看的pdf,很基础，不过也很实用，不想写代码的时候就看看，就当放松了，这玩意，还是有点用的，万一以后真走架构师这条路呢，你说是吧 查看详情