重新认识架构—不只是软件设计

前言

什么是架构？

通常情况下，人们对架构的认知仅限于在软件工程中的定义：架构主要指软件系统的结构设计，比如常见的SOLID准则、DDD架构。一个良好的软件架构可以帮助团队更有效地进行软件开发，降低维护成本，提高系统的可扩展性和可维护性。这里的架构定义有更多元化的理解：架构不仅是对软件开发设计和流程规范的定义，也包含了参与架构设计的人员、以及项目过程中和架构有关的活动，都可以称为架构。

从广义角度来理解架构，意味着更全面的思考和新的融合。

按这张图理解，架构是指架构师以商业价值为导向、以用户为核心，在所处的商业、文化、技术环境中，利用有限的资源和成本，设计架构方案、组织或参与研发活动，从而达到既定目标的一项复杂且持续的活动。

架构师面对实际问题，在复杂的环境中如何做出正确的选择，如何确保架构活动顺利进行，保障项目落地，可以从目标、资源、行为、趋势这四个层面来梳理。

架构

目标

明确目标：在开始新事物时，可能需要面对各种各样的选择和挑战。在这种情况下，明确具体的目标并非易事。

• 可实现：目标需要具有可实现性，过高或过低的目标都可能导致挫败感和疲惫。要在充分评估自己能力、资源和环境的基础上，设定合理的目标。
• 具体、明确：目标应该具体、明确，易于衡量，以便对自己的进展进行有效跟踪和调整。将目标细化为若干小目标，有助于更好地管理和实现目标。
• 有弹性：目标制定过程需要有一定弹性，能够应对不确定性和变化。当遇到挫折或不可预测的因素时，可以适时调整目标，以保持积极的心态和动力。
• 持续关注和调整：目标制定并非一劳永逸，需要根据实际情况进行持续关注和调整。通过定期评估进展、学习经验教训，可以保持目标与现实的一致性，并提高实现目标的可能性。

上面4条是指导原则，实际情况更为复杂，比如技术人员通常以技术驱动去探索目标，但是它不一定适合商业活动。拿MQ的对比Kafka和Pulsar，后者相较更新、更快，技术极客们通常会毫不犹豫的选择探索后者并将它应用到实际工作中。从普适性很强的成熟方案切换到新颖高性能的方案，除了考虑切换的成本外，还要考虑切换后带来的收益，以及团队成员掌握Pulsar的成本。从发展的角度上看，除非Kafka有致命的缺陷且不被修复，那么随着时间推移Kafka可以一直演进迭代也会变得更出色。所以单纯从短期的技术先进性上看并不可取，也要关注技术的生态，这也就是常说的对技术的生态有一定的前瞻性。

结合自身的情况，在线业务为什么要切GBF，是要基于领域建设提高复用度，达到降本增效。架构活动的所有目标都是为了降本增效。切框架短期内会使业务迭代成本变高，中期途中就会陷入一个悖论：当上下游环境协调成本高时，如果从自身妥协方案，会使得US短中期成本增高，且如果没有改进的情况下无论是从US自身还是纵观全局看长期收益降低，但是又不能影响进度，或者说可不可以等时机成熟再进行，我感受到过不小的压力。

这些原则说起来比较简单：确保长期目标不动摇，临时方案做取舍。做下来就会有犯难的时候：如果临时方案做得多了容易形成包袱，影响长期收益，最终会使定制的目标打折扣。阶段目标保障和长期收益并不是完全对立的，实际工作中也会存在需要做取舍的情况，当阶段目标和长期收益出现矛盾时，需要架构人员争取资源或做好取舍。纵使做完决定选择阶段目标临时放弃长期收益时，这也只是一个短期的决定，并不能代表将来，也就是说在时机成熟的时候（例如上下游在自身的演进中做了理想态的改造），那么作为部门自身也需要时刻关注并及时跟进。

