企业架构设计原则之因素均衡性

条条大道通罗马。世上万千事，很少而且只有唯一的解法。

回到架构设计的专业领域，面对一个具体的产品或问题，同样也会存在很多可实现的方案，但是各个方案之间大部分情况下都会各有优劣利弊，又该如何抉择呢？

首先，我们简单地认识下影响架构设计的常见业务性因素。

一、时间周期

时间是一个老朋友了，很多时候都离不开他的身影。我们做架构设计的时候，必须时刻记住他。

激烈的商业社会下，产品的生命周期和生产方式也顺应潮流发生了巨大的变化。过去一款产品的生命周期可以长达数十年，而如今，只要一款新产品面世并获得市场的好评，其他竞争者便会纷至沓来，争相入局分一杯羹。加上当前大部分产品主要停留在商业模式创新，尤其是国内更是如此，因此，竞争者之间并不存在高不可逾越的藩篱保护，为了获得客户的青睐，大家彼此模仿之余，都会进行少量的差异化设计，以便能够突出重围。这样你追我赶的场面，对于广大消费者而言往往意味着更多的产品花样、更心仪的产品价格和更贴心的服务体验；对于行业来讲，以一定程度上促进了行业的快速发展，百花齐放百家争鸣；但是，对于产品的供应商而言，却不得不面临产品生命周期被缩短的境地。因此，产品的生产方式也不得不进行改造。原本长周期、功能完善而开发周期更长的方式，逐渐被小步快跑、快速试错的开发方式所取代。

因此，架构设计必须考虑设计方案的时间周期，以匹配产品运营模式的需求。只有在产品可以接受的时间范围内能够顺利实现的架构方案，才是有生命力的方案。

二、落地成本

除了时间这位老朋友，成本同样也是十分熟悉的老伙计了。不同的企业所能负担的产品研发成本迥异，同一企业不同产品因为承担的使命和特征不同，所能接受的成本也不尽相同。因此，在架构设计的时候，对成本的考量应该是不可跳过的话题。

在 IT 行业，常见的成本包括人力成本、资源采购成本以及运维实施成本。

（1）人力成本。主要是指开发一款产品所需要投入的全部人力资源的成本。一个成熟且分工明确的产品研发团队，一般包括产品经理、架构师、开发工程师、测试工程师和运维工程师等岗位，不同岗位投入的人员数量和时间长短不同。而且，对于 IT 行业，广泛流传着“三分开发七分运维”的经验之谈。产品全生命周期所投入的人力资源成本之和，即该产品的人力成本。对于倡导商业价值为导向的企业，人力成本的投入是十分关键的决策指标。因此，作为架构设计人员，必须具备基础的商业决策素养。

（2）资源采购成本。产品的成型，除了需要投入人力成本，往往还需要相关资源的支撑。对于软件产品，常见的资源包括服务器、磁盘、网络设备等硬件，也包括如数据库管理系统、网络服务器等软件系统。这些软硬件大部分也都是需要向专业的供应商进行采购，自然也会产生实实在在的成本。

（3）运维实施成本。对于 IT 行业日益盛行的 SaaS 产品，自然不用过多考虑实施的成本。但是对于需要在客户本地部署的产品，实施成本的高与低不仅仅决定产品的价格和竞争优势，还影响产品的客户体验，试想想，如果客户采购一套产品，实施需要一个星期，每次出现问题都需要好几天才能定位和解决，你是客户你愿意采购吗？同样的，对于产品供应商的经营管理层，这样的成本你愿意承担吗？假设企业业绩腾飞，运维实施成本将变得高不可攀，最终制约企业的发展。

三、团队技能

再优秀的架构设计方案也离不开技术团队的理解和开发落地，因此团队的因素不得不考虑。设想一下，如果采用的架构方案，团队当中无人熟悉，无形之中为架构的高保真落地和时间周期内的实现埋下了重大的不可控风险。首先，时间方面来看，团队不熟悉，必然需要花费更多的时间去熟悉和摸索，一边学习一边使用，因为缺乏经验，难免会落入很多的技术陷阱，从而花费大量的时间去排查；其次，因为缺乏相关的技术储备，难免会出现理解上不深刻，勉强只能大概还原架构方案，而如果寄希望于在开发过程中对架构方案进行完善和优化，则大概率会落空。

当然这里面不排除一种情况，即公司愿意投入更多的时间成本和风险担当，尝试让团队去涉足新的技术领域，从而扩张团队的技能边界，提升团队的技能储备，为将来的发展提前布局，这无疑又是新的发展愿景下新的决策因素了。

四、团队成熟度

团队成熟度对架构方案的影响可以分为两个层面。其一是团队整体的专业技能水平，其二是团队之间的协作是否经过磨合后达到一种顺畅互相信任的和谐程度。

