能力地图是帮助用户快速理解业务中台所提供的业务服务能力，并且共享已有的业务服务能力的辅助系统，是业务中台的产品化包装。 　　能力地图作为业务中台的辅助系统，是需要帮助用户理解，使前台应用系统更顺利的接入业务中台，从而真正的发挥出业务中台的价值，使得业务中台真正有效的落地。这个让别人理解的过程让别人愿意使用业务中台的共享服务的过程就是能力地图的作用。业务中台应该像SaaS产品一样可以是业务团队看得见的软件产品。

能力地图的各种清单是其提供功能的基础。

能力地图记录业务中台的所有可共享的业务服务能力，并且以业务（运营）团队能理解的语言描述其功能职责、适用场景、成本、收益、已采用（或者说接入）的业务线／产品线，所属的业务共享部门。业务线（或产品线）+ 可共享业务服务能力 + 相互间的依赖关系 = 能力地图的直观形象（节点与箭头构成的有向无环图，如同地图导航一样）。这个这里所说的业务服务能力不是底层的技术服务（Restful API / Dubbo Service Interface / K8S service）。这里的描述都应该是非技术人员能够理解的语言文字／视频。

能力地图清楚的描述公司的每一个应用系统，以Application为最小单位（可独立部署或运行的最小单元），包括其功能职责、边界定义、所属系统、所属的业务owner、所属的IT owner。这里的语言描述应该是各个技术团队都能理解的。这些Application 与业务能力清单中的可共享的业务服务能力，实际会存在多对多的关系。能力地图需要记录这个对应关系，以便于分析、建议、帮助接入。这些信息可以简单的来源于（面向应用的）CMDB。 　　业务能力与Application(应用程序)是有明显区别的，前者是业务角度，后者是技术角度。例如，API Gateway的隔离熔断能力，不是业务能力，没有必要出现在业务能力清单。认证授权是业务运营团队能够理解的，是属于业务能力清单里的，认证可以帮助识别客户或者用户群体，而“授权”更是帮助业务针对性运营的手段之一。

这里所说的产品可以是金融产品、软件产品，实物产品、餐饮产品、劳动服务。一般包括其分类信息。 以金融产品为例，这里应该描述其资金流、客户旅程、监管信息。 以软件产品为例，例如某个商业的手机办公软件，这里应该存档其用户指南、版权信息、收费方式、发行渠道、编程语言、维护团队等基础信息。

公司的各个业务线、部门、团队设置，及其职能。如果业务中台是集团提供的，则还应该记录集团下的各个专业公司。这些信息可以简单的来源于HR相关系统或者LDAP。用于标识应用系统的业务owner，标识应用系统的服务对象。标识哪些是前台部门（例如客服）、中台部门、后台部门（例如GS行政）。

大多数基于微服务架构风格建设的比较完善的系统都会有服务注册中心，其中记录着各种服务提供者及服务消费者的相关信息。能力地图可简单的对接服务注册中心，即可知道哪个应用程序提供了哪些微服务，消费了哪些微服务，构建出微服务的依赖图。 　　本文中的“微服务”如果没有特别声明，都是指注册在服务注册中心的微服务，如Dubbo框架以接口为单位注册，基于Restful风格的可以URL为单位注册。K8S的service虽然也有服务自动发现的意义，也注册在ETCD，但更多的是负载均衡/DNS的意义，是我们平时说的Application（应用程序）的一种部署模式。

能力地图的功能从表面上看是比较简单的，想做得好就不容易了。用户操作越简单，系统构建越复杂。

能力地图识别用户身份（知道用户是哪个部门的做什么工作的），记录用户过往的搜索行为，识别用户的工作场景及其兴趣，根据用户输入的关键字，将上述各种清单信息筛选最合适的排序展现。

