如何让技术架构师具有预知未来业务发展的能力

大家好，今天我们来分享业务架构，但是我们并不是以产品经理角度讲述一个业务架构是什么以及如何做？而是以一个技术架构师的角度，讲述如何承接业务架构或在没有业务架构的时候，如何判断业务变化趋势而对系统架构提前做出反应。

一、发生背景

研发人有技术架构，产品经理有业务架构（通常是一个人），当一个技术架构师不懂业务架构的时候，就会出现如下对话。

技术工程师小王：“产品经理又改需求，昨天和我说订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”

架构师小孙：“业务本来就发展迅速的，那天他还和我说想根据商品体积拆分的，被我挡了回去”。

技术工程师小王：“厉害，还是你有话语权”。

我相信大家经常遇到类似的问题，然而如果技术架构师懂业务架构，就会变成下面的对话场景。

技术工程师小王：“产品经理又改需求，昨天和我说订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分，还好，你上次和我说这块规则是多变的，让我把不同订单拆分逻辑，拆分为原子化，我改下配置就搞定，不愧是架构师，你怎么知道这块多变？难道会占卜？”

架构师小孙：“哈哈，预知未来本来就是架构师的职责”。

技术工程师小王：“快教教我吧”。

下面我们就来学习下如何，如何让技术架构师具有预知未来业务发展的能力。

二、解决方案

技术架构师需要了解业务架构的知识，但是又不用像产品经理知道那么多，例如价值链等等概念。他需要知道的如何识别业务发展变化趋势，并把对应部分的技术架构做好结构化、扩展性。我今天就来介绍一个简单的方法- MIT知识模型。简单来说是 1：映射（Mapping） 2 识别（identify） 3 询问（ask about）

映射（Mapping）：所有的需求可以映射到如下系统化、结构化的语言，计算机程序是在什么样的场景（事件）下开始行动，程序需要读取哪些数据（实体），依据什么样的顺序（活动）、规则（任务）由谁（组织/角色）执行，执行后会产生哪些数据（实体）。但是针对一个特定的场景来说，顺序（活动）、规则（任务）由谁（组织/角色）是更容易多变的。

识别（identify）&询问（ask about**）：所以我们在和产品经理沟通需求的时候，最主要的是识别顺序、规则**（组织/角色通常在权限系统RBAC模型可以配置，可以不用多考虑）。如何快速识别顺序和规则呢？

1、 顺序：一个场景经过的多个业务活动，这个通常产品经理的业务流程图会展示，例如商品引入功能，需要经过“洞察”、“选品”、“招商”、“法务”等多个业务流程节点。找到这个顺序后，主要问产品2个问题就可以判断是否多变，“这个顺序，是否在不同客户/渠道/品类等不同端或渠道不同”，“这个顺序，是否因为短期上线压力，妥协只是做了简化”。

通常产品经理在调研的时候会获得这个信息。如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以有多种方式处理扩展性，可以做出多个微服务，或者利用流程引擎工具实现扩展性。

2、规则：通常是（ IF A then B）模式，他通常在在每个顺序节点下面，例如在商品引入的“洞察”的业务活动时候，如果发现有如下话术“如果商品是大家电，需要考虑竞对价格因子”，“如果商品是滞销类型，可以不用参与洞察”等等。

如果发现这类术语，基本可以判断是规则；当然还有些规则比较隐蔽，需要我们来挖掘，例如案例中**“订单按照库存状态拆分，我刚刚上线今天又和我说按照促销类型类型拆分”，**这里其实并没有那么明显的（ IF A then B）模式，但是通常有形容词的动词，都有可能变化（例如 按照库存状态拆分）。

但是如果在挖掘下或仔细思考下，就可以看出出来这个两个拆分逻辑，一定是有条件或顺序的，否则同一个订单拆分会乱套的。

如果在这个时候，我们在追问下产品2个问题，

“1、这个规则，是否在特定的条件下才有效，例如客户/渠道/品类等不同端或渠道、时间段、优先级顺序”。

“2、这个规则，在不同客户/渠道/品类等不同端或渠道，还有可能其他规则“。

同样，如果产品经理不确定，可以让产品经理在调研下，有个这个信息，在系统架构处理的时候，就可以多种方式处理扩展性，最简单代码的可以做策略模式，或利用配置文件、规则引擎dools等实现扩展性。

三、案例分析

通过以上简单的模型，我们就客户还原架构师小孙，在和产品经理沟通的需求场景。

产品经理小李：“这次我们要做个业务，订单履约。这是我的PRD，今天我们一起看下。“

架构师小孙：“PRD写的挺详细的。通过我这个PRD。我们理解了订单履约大概要实现的功能，你看我这样说是否正确：订单履约功能需求，需要读取订单数据，在经过拆分、打标顺序，产生多个拆单后订单，并传输给物流系统。通常这些工作，由系统自动处理无需人员干涉。是吧？”

产品经理小李：“是的，大的逻辑是这样的。”

架构师小孙：“这里拆分、打标顺序，否在不同客户/渠道/品类等不同端或渠道不同。是否因为短期上线压力，妥协只是做了简化？“

产品经理小李：“我调研了4个客户，3个订单渠道，以及竞品都是经过这个这几个环节。目前看没有在新节点的可能性。”

架构师小孙：“好的，那我为了成本考虑。我先把流程节点设计为固定，后续你这里发现有多变的场景及时通知我，另外我看你在拆分环节，提到订单按照库存状态拆分，这里是所有订单都按照库存状态拆分吗？”

产品经理小李：“额，我我觉得是。“

架构师小孙：“我建议你在调研下，不同客户/渠道/品类等不同端或渠道下，是否有不同逻辑”，通常在有形容词的动作，都是可能变化的。”

—— 一段时间后

产品经理小李：“嗯是的，客户A说他们除了库存、还有运费、礼品卡、商品体积拆分逻辑，这些会按照顺序来依次进行“。

架构师小孙：“OK。这块我设计为可扩展性的。”

四、总结陈述

看，架构师有业务预知性或者业务敏感性其实挺简单的，就是找对位置，多问些问题，就可以为一线研发减少很多工作量。这个能力在很多地方，也可以称为业务敏感性。

所以系统扩展性设计一定离不开业务输入，但是如何通过几个简单的问题，就可以快速找到业务多变的地方，就是我本次分享的MIT模型解决的。大家也可以请根据一个业务场景，按此MIT知识模型分析下业务多变的点。

来源：京东云开发者社区

作者：京东零售 李春丽（未经授权请勿转载）