（1）团队综合专业水平

团队综合专业水平指团队内各个成员的专业素养平均水平。一般与团队成员的平均从业年限、过往经历挑战性和成员自主性有较强的依赖关系。很显然，对于专业类工作，从业时间越长，工具的运用更加熟练，原理的理解也更加深刻，所遇到的问题类型也更加多样，从而促进专业素养的晋级。而过往经验的挑战性，往往决定了遇到问题的数量、复杂度。问题是一把双刃剑，一方面会给我们的工作增加困扰和压力，但另一方面则像磨刀石，帮助我们磨砺锋刃。遇到的问题越多，见识也就越广阔，知识半径自然会被扩大。而问题的复杂度，则会督促我们加深对专业的深入理解，从简单的应用，深入到复杂的应用，再进一步达到对原理的掌握，最终融会贯通，举一反三的高阶境界。成员的自主性则是一种难能可贵的内驱力，即使平常遇到的工作平淡无奇，只要时刻心怀激情，保持强烈的内在驱动力，也可以在简单的事情上不断思考，从而看到别人所看不到的深刻本质。其次，拥有自驱力的人，会自发地寻找学习的途径，自己制定清晰的成长轨迹，通过自己背后孜孜不倦地学习，最终可以实现超越同龄人甚至胜过从业时间更久的前辈的专业修为。更重要的是，拥有自驱力的人，仿佛拥有破解疑难杂症的万能钥匙，任何问题在他们的执着下，最终都会消失。这样的成员，是团队的财富。

（2）团队协作水平

团队之间有没有明确的、大家都深度共识的标准、流程和制度？大家是否严格按照这些共识处理日常的工作？团队之间的问题，是否经常需要组会进行就事论事的讨论？

上面三个问题在不同的团队中，会有不同的答案。如果你的团队缺乏大家普遍认同的标准、流程和制度，那么显然团队协作水平是有待提升的。当然，如果有但是未能坚决彻底地执行下去，也是光有其表，远远还够。最后如果一个团队发生的问题，大部分都需要一事一议，那么显然制定的流程和规范是不完善的，需要进行补充。立项状态下，团队成员之间可以自组织自管理，凡事有章可依，依流程办事，每个人都很明确自己面临的事情该如何去处理，不需要去请示。如此团队，才能高效运转。

（3）团队信任程度

如果说团队综合专业素养和协作水平算是显性可观察可制衡，那么团队之间的信任程度则显得难以捉摸得多。首先，信任是一项心理感受，每个人的体验不一样，很难量化；其次，信任的建立不是光靠流程制度就可以完成的，更多的是需要长时间并肩作战积累的深厚情谊；最后，信任非常重要。在拥有良好的信任环境下工作，一方面可以极大地减少制度流程所带来的管理程度和效率损耗，另一方面因为信任可以携手征服很多的难题，因为大家摒弃了芥蒂，齐心协力，很多看似不可逾越的鸿沟也将变得平坦。

为什么在设计架构方案的时候要考虑团队成熟度呢？试想想如果你设计的架构方案非常复杂，引入的技术都是偏向前沿和高深，而执行的技术团队平均从业经历不过 2—3 年，大部分成员的工作还需要其他更资深同事的指导，你指望这样专业素养的团队能够顺利地落地你的架构设计吗？无异于天方夜谭吧。其次，如果设计的技术方案设计很多子系统，各个子系统之间有非常频繁的交互，需要负责开发的团队之间紧密合作，共同制定相关的实施规范和标准。而不幸的是，后面负责开发的团队之间剑拔弩张，彼此严重对立，哪怕一方说得在理，另一方也借故阻拦，这样的协作氛围无疑无法承受非常紧密协作型的任务，更适合彼此边界切割得很清晰，交互尽可能少，职责尽可能地明确，总之，尽可能减少他们之间的沟通要求或许更容易保障方案的最大限度原汁原味的落地。

五、业务价值

架构设计时需要考虑产品的业务价值，我想这一项无需过多阐述吧。毕竟业务价值是商业活动的起点，同时也是终点。如果我们面对的是一款可以增加营收上亿的优质产品，那么架构设计自然要考虑周详，确保用户体验的连贯、顺滑，甚至是惊喜。反之，如果我们只是为一款内部工具型产品进行架构设计，而且还是低频工作，架构设计还按照上述产品同样的规格来对待，无需多说，稍微明智的人一看就知道不合适，毕竟简单的算账本事大家还是具备的。

那么什么是业务价值呢？

我们按照对内对外二分法来拆解，业务价值对外表现为帮助客户创造的价值，对内体现为带给企业的商业收益。而这两者本身具备内在关联性。因为企业收益往往来自客户，如果产品无法给客户创造价值，客户自然不会买单，企业也就不会有营收。因此，以客户为中心，服务好客户，站在客户的立场，甚至站在客户所属行业领导者和先行者的立场，帮助客户梳理方案，助力客户业绩增长，也就是帮助企业自身的业绩增长。

