中国建设银行洛阳分行网站,百度做网站多,微信登陆入口官网,营销型网站制作方案大家好#xff0c;今天我们来分享业务架构#xff0c;但是我们并不是以产品经理角度讲述一个业务架构是什么以及如何做#xff1f;而是以一个技术架构师的角度#xff0c;讲述如何承接业务架构或在没有业务架构的时候#xff0c;如何判断业务变化趋势而对系统架构提前做出…
大家好今天我们来分享业务架构但是我们并不是以产品经理角度讲述一个业务架构是什么以及如何做而是以一个技术架构师的角度讲述如何承接业务架构或在没有业务架构的时候如何判断业务变化趋势而对系统架构提前做出反应。
一、发生背景
研发人有技术架构产品经理有业务架构通常是一个人当一个技术架构师不懂业务架构的时候就会出现如下对话。 技术工程师小王“产品经理又改需求昨天和我说订单按照库存状态拆分我刚刚上线今天又和我说按照促销类型类型拆分” 架构师小孙“业务本来就发展迅速的那天他还和我说想根据商品体积拆分的被我挡了回去”。 技术工程师小王“厉害还是你有话语权”。 我相信大家经常遇到类似的问题然而如果技术架构师懂业务架构就会变成下面的对话场景。 技术工程师小王“产品经理又改需求昨天和我说订单按照库存状态拆分我刚刚上线今天又和我说按照促销类型类型拆分还好你上次和我说这块规则是多变的让我把不同订单拆分逻辑拆分为原子化我改下配置就搞定不愧是架构师你怎么知道这块多变难道会占卜” 架构师小孙“哈哈预知未来本来就是架构师的职责”。 技术工程师小王“快教教我吧”。 下面我们就来学习下如何如何让技术架构师具有预知未来业务发展的能力。
二、解决方案
技术架构师需要了解业务架构的知识但是又不用像产品经理知道那么多例如价值链等等概念。他需要知道的如何识别业务发展变化趋势并把对应部分的技术架构做好结构化、扩展性。我今天就来介绍一个简单的方法- 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知识模型分析下业务多变的点。 来源京东云开发者社区 作者京东零售 李春丽未经授权请勿转载
