今天是第八篇：中台建设中技术平台的考虑。
— 1—
指挥官体系建设中需要支持的平台的分类
前面文章的读者对象主要是CIO/CTO、产品经理、企业架构师，这个章节的读者对象主要是企业架构师/首席架构师。本篇内容长、专业内容多，建议收藏仔细阅读。
今天要讲前面介绍的指挥官体系的作战体系/能力视角、指挥体系/响应视角、生产体系、稳态视角、敏态视角如何具体落地。
— 2—
指挥官体系建设中涉及的高阶技术架构
服务是业务和技术的二位一体
各个企业的指挥官体系的建设过程中，最终发挥价值的是产品，而IT技术团队看到的产品是什么呢？是一个个服务。服务既是业务功能，也是技术上的实现接口。
企业的作战体系体现企业的能力视角，这些能力是由服务来体现的。
指挥体系体现了企业的响应视角，这个视角是由服务的关系来体现的。
我们引入一个术语：事件，这里事件就代表服务间发生了关系。所以企业里的基本关系就是：服务-事件-服务。这个构成了事件驱动的架构（EDA）。这个构成了指挥官体系的敏态视角。
我们可以看到服务之间的关系可能是稳定的，也可能是不那么稳定、随着时间动态变化的。如果服务间的关系是稳定的，我们去掉“服务-事件-服务”中的事件， 关系就变成了“服务-服务”，这个就变成了面向服务的架构（SOA）。这个构成了指挥官体系的稳态视角。从这里可以看出，大多数企业整体的设计过去都基本是从稳态视角出发的。
面向敏态视角的EDA架构适应性更强，但是设计耗费的人力成本也更大。在具体的设计过程中，要分析服务之间的关系是相对稳定，还是变化频繁。前者适合采用SOA架构，后者适合EDA架构。
企业会是EDA SOA的架构
过去的系统设计多采用SOA架构，现在的指挥官体系中，采用EDA架构的服务会越来越多。因为在这个VUCA时代，变化才是常态，但从整体的架构看， 企业的架构会是一个EDA SOA的架构。
两个因素决定了EDA架构比重会越来越大：一是VUCA时代的常态变化；二是团队识别服务本质的能力差距，也需要变化。为了隔离不断调整服务所带来的影响，最小化其影响，采用EDA架构就会越来越多。
我自己的体会是：稳在敏中求，没有敏，很难出来理想的稳；而稳的固化，会让企业更加的敏。敏中求稳，稳中得敏，此敏已非彼敏！稳和敏不是对立关系，而是统一关系，对方的存在可以让自己更好！
— 3—
作战体系/能力视角
从业务流程到具体实现，在面向服务的建模方法论中，涉及服务的识别、确定和最后的实现。有了服务的基本单元后，服务交互的角色就出现了， 主要的角色包含服务提供方、服务消费方、服务管理方以及底层的服务集成框架。
服务各方的关系就构成了一个面向服务的架构（SOA）。SOA意味着应用设计的最佳实践的总结。
SOA的设计构成包含两部分工作，第一部分是应用层级的工作，这涉及到服务的识别和确定。
这部分的方法有很多，比如IBM有一个五天的面向服务的建模方法论（SOMA），TOGAF的应用架构设计，领域驱动设计（DDD）等都大同小异，都可以帮助识别服务、定义服务。
整体而言，这些方法都太重，实际分析设计中，研发团队实际遵照执行的很少。这里面有很多原因，例如研发进度紧张、团队成员能力不足等。但据我观察，大体还是因为方法论太重导致，团队在使用前最好做一番裁剪。
没有花拳绣腿的 服务分析V字法
这里我介绍一个分析服务、设计应用架构的非常简单实用的方法，我总结为服务分析V字法。
上图中左边业务活动拆解构成的模型就是BAM（业务活动图），右边的就是服务/服务组，或者也可以看作企业的应用架构。
将业务流程中包含的活动一层层分解， 最后分析出最小粒度的功能，然后再将这些功能按照相关度进行聚合，识别出服务、服务组，或者应用架构中的应用。建设架构视角的中台时，避免重复建设的分析设计工作就是在这个环节做的。具体识别候选服务、确定服务的过程中，要根据服务的相关性确定服务是否合并，这里有操作数据是否相同、是否业务环节连续等判断，最关键还是要看服务在业务上的相关性。
服务的设计要贴近业务，要进行差异化区分；服务组件的设计要多考虑重用，不同的服务可能是由一个服务组件提供的。服务组件会调用功能组件和技术组件，这样，服务-服务组件-功能组件/技术组件的三个分层就体现出来了。
稳定的服务的识别构成了指挥官体系的能力视角
经过这一层级的工作，服务、服务组就可以被识别出来，比如零售中的订单中心、会员中心等就是在这部分工作中识别出来的。这里要说一下，一些稳定的数据服务也是在这部分工作中识别出来的。
SOA的设计还包括支撑的技术平台的支持，这里列出两个直接相关的平台，其他公共需要的技术平台在最后章节讲述。
第一个平台是服务交互平台，这个平台有两种类型：一种是分布式服务调用框架，最初这种框架适合企业技术标准统一，服务通过注册都可以被服务管理平台进行管理，现在已经演变成为可以支持异构系统；另一种是集中服务调用平台，就是企业服务总线（ESB）。不管是哪种类型，基本都支持服务管理、服务监控、服务熔断、服务流控、服务版本化等共性能力。
第二个平台是主数据管理平台，其本质是一种数据服务，主数据有这几个特点：数据相对稳定、多个应用使用，相对频繁访问。所以设计通过数据分发来实现，其实这是一个技术设计的最优实现。主数据管理平台的主要能力是数据排重、数据分发实时、保证分发的数据的一致性。
— 4—
指挥体系/响应视角/稳态视角/敏态视角
上面讲了企业的作战体系， 企业已经清楚了自己具备的能力或者服务。这些服务如何响应市场，取决于指挥体系如何响应。
服务的交互构成了指挥官体系的响应视角
这种业务上的关系进入IT体系后， 就变成服务之间的关系。服务是由作战体系提供的。任何一次和用户的交互会触发一系列服务的执行，这些执行本质就是指挥体系在发挥作用，也是指挥官体系的响应视角。
直接和用户交互的服务，在企业内部和其他服务如何进行交互，这是指挥体系要回答的问题。
稳定的服务、稳定的服务关系构成了指挥官体系的稳态视角
以下几种情况可以采用服务直接调用的方式：服务间关系很稳定，或者相对稳定，或者必须等待服务提供方执行完毕、服务消费方才能继续。这个时候，服务消费方强依赖服务提供方，二者耦合关系比较紧。这种耦合关系是设计时确定的，二者形成了服务契约，如果要有变化，需要双方沟通重新设计修改。
服务的调用要有契约精神
SOA的架构一定要管理好服务契约，架构设计、变更要有契约精神，否则会带来很多问题。
这一过程中对用户负责的是服务消费方，但能够确定服务消费方和服务提供方服务契约的责任人是谁呢？很多企业没有明确这样的角色，其实这个角色是端到端产品经理。SOA架构带来的另一个问题是：服务提供方的负责团队的积极性很容易被打击，因为 TA 被服务契约束缚着。团队的感觉是：每次想做点什么，都要沟通、沟通，扯皮的事情太多。根本原因是被一个不好的架构束缚着，每个人都是局中的受困者。
所以我建议：
尽可能少用服务调用
SOA架构在VUCA时代是一个不太好的架构，要尽量少用。
这个时候每个服务都属于一个产品，属于一个运营团队，也属于一个研发团队。每个服务设计的时候，监控事件，当某个事件发生时，触发服务执行。服务到底如何做，是由服务提供方的团队负责，团队的主观能动性就被激发了。
解耦的服务的关系，EDA的架构定义了指挥官体系的敏态视角
整体设计时，大家定义抛出的事件、监控的事件，从全局角度去定义这些事件。整体架构是被事件驱动的，服务和服务的关系是被事件驱动的，事件是有业务含义的；另外最关键的是部门和部门间的关系变成协作关系，不是指挥关系。当某个事件发生时，如何做出响应是自己部门的职责，自己要思考，自己要和自己的业务目标、产品目标对齐。为了达到自己的目标，要主动对事件关心，当事件触发时完成目标。EDA架构完美的解决了服务关系的不确定性问题。
另外EDA架构也能支持企业对于及时响应的更高要求，除非是统计意义上的数据处理，否则都是实时、准实时进行了服务处理。所以从这个意义上来说，设计中也要：
尽可能减少对于作业/job，批处理/batch的使用
这些事件中，有一种共性的事件，就是服务契约没有达到企业要求，这些事件都会被指挥体系捕获，有专门的监控服务进行处理。
另一个就是针对数据实体的不确定性的处理，过去都基于数据实体设计属性进行处理，如果涉及到数据实体的结构变化，需要从底层改起，影响很大。
数据标签可以帮助应对数据的不确定性
今天类似于服务的交互设计，针对相对静态的数据，设计为数据实体的属性；针对相对动态的数据，设计为数据实体的标签，所以针对数据实体的标签平台会在系统中占有一席之地，用来应对企业处理的数据的不确定性，从面向数据实体属性向面向数据实体属性和标签进行演变。属性处理数据实体的静态特征，标签处理数据实体的动态特征。
指挥体系在明确了作战体系的各自服务/产品职责后，协作通过事件来进行，持续监控服务/产品契约，确保达到契约承诺，可以看出打赢战争的最终保障在指挥体系，指挥体系是指挥官体系的神经中枢。
— 5—
生产体系
生产体系保证作战体系、指挥体系需要的产品/服务快速、稳定的交付到生产环境。
包含持续集成（CI），持续部署（CD），持续运行（CO）。在这方面业界已经很多商业化产品，也有散着的很多开源的产品。
生产体系需要具备的能力：
1. 快速集成，快速部署，比如一个单一的发布 ，是否能在1S发布完成。
2. 为失败设计，灰度发布，秒级回退，A/B测试等，就是任何的发布包都可能有技术、业务上的问题，缺省假设是出问题。
3. 规模化并行集成、部署，一个大的项目，涉及10个产品、300个服务，能否支持各自相对独立集成测试、发布，但整体目标统一，形散而神不散，整体目标可视，各自相对独立。
4. 一切兼资产，所有的产品、服务、系统等都是数字化资产，都被管理、监控起来。
— 6—
对于公共技术平台的要求
IaaS平台一定要达到公有云的水平
一句话：不要自己做，对公司不好，对自己也不好。对于中国大部分公司，自己做这部分没有意义，纯粹是给自己找个学习机会和造第一百个轮子。两个基本的考核点：1 、申请资源除去审批环节的耗费时间是否能在分钟内获得？ 2 、是否和研发环节无缝集成？如果这两个没有做到，就不要吹牛了；如果做到了，还可以和厂商谈商务，用自己的投入和厂家谈，云厂家一定可以做到比你便宜。
海量交易高并发一定是公共平台/组件
比如一般的数据库分库分表、缓存服务、集成服务，都要采用技术平台解决掉海量交易高并发的问题。
另外一条路就是serverless，这个一定是方向，合适的时机切入，可以获得技术红利。
事务一致性处理是很多企业技术管理薄弱的地方
如果网络不抖动，如果机器不宕机，程序一切正常；事实是网络一定会抖动，机器一定会宕机，所以很多企业的程序整天有问题。这个的原因很简单，没有处理好事务。这个时候企业要制定自己的事务处理规范，确定事务处理技术平台，任何一个服务都要遵守该事务规范，采用该事务处理平台，这个问题就解决了。
监控一切
无数据不管理，无监控不研发。制定业务监控、系统监控规范，根据监控规范确定监控平台，一切的产品、服务、系统都要被监控，监控是指挥体系的眼睛。
控制一切
任何的异常，一种是转生产体系，一种是转作战体系。不管是哪一种，都要有控制手段。
决策一切
今天决策由人工 智能构成，不断的将人工的部分持续的转智能，第一步是将规则系统化，交由系统根据规则决策；第二步是学习人的决策数据，交由系统通过机器学习、深度学习智能决策。在这个环节利用的技术目前主要有RPA机器人 AI技术 数据湖。
— 7—
作战指挥室（决策系统）是企业的指挥中枢
指挥官体系是一个充分授权的体系，各个产品独立进化，各个组织持续改进。怎么保证整体为共同目标一起努力呢？
第一是设计阶段，整体目标对齐，要有整体规划，这里可以借用类似CBM、EA等方法论做整体规划，利用OKR/KPI等手段赋予做这些事情的意义，激发人的主观能动性。
第二是运行阶段，能够在整体看到全局，公司的高层持续在全局进行关注，持续优化。有整体视角，在每个季度都做对全局最优的工作，进而赢得这场商业战争。
在IT系统里面，什么元素承担这一职责呢？业务活动图（BAM）。
大家要注意到， 我说的是BAM，不是流程。为什么不是流程呢？ 流程太细了，很难维护设计态和运行态的一致性，如果采用了类似BPM等平台， 又束缚了一些团队的主观能动性。
如何用好BAM呢？第一设计阶段，明确企业的业务活动以及业务活动的关系，识别出服务。
运行阶段，能根据服务间的交互关系，生产一个动态的BAM视图，供企业高层、研发团队二次迭代使用，这里最关键是可视化，直观形象的展示企业能力-业务活动-服务的关系，是哪些服务在阻碍企业的核心能力落地。
— 8—
下一步工作
今天介绍的技术平台是在逻辑层面、应用层面，具体到落地，还要做技术选型，产品选型，上面提到的产品或多或少在市场上都有，大家知道自己所需后，做选型其实也就很简单了。
到此为止，指挥官体系/中台系列的主要内容就介绍完了，感谢大家耐心看到这里。这是一个具体可行、可落地的系列，希望对大家能有所帮助。
我相信每一个IT人都不想在企业里面做着外包的工作，一定希望成为企业的核心竞争力。时代在呼唤指挥官体系，想明白了“该不该”的问题，就努力去解决“能不能”的问题。
千里之行始于足下，开始行动吧，加油！