六、业务特征

架构设计的核心目标是为了支撑业务发展的需求。因此，不同类型业务和处于不同阶段的业务对架构设计的诉求也是不可相提并论的。

（1）业务类型

结合本文主要讨论的内容，我们限定此处所讲的业务类型主要是业务的稳定性要求。很显然，对于金融行业业务系统和面向企业内部事务记录型的业务系统，对稳定性的要求可能相差迥异。因此，在为这两类业务系统进行架构设计的时候，所采用的设计方案理论上也是各有侧重。对于合格的架构师，深入了解业务类型，挖掘出内在的核心诉求，往往决定了架构设计的成功与否。

（2）发展阶段

任何事物都有生命周期，硬件产品、IT 系统也自然不能例外。如果我们面对的业务是一项成熟型业务，且发展快速，经过时间的酝酿，目前运作流程已经比较清晰且流畅，那么，与之搭配的架构方案理当也是面面俱到、高度智能和自动化，同时会兼顾未来中长期业务发展水平并在容量上进行冗余。如果我们面对的业务是一项刚刚成立的探索型项目，没有明确的发展轨迹和运营计划，即使有大的发展方向也是存疑的有待市场的验证。那么，我们的架构设计方案就不能过于全面和超前，因为全面的方案所要求的建设周期会更长，并不适合这一类探索型业务所采用的短平快的试错性要求，其次过于超前的方案，也会导致系统的复杂度上升，对于运营的要求可能也会提高，未必恰当，更重要的是，这一类业务的存活时间本身就没有人说得清，再精良的设计也可能没有用武之地，在发挥作用之前可能业务因为无法破局而关闭，只留下架构设计者的阵阵唏嘘。

七、时间推移因素

时间是一位不速之客，不管你是喜欢还是不喜欢，他的作用时刻都在。时间对架构设计的最大影响，在于他会改变一些因素，导致原本重要的因素变得不重要，甚至消亡，而原本坐在偏远角度的因素可能变得无法忽视。

譬如在系统设计中，经常会遇到数据规模的问题。假设一个功能，架构设计的时候需要查询整张表的数据用于计算，因为业务刚刚起步，这样的实现方式似乎没有任何问题。可是这张表的数据，每天增长 1 万笔，一个月后他的数据量就可以超过 30 万条，半年后，可以轻轻松松越过 200 万的门槛。如果按照目前的设计，可以想象一个月之后，系统会越来越卡顿，半年之后，只要使用这个功能，估计系统就崩溃了。因此，面对这样的场景，在设计之初就需要考虑各个因素在一段时间后的变化，并提前考虑，避免因为忽略因素的变化性而导致方案过于短视而失去生命力。

当前，我们在考虑时间推移对因素的影响时，对于时间窗口大小需要跟业务特征像相匹配。越是成熟稳定型的业务，时间窗口可以考虑得更大，避免方案频繁变更而影响业务顺畅运行，以及增加变更的成本。而对于探索型业务，时间窗口则不宜过长，假设企业内部有规则表明，一项探索业务的最长验证周期是半年，超过半年还没有验证商业模式的可行性，则该业务将被无情地砍掉。那么架构设计所考虑的时间窗口也可以以半年为期。

八、技术成熟度

架构设计自然离不开对技术工艺的选择。

然而，不同技术出现的时间不同，被应用的次数和场景不同，加上自身的设计天赋，导致技术的成熟度自然也不同。因此，为不同的业务挑选不同成熟度的技术工艺，也是架构师该有的修为。

首先，对于架构师必须广泛的涉猎技术丛林，了解丛林中各式各样的技术，理清设计的优缺点和应用场景。尤其是对于每一项技术当前的成熟度、应用案例和应用深度需要掌握。

其次，需要了解当前业务可以容忍哪个级别成熟度的技术。一般新技术意味着新特性，而且大部分新特性都附带技术红利，假设业务可以容忍，或许可以从新技术红利中获益。同时，新技术也经常与不稳定挂钩，如果业务对稳定性的要求很高，显然不太般配。此外，团队对新技术的掌握程度也是一个值得关注的话题，毕竟能掌控的事情才是符合管理常识的。

介绍完上述各种因素之后，我们不难发现，各个因素之间有时候会存在互斥性。譬如时间周期很短的创新型项目，假设我们还希望引入若干团队技能之外的技术，而团队本身也是刚刚初建，显然这样的技术选型就不太合适。

因此，对于架构师，我们需要纵观全局，将业务需求梳理清楚，并将众多因素进行分级，优先满足高优先级的因素，在此基础之上，可以适当兼顾低优先级的因素。