写点什么

如何让技术架构师具有预知未来业务发展的能力? | 京东云技术团队

  • 2023-05-18
    北京
  • 本文字数:2437 字

    阅读完需:约 8 分钟

如何让技术架构师具有预知未来业务发展的能力? | 京东云技术团队


以一个技术架构师的角度,承接业务架构或在没有业务架构的时候,如何判断业务变化趋势而对系统架构提前做出反应?

一、发生背景

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


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


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


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


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


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


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


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


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

二、解决方案

技术架构师需要了解业务架构的知识,但是又不用像产品经理知道那么多,例如价值链等等概念。他需要知道的如何识别业务发展变化趋势,并把对应部分的技术架构做好结构化、扩展性。我今天就来介绍一个简单的方法- 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 知识模型分析下业务多变的点。


来源:京东云开发者社区

作者:京东零售 李春丽(未经授权请勿转载)

发布于: 刚刚阅读数: 4
用户头像

拥抱技术,与开发者携手创造未来! 2018-11-20 加入

我们将持续为人工智能、大数据、云计算、物联网等相关领域的开发者,提供技术干货、行业技术内容、技术落地实践等文章内容。京东云开发者社区官方网站【https://developer.jdcloud.com/】,欢迎大家来玩

评论

发布
暂无评论
如何让技术架构师具有预知未来业务发展的能力? | 京东云技术团队_架构师_京东科技开发者_InfoQ写作社区