当用户在能力地图中输入的不是名词，而是动词，或者是询问句的时候，能力地图可以理解用户要做的事。例如一位金融产品经理，输入：“打造电商领域分期付款产品”。可能公司并没有电商领域的分期付款产品，但有线下零售领域的分期付款产品。能力地图将“线下零售领域的分期付款产品”整个资金流与客户旅程相关信息展现，并且建议这位金融产品经理与哪些（运营/财务/IT ）关系人联系以了解流程的关键环节。像地图导航软件一样，提供智能的分析与路线建议。这样就可以大量的节省开发新产品的时间成本，并且可以共享已有的一些业务服务能力。不会闭门造车，开发一些新的奇葩的业务流程浪费运营成本，不会重复建设浪费IT开发成本。 　　当然这个功能是比较理想的，落地有难度，但借助于日趋成熟的NLP自然语言理解，是可以做到的。智能客服已经被应用得很广泛。更多的可能不是技术可行性，而是成本与收益的衡量。

主要是各种清单信息的展现，包括：

主要是关联CMDB、服务注册中心、事件处理系统等，对可共享的业务服务能力给出自动分析的报告。这个技术难度不大，主要也是成本与收益的衡量。可以实现简单的问卷调查，用于共享服务的评价与反馈。

能力中心由多项业务能力所组成，某项业务能力可能又是由多项更小的业务能力支持。例如某支付公司会员中心可以提供认证能力，而认证能力可以分为人脸识别、密码认证、指纹认证、公安系统身份证影像实名认证、银行卡四要素实名认证、微信OpenID关联认证、合作伙伴关联认证。 　　应用系统一般可以由多个应用程序组成，从类型上可以由前端应用程序、BFF应用程序、job跑批作业、联机应用程序等不同类型的应用程序组成，从功能上可以由不同功能的应用程序组成。例如账务系统，可以由记账、清算、会计、对账、调账、封账等不同的应用所组成。 　　前两者，一是从业务维度构建的树，一是从技术维度构建的树，两者的节点并不是一一对应的。在树的底层叶子节点，需要构建关联关系，清楚的知道哪个应用程序支持了哪个业务能力，是多对多的关系。业务能力与应用程序能否一对一呢？在规模小的环境下，是可以考虑这么规划的，但在规模大的环境下，总会受到很多的技术约束、环境约束、文化约束、历史包伏，追求一对一没有太多实际意义。 　　我们可以将这个能力地图对应到现实生活中的地理地图来理解。地理地图有国、省、市、区、街道，构成一个树状结构，而高速公路、铁路、航线贯穿于其中。我们要到某个较远的目的地（省市区）旅游，可能需要经过很多个火车站，中途可能要换乘高铁、大巴。要乘坐高铁就要先依赖于大巴抵达某个火车站，这种依赖关系一段接着一段。 　　将能力中心理解为某个省市、将业务能力理解为某个市／区，将应用系统理解为某个交通系统，将应用程序理解为某条高速公路或某条铁路，将微服务的远程调用理解为乘坐某辆大巴（或某列火车）到达另一个高速公路服务区（或火车站）。将我们要开展的某个业务理解为我们要到某个地方去旅游。 　　这就是我喜欢称之为“能力地图”的原因，很形象。 　　将上述所有的清单信息及关联信息录入Neo4j这样的图数据库，我们很容易就可以得到一个关联图结构。只需要将最底层的叶子节点关联起来，就可以通过图的遍历分析，得到高层节点的依赖关系图。如同从深圳去云南大理旅游，即使不知道省与省之间的邻接关系，也可以通过一路上铁路站点、高速公路站点的信息知道要途径哪些省市。 　　能力地图对公司业务规划与IT规划的作用，如同百度地图、高德地图对于旅客一样。输入一个目的地，可以给出建议的规划路线。能力地图对于不同公司的业务环境，不一定能做到非常智能，但可以给出非常重要、真实、准确的路线参考。

网上很多文章都有说业务中台要怎么做，各种方法论。其中有很多是高屋建瓴的，但在落地的时候，都是需要解决如何对待大量遗留系统的。我认为其中应该有那么几步是要走的，而这几步所获得的信息恰好是能力地图的初始输入。