企业架构设计原则之业务导向性

一、核心业务自主可控

（1）减少核心要素对外依赖，保障关键链路自主控制

任何系统在进行架构设计的时候，都需要对系统拟实现的功能和流程进行深刻的剖析，划分功能矩阵，并厘定功能的重要级别和其他特征，如数据一致性要求、时效性要求和安全系数要求。同时，对于核心功能的业务流程需要仔细梳理，分清楚主干流程还是分支流程。对于主干流程，必须保证开发和维护团队对他有充分的自主可控权。因此，在设计之初，需要避免主干流程过多依赖其他系统，因为其他系统的可靠性和稳定性我们无从保障，一旦出现问题，恢复时间也无法干预，过多依赖只会增加系统出现故障时的干着急的被动局面。

为了尽可能减少核心流程依赖其他系统，可以考虑自建或内联的方式替代。所谓自建，即将需要依赖的服务自己实现一遍，从而减少依赖。而内联侧重的是，将直接依赖对方的服务，改为将对方服务的代码或类库引入到系统自身之中，一起构建运行，从而减少远程依赖。

（2）降低依赖强度

如果在实际情况下，依赖是必不可少的，譬如被依赖的组件拥有很高的技术复杂度，暂不具备自建的技术积累，或者受限于版权等因素也无法做到内联，又该如何呢？

这种情况下，我们需要降低依赖程度。譬如原本强依赖转为弱依赖，原本实时依赖转为非实时依赖，从而降低对依赖方的力度。

譬如我们正在开发一款业务系统，其中依赖身份证 OCR 的功能，而 OCR 服务商的稳定性无从保障。为了提高系统的自主可靠性，一方面我们可以将 OCR 的功能进行降级，譬如 OCR 功能不可用的时候，主要流程还是可以继续，后续通过定时任务间隔性地进行重试，从而补齐确实的子流程。

（3）掌握主导权

任何时候都要尽可能保留选择性和控制性的权利。在企业经营过程中，出于风险可控和提高话语权的考虑，往往都会同时选择多家上游供应商，也会同时与多家下游经销商或渠道合作，从而避免被卡脖子，失去话语权而被挟持。

架构设计也不例外。对于自身无法掌控的内容，都需要有多重可选方案，同时可以低成本地快速切换，避免捆绑。另外，在方案设计上，尽可能避免需要对方相关操作，我方才能够顺畅进行的情况，相反，应该将这一类操作的控制权转移到我方。

还是以上述 OCR 功能为例，为了保证业务自主，我们需要同时对接两家以上的供应商，并且可以按照一定的规则进行业务的分配，一旦出现紧急情况，可以快速从容且有效地切换。另外，对于 OCR 异常的情况，假设供应商可以重试，我方也可以重试，这样的局面下，尽可能选择我方重试的方案，因此重试的时机、频次和方式是可以自主掌控的，如果依赖对方的重试再通知我方，看上去似乎节省了一些工作，但是却以失去自主性为代价的。一旦客户抱怨说为啥 OCR 还是通不过，我们重试的情况下可以再次操作，而依赖供应商的重试至少会增加沟通的复杂度，重要的是供应商何时重试我们只能提要求，做不做取决于人家。甚至有时候，即使供应商主观上非常愿意配合，一旦出现生产事故，是否联系得上，联系上了对方是否具备操作的条件都是未知数。所以，你觉得哪一个更是老成谋国之举呢？

二、自主性与风险损失保持正相关

在架构设计的时候，经常会遇到一些两难抉择的时刻。譬如两个系统之间的交互，系统 A 调用系统 B 去完成一项功能，对接完成的结果可以是 A 主动查询 B 来实现，也可以是 A 被动等待系统 B 处理完成之后回调。作为架构师，你该如何决策呢？拍脑袋肯定不是最明智的选择；随机选似乎也不合适，同样的场景如果上一次选择主动查，下一次选择回调，只会让人觉得不够具有原则性，进而怀疑专业性和问题思考的深刻性。

在这样的两者看起来都可行的情况下，我们遵循一个原则，即谁承受的风险越大，谁应该优先掌握主导权。

假设上面的案例中，处理结果的及时性对 A 非常重要，却对 B 没有那么重要。B 的回调很可能会因为 B 系统的不稳定或者网络的波动而变动没有那么确切，而且一旦回调异常，A 要想继续流转，必须依靠 B 的补偿机制，假设 B 有补偿机制的话。因此，A 所承担的风险更大，因此，此情此景下，无疑选择 A 主动查询会更加合适，同时，在设计主动查询的时候，做好异常情况下的保障机制。命运要掌握在这里的手中，大体就是这个意思。

三、自主性与事故责任保持正相关

同样两个存在交互关系的系统，假设系统 A 是用户资金发放的系统，B 是用户信息系统。系统 A 在发放的时候，为了保证资金安全，需要用户的身份证图片信息，而这些信息在系统 B 中可能存在，作为用户补充信息的一部分，但是非强制性的。从监管部分的政策条例来看，系统 A 每一个人用户的资金提现操作，必须具备身份证图片信息，一旦缺失，必须及时补充，否则将承受法律风险和经济处罚。

如果你是架构师，你是让系统 A 开发一个身份证上传的功能，如果不上传就不给予资金发放，还是直接调用系统 B，并要求系统 B 的产品经理将原本是完善信息的身份证图片改为必须补充的信息？

如果是从数据一致性、复用性和数据流的合理性的角度来看，让系统 B 强制收集用户的身份证图片似乎更加通顺，而且后续其他系统也可以继续复用。可是问题在于，并非所有用户都有提现的要求，一棒子打死的做法，似乎也不合理，因为无故收集用户的敏感信息本身也是敏感行为。其次，系统 B 可能因为有更加迫切的研发计划，导致在时间上无法满足系统 A 的要求，这样一来，系统 A 的部分用户提现可能会被拦截，也是一个问题。

我们从责任的角度来看，很显然，在提现合规的视角来看，无疑系统 A 承担的责任更大，而系统 B 本身对身份证图片信息的诉求不高。因此，从实际情况出发，由系统 A 自主设计强制性的身份证图片信息收集功能，并同步到系统 B 的方案可能会更加容易落地，并更加能确保符合业务要求。

四、因素分类分级

影响架构决策的因素可能会有很多，这时候我们可以采用分类分级的方式进行处理。将各种因素先进行尽可能的穷举，然后分析这些因素的类型、影响大小，然后进行归类处理。

分类分级可以让我们从大量因素之中抽身出来，避免陷入因素丛林之中而失去方向和判断。当然这也是朴素的解决思路，可以广泛应用到不同的事务之中。