谈到取舍，深有感触：作为决策者或有决策权限的角色，在决策范围内需要做好取舍。如果当事人不做取舍，那么就只能让别人来替他做取舍。执行者大都选择丢掉休息选择加班、或者跳过总结归纳改进的环节，长此以往这种决策低效且不科学。决策人员需要做好清晰的取舍，避免无限度的索求（全都要），因为很有可能无法被完全满足，导致取舍权分散给执行者。取舍权分散给执行者有什么不妥？个人认为取舍的决策权下放分散给执行者存在问题是：执行者接触到的信息有限、经验不足易导致决策过于片面，不容易有全局观，容易做出错误的决策，项目风险加大。

资源

资源，是有限的。

作为一个架构师，要在有限的资源下最大化商业价值。如何让技术人员站在商业的角度来理解这句话？

这里描述是一项架构师参与的商业活动，既然是商业活动那么必定要有商业价值。大部分技术人员并不关注商业的价值逻辑，通常只关注技术方案是否优越，容易忽略技术方案落地过程中客观存在的资源、环境以及协作等因素。如何让技术人员理解商业价值，可以从代码和设计的三个作用来阐述：

技术人员主要通过上面这三个途径为公司赚钱。员工的工资和各种收入，来自于公司的商业收入和融资。

结合自身的理解，从公司到组织到个人，都有属于自身层面的商业逻辑，科学合理可持续发展的商业逻辑也是支撑公司、组织和个人发展的基础，脱离了合理商业逻辑的事物，短期内看并不一定会有明显的结果，长期看会衍生出各种各样的问题，问题的原因不仅仅归咎于问题本身及产生的过程，更深层次上看是整个的商业逻辑是否合理、可持续。

那么作为个人来讲，如何做到利用手中的资源最大化商业价值，对公司、组织、个人都能受益？

a.理解你所在的企业或团队的商业模式

b.理解你在自己所处环境中创造的商业价值

c.保障架构活动的长期商业价值

d.在架构规划中寻找扩大收入的机会

e.在架构规划中寻找减少成本的机会

前两点商业模式和商业价值，每个人的认知不一样，通俗讲就是这个公司、这项业务是不是核心、有没有前景。对于公司业务前景经常会有不同的声音，常见于新兴业务，属于仁者见仁智者见智，不过也从侧面了印证了最近比较流行的一句话：人们通常赚不到认知以外的财富。行业、企业的发展作为自然人很难影响和撼动，历史和趋势中个人只有选择的空间。

那么第三条对我们来讲说是一个长期面对的事情：当做出选择后，如何在工作中确保自己和团队都能够有持续的、足量的、正向的价值和收益。和经济学一样，技术的边际效益也是递减的，因为技术一直在发展，个人的价值和优势主要体现在增量价值上，也就是说个人通过工作创造的价值，是在平均价值之上，才能说这个人具有一定的优势。然而这些优势并不是一成不变的，因为开源的解决方案也在源源不断的提升，越来越多的人掌握，那么个人的增量价值响应的就会减少，甚至不存在。这也就需要个人不断的学习、提升自己来持续提高竞争力。

文中提到的资源和经济学中的生产资料、生产成本类似，商业价值依赖资源，商业公司和组织对员工的期望是最小成本生产最大商业价值，这些无论是从短期还是长期来看都要关注，目标过于抽象时为了避免不同的人理解不一致，可以根据每个人的环境、岗位具象专属的目标，最好是根据时间粒度分散成阶段性的目标，也就是说于员工个人而言，更多的是对阶段性精确目标的最大化投入来取得收益。目标的定制依据这里已经介绍完了。

当目标确认完后，就要奔着目标，发挥自身的最大价值。也就是两个方面：发掘机会和减少成本。

