业务中台-能⼒地图
⼀、什么是能⼒地图?
能⼒地图是帮助⽤户快速理解业务中台所提供的业务服务能⼒,并且共享已有的业务服务能⼒的辅助系统,是业务中台的产品化包装。
能⼒地图作为业务中台的辅助系统,是需要帮助⽤户理解,使前台应⽤系统更顺利的接⼊业务中台,从⽽真正的发挥出业务中台的价值,使得业务中台真正有效的落地。这个让别⼈理解的过程让别⼈愿意使⽤业务中台的共享服务的过程就是能⼒地图的作⽤。业务中台应该像SaaS产品⼀样可以是业务团队看得见的软件产品。
⼆、能⼒地图有什么功能
能⼒地图的各种清单是其提供功能的基础。
2.1 清单
2.1.1 业务能⼒清单
能⼒地图记录业务中台的所有可共享的业务服务能⼒,并且以业务(运营)团队能理解的语⾔描述其功能职责、适⽤场景、成本、收益、已采⽤(或者说接⼊)的业务线/产品线,所属的业务共享部门。业务线(或产品线)+ 可共享业务服务能⼒ + 相互间的依赖关系 = 能⼒地图的直观形象(节点与箭头构成的有向⽆环图,如同地图导航⼀样)。这个这⾥所说的业务服务能⼒不是底层的技术服务(Restful API / Dubbo Service Interface / K8S service)。这⾥的描述都应该是⾮技术⼈员能够理解的语⾔⽂字/视频。
2.1.2 应⽤系统清单
能⼒地图清楚的描述公司的每⼀个应⽤系统,以Application为最⼩单位(可独⽴部署或运⾏的最⼩单元),包括其功能职责、边界定义、所属系统、所属的业务owner、所属的IT owner。这⾥的语⾔描述应该是各个技术团队都能理解的。这些Application 与业务能⼒清单中的可共享的业务服务能⼒,实际会存在多对多的关系。能⼒地图需要记录这个对应关系,以便于分析、建议、帮助接⼊。这些信息可以简单的来源于(⾯向应⽤的)CMDB。
业务能⼒与Application(应⽤程序)是有明显区别的,前者是业务⾓度,后者是技术⾓度。例如,API Gateway的隔离熔断能⼒,不是业务能⼒,没有必要出现在业务能⼒清单。认证授权是业务运营团队能够理解的,是属于业务能⼒清单⾥的,认证可以帮助识别客户或者⽤户体,
⽽“授权”更是帮助业务针对性运营的⼿段之⼀。
2.1.3 产品清单
这⾥所说的产品可以是⾦融产品、软件产品,实物产品、餐饮产品、劳动服务。⼀般包括其分类信息。
以⾦融产品为例,这⾥应该描述其资⾦流、客户旅程、监管信息。
以软件产品为例,例如某个商业的⼿机办公软件,这⾥应该存档其⽤户指南、版权信息、收费⽅式、发⾏渠道、编程语⾔、维护团队等基础信息。
2.1.4 组织结构
公司的各个业务线、部门、团队设置,及其职能。如果业务中台是集团提供的,则还应该记录集团下的各个专业公司。这些信息可以简单的来源于HR相关系统或者LDAP。⽤于标识应⽤系统的业务owner,标识应⽤系统的服务对象。标识哪些是前台部门(例如客服)、中台部门、后台部门(例如GS⾏政)。
2.1.5 微服务清单
⼤多数基于微服务架构风格建设的⽐较完善的系统都会有服务注册中⼼,其中记录着各种服务提供者及服务消费者的相关信息。能⼒地图可简单的对接服务注册中⼼,即可知道哪个应⽤程序提供了哪些微服务,消费了哪些微服务,构建出微服务的依赖图。
本⽂中的“微服务”如果没有特别声明,都是指注册在服务注册中⼼的微服务,如Dubbo框架以接⼝为单位注册,基于Restful风格的可以URL为单位注册。K8S的service虽然也有服务⾃动发现的意义,也注册在ETCD,但更多的是负载均衡/DNS的意义,是我们平时说的Application(应⽤程序)的⼀种部署模式。
2.2 功能
能⼒地图的功能从表⾯上看是⽐较简单的,想做得好就不容易了。⽤户操作越简单,系统构建越复杂。
微服务注册中心有哪些2.3.1 关键字搜索
能⼒地图识别⽤户⾝份(知道⽤户是哪个部门的做什么⼯作的),记录⽤户过往的搜索⾏为,识别⽤户的⼯作场景及其兴趣,根据⽤户输⼊的关键字,将上述各种清单信息筛选最合适的排序展现。
2.3.2 关键字建议
当⽤户在能⼒地图中输⼊的不是名词,⽽是动词,或者是询问句的时候,能⼒地图可以理解⽤户要做的事。例如⼀位⾦融产品经理,输⼊:“打造电商领域分期付款产品”。可能公司并没有电商领域的分期付款产品,但有线下零售领域的分期付款产品。能⼒地图将“线下零售领域的分期付款产品”整个资⾦流与客户旅程相关信息展现,并且建议这位⾦融产品经理与哪些(运营/财务/IT )关系⼈联系以了解流程的关键环节。像地图导航软件⼀样,提供智能的分析与路线建议。这样就可以⼤量的节省开发新产品的时间成本,并且可以共享已有的⼀些业务服务能⼒。不会闭门造车,开发⼀些新的奇葩的业务流程浪费运营成本,不会重复建设浪费IT开发成本。
当然这个功能是⽐较理想的,落地有难度,但借助于⽇趋成熟的NLP⾃然语⾔理解,是可以做到的。智能客服已经被应⽤得很⼴泛。更多的可能不是技术可⾏性,⽽是成本与收益的衡量。
2.3.3 清单信息与关联图表
主要是各种清单信息的展现,包括:
1. 关联图
1. 能⼒中⼼与业务能⼒的树状结构图
2. 应⽤系统与应⽤程序的树状结构图
3. 业务能⼒相互间的依赖关系图
4. 服务注册中⼼的服务提供者与服务消费者之间的依赖关系
5. 哪些应⽤程序⽀持了哪些业务能⼒(多对多的⽀持关系)。通过这层关系跨越了技术与业务。例如某个⾦融产品的客户旅程中某个客户
场景依赖于哪些微服务。这样基于调⽤链分析,就可以得知某个业务服务能⼒是如何构建的。也可以得知某个⾦融产品是如何通过IT⽀撑的。
6. 更多关联关系:应⽤程序所依赖的数据库、VM、负载均衡器、物理机/数据中⼼。
2. 属性列表。
当⿏标单击上⾯关联图的某个节点时,展⽰这个节点的相关属性。
1. 渠道/业务线/产品:产品描述、⽬标客户体、资⾦流概要描述
2. 能⼒中⼼:职能描述
3. 业务能⼒:职能描述,业务属主(owner)
4. 应⽤系统:职能描述,IT属主(owner),分层信息,板块信息。
5. 应⽤程序:职能描述,IT属主(owner),类型(微服务应⽤/job/前端应⽤/BFF应⽤)。
6. 服务注册中⼼所注册的微服务(Dubbo的Interface / Restful的API):职能描述,IT属主。
2.3.4 共享系数、质量报告、状态报告
主要是关联CMDB、服务注册中⼼、事件处理系统等,对可共享的业务服务能⼒给出⾃动分析的报告。这个技术难度不⼤,主要也是成本与收益的衡量。可以实现简单的问卷调查,⽤于共享服务的评价与反馈。
三、能⼒地图如何构建?
能⼒中⼼由多项业务能⼒所组成,某项业务能⼒可能⼜是由多项更⼩的业务能⼒⽀持。例如某⽀付公司会员中⼼可以提供认证能⼒,⽽认证能⼒可
以分为⼈脸识别、密码认证、指纹认证、公安系统⾝份证影像实名认证、银⾏卡四要素实名认证、OpenID关联认证、合作伙伴关联认证。
应⽤系统⼀般可以由多个应⽤程序组成,从类型上可以由前端应⽤程序、BFF应⽤程序、job跑批作业、联机应⽤程序等不同类型的应⽤程序组成,从功能上可以由不同功能的应⽤程序组成。例如账务系统,可以由记账、清算、会计、对账、调账、封账等不同的应⽤所组成。
前两者,⼀是从业务维度构建的树,⼀是从技术维度构建的树,两者的节点并不是⼀⼀对应的。在树的底层叶⼦节点,需要构建关联关系,清楚的知道哪个应⽤程序⽀持了哪个业务能⼒,是多对多的关系。业务能⼒与应⽤程序能否⼀对⼀呢?在规模⼩的环境下,是可以考虑这么规划的,但在规模⼤的环境下,总会受到很多的技术约束、环境约束、⽂化约束、历史包伏,追求⼀对⼀没有太多实际意义。
我们可以将这个能⼒地图对应到现实⽣活中的地理地图来理解。地理地图有国、省、市、区、街道,构成⼀个树状结构,⽽⾼速公路、铁路、航线贯穿于其中。我们要到某个较远的⽬的地(省市区)旅游,可能需要经过很多个⽕车站,中途可能要换乘⾼铁、⼤巴。要乘坐⾼铁就要先依赖于⼤巴抵达某个⽕车站,这种依赖关系⼀段接着⼀段。
将能⼒中⼼理解为某个省市、将业务能⼒理解为某个市/区,将应⽤系统理解为某个交通系统,将应⽤程序理解为某条⾼速公路或某条铁路,将微服务的远程调⽤理解为乘坐某辆⼤巴(或某列⽕车)到达另⼀个⾼速公路服务区(或⽕车站)。将我们要开展的某个业务理解为我们要到某个地⽅去旅游。
这就是我喜欢称之为“能⼒地图”的原因,很形象。
将上述所有的清单信息及关联信息录⼊Neo4j这样的图数据库,我们很容易就可以得到⼀个关联图结构。只需要将最底层的叶⼦节点关联起来,就可以通过图的遍历分析,得到⾼层节点的依赖关系图。如同从深圳去云南⼤理旅游,即使不知道省与省之间的邻接关系,也可以通过⼀路上铁路站点、⾼速公路站点的信息知道要途径哪些省市。
能⼒地图对公司业务规划与IT规划的作⽤,如同百度地图、⾼德地图对于旅客⼀样。输⼊⼀个⽬的地,可以给出建议的规划路线。能⼒地图对于不同公司的业务环境,不⼀定能做到⾮常智能,但可以给出⾮常重要、真实、准确的路线参考。
四、⼤量遗留系统的基础上如何构建?
⽹上很多⽂章都有说业务中台要怎么做,各种⽅法论。其中有很多是⾼屋建瓴的,但在落地的时候,都是需要解决如何对待⼤量遗留系统的。我认为其中应该有那么⼏步是要⾛的,⽽这⼏步所获得的信息恰好是能⼒地图的初始输⼊。
1. 识别所有的客户/⽤户/合作伙伴体。
2. 梳理应⽤系统清单、各条业务线的产品清单。
3. 通过访谈了解公司组织结构、各团队的⼯作职能及其对接部门。
4. 确定哪些application属于前台范围?
5. 确定哪些application属于技术平台?
6. 确定哪些application属于后台范围?
7. 确定哪些application属于中台范围?
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论