机会需要发现，无论是来自于科学的数理统计、分析挖掘还是日常中的一些小Tips，都是在发掘机会。这一点我在业务侧会接触到比较多的机会，版本迭代中通常会和产品聊本次更新的动机是什么，收益在哪，作为C端的产品逻辑，除了这些收益，我们还要从用户体验出发，这些变化会给用户带来什么样的方便，以及我们会不会有额外的代价和成本。最常见的例子就是如何在有限的屏效中将活动信息、分享裂变、推荐合理的展示给用户、引导用户，以及每个模块能否让大部分用户心领神会设计的初衷，交互能否适应人群的习惯等等。但目前我还没有精力投入到指标的研究和跟踪中去分析验证，只是有兴趣，后面有机会需留意这块。

除了业务的机会，也有技术的机会。比如发现并抓住开发中遇到的痛点。很多同学在开发或推进过程中会遇到各种各样的痛点，非常多的情况就是考虑到时间、精力有限等因素后为了保障任务按期完成，选择性忽略这个痛点，当任务完成后又投入到其他事项中。这些痛点虽然造成了体感上的影响或者影响了一点点效率，但并没有被抓住解决掉，因为单论这一个问题不会被放大，也不影响KPI或OKR，痛点存在还会继续影响其他将要遇到的“幸运同学”，当忽略的次数变得多起来，量变易引发质变：框架不够好用。如何应对这种现象，个人觉得可以设计一种机制，强化痛点发现、上报、跟进、解决、反馈提升，也会从侧面提醒项目Owner除了关注任务的进度，也要关注任务完成的质量。

成本包括人力成本、时间成本、机会成本，也包括技术迁移的成本，作为架构师，需要从各类复杂成本中去衡量，按时间轴推演，保障中长期的收益。

行为

技术同学每天沉浸在逻辑中，容易陷入一个思维区域：世界由逻辑和数字主宰。合理的结构中商业活动需要和技术解耦，因为技术自身不会给企业和组织带来价值，而是大多数企业和组织作为一个平台，使用技术盈利。技术落地的过程鲜有单兵作战，大都是团队协作、组织协同。上面这句话推导的逻辑是：商业价值 --> 组织活动 --> 人在组织 --> 活动主体是人 --\> 遵循人性。

提到人性，就会提马斯洛需求层次模型。尽管每个人所处的环境、接触的信息、个人的观念各有不同，需求层次模型也会有千差万别，但是从公司、组织和员工的角度来看，这一模型相对稳定清晰。动机的抢占模型也可以理解为需求的压制模型如下图：

有时候任务推进会感觉到超乎寻常的艰难，合适的沟通方式表面上可以避免一些矛盾，本质上是作为被推进方，或者当事人的资源不足（例如需求排不开），通常推进方并不了解合作方的需求优先级或依赖层次，和他要配合做这件事的成本，有些事只是在推进放看来比较简单，就会有一个求证的过程，这个过程有没有必要我自己也不太清楚。当这些需求得不到满足的情况下，合作方会自动诱发动机，主导的意识和行为通常让人难以理解，遇到这种事情的解决方式是分析他的需求优先级，是否存在动机压制，以及能否协调调整优先级，改变动机压制的重要性和次序。

在最近的工作中经常遇到的一个现象是：方案可行，但是协同方没资源。因为组织的资源不单单为我所在的一个项目提供，而是要支撑当下阶段的各个目标。如何在多样目标和复杂的组织资源协调中找到最优解，是非常困难的一件事情。作为参与方，尽量去解，临时做兜底。一次次兜底就是一个个小包袱，还要不忘提醒自己包袱不要太多。

动机优先级中每个人的认知和安排是不一样的，有一个可以参照的依据：设计思维的精髓在于深度理解和尊重用户，对技术人员来讲到底是被动地迭代方案，执着于填补设计的漏洞；还是从共情用户的角度出发，脱离现有技术方案的束缚。同时忘记现有的技术方案的优势， 把关注点放在深度理解用户、解决用户的痛点上，进而拓展技术设计空间，找到更完美的技术路径。答案不言自明。

上面提到的这些只是理论，也就是我们常说的理想态，能否很好的落地就变得复杂起来，因为单纯从理论上来看这些对每个人的要求非常高，无论是职业素养还是主观能动性上，做到的都是少数。同时伴随着边际效益递减、35岁危机、996等热门社会现象，底层逻辑是人们没有安全感导致行为偏重自保，这些能不能带来商业价值是值得分析和审视的。这里提到的安全感是指能够影响人做出科学决策的环境压力，并不和居安思危中的危机感对立。

结合自己在技改项目的过程中，有同学反馈担心会失去手里的业务和之前负责的一些方向，也有同学有需求压制导致参与度不高，有的会在交谈中表达，有些虽然不明说，但种种迹象表明团队协作或工作内容没有安全感。我给出的反馈和建议是：当前目标是降本增效，业务的前景很宽广，当下还在高速发展，完全没理由缩编，但是这并不意味着可以无限度的扩张。我们需要在思考如何在不扩编的情况下更高效的做更多的事情，花更短的时间，支撑更多的行业。消除危机感的同时，还需引导良好的设计思维，刚才提到的深度理解和尊重用户，很多同学是需要这种自我满足感的，但是当节奏变得紧张、感受到环境不宽松时，这些也就随之被抛诸脑后转而去满足更原始和低层次的动机，也就是面对源源不断的需求和迭代，将任务填满日程表，从而持续不断的投入到紧张的迭代中。

顺势—天时、地利、人和

如何看清行业的周期、把握新技术。

俗话讲，你永远叫不醒一个装睡的人。是这个人不愿意醒吗？我看未必。而是人性的一些弱点导致这个人不愿意接受现实、害怕变化、对过往的路径严重依赖、或者思维僵化，导致他不想醒。自我麻痹源自处于风险或者压力下的自我保护机制：当个体面临压力、困境或威胁时，为了保护自己的心理健康和自尊，会出现一些消极的应对策略。这些策略通常表现为对现实的否认、回避或者对问题的轻视，从而使个体在心理上暂时免受困境带来的痛苦。然而，长期的自我麻痹可能导致问题恶化，无法解决现实生活中的问题，不能全力探寻新的出路，甚至用勤奋弥补内心的不安，容易陷入于目标无用的布朗运动——目标不清晰、动作不连续。

畏惧变化：当人感受到压力时，对变化感知异常慎重。在繁忙的事务中如何保持专注，历史的包袱能不能放下，如何卸载，短时间内卸载不掉那如何长线对待，如何同时支撑好业务，当同时面临这些问题时，每种取舍都有它自身的底层逻辑，当我们面向未来去思考这些问题时，就知道当下该如何选择。

对于路径依赖可以很好的用一句话解释：成功可以借鉴，但不会复刻。技术的生命周期，可以从技术社区中获取，技术的周期源于大多数人对该技术的定位。如果工程师们对这项技术不再有需求，那么这项技术的命运将会毫不犹豫的被抛弃。

对技术周期的了解作为架构师的基本功，这里不再作分析。当一个架构师的技术掌握优秀时，又要避免一个误区：拿着锤子看什么都是钉子。技术是实现商业价值的一个手段，并不是唯一路径。在这个前提下技术不能拖累商业价值的最大化。所以说架构师面对公司、组织、以及工作开展的实际情况，要选择合适的技术方案。

如何定义合适的技术方案？先看三个不同的研发活动的层次：

架构师在这三个层次的研发活动中侧重点是不一样的，技术驱动需要保证技术的先进性、产品驱动保障客户的体验、业务驱动保障业务指标的全盘增长。

影响技术体系建设的外部因素还有行业发展、企业内部指标的压力、组织结构的影响等等，需要架构师获取全面的信息，通盘抓重点，找到保障商业价值最大化的关键因素和节点。

总结

最近在学习郭东白的架构课，本篇文章主要是结合自身实际的经历阐述架构师定位、架构活动如何保障企业、组织实现商业价值，以及从员工层面的执行、管理角度分析各层次的定位、方向，通过这些思考总结沉淀，帮助我们在工作中更好地做技术落地和业务支撑。