数字中台与架构设计

        最近在赶鸭子上架，做一个大型行业应用的架构设计。说实话，非我所长。从公司层面和个人层面都有一堆需要吐槽的地方。下面就把个人前面的一些认识和这次的感想一起再贴一下。

    一、战略层面（吐槽小老板）

      1、战略倾斜，做不到抓大放小，始终盯着面前哪一点肉    

         这个没什么可说的，老板有老板的战略，员工有员工的规划。

         现在的老板的问题是，格局太小，整体把握实在不均衡。由于民企都是从小到大，一刀一枪从土鳖干起来的，在目前规模还是局限在千万级别的情况下，面对已经出现并正在深入的业务危机，操作这个业务转型实在是困难。于是天天在嘴上说，要加强咨询设计服务的业务，要降低政府业务的占比，深入XX、YY行业。但是，始终停留在嘴炮阶段：既没有针对XX、YY行业出台新的优惠政策，也没有加强这个方面的业务投入，只是对下面的负责人（比如本人）整天说，要深入啊，要加强学习啊。叉叉，你不给政策不给钱，我上哪去找资源。一些特别小的项目甚至是几千块钱卖报告的事情都去接，每天都疲于应付事务性的事情，比如一般性的技术文档、开发票、打合同、贴报销票据，这些都要自己弄，哪还有时间去分析行业动态，构建技术平台核心能力。

         这个带来的最大的一个点，就是没有团队凝聚力。公司、部门、小组、个人之间就是一种层层承包、逐级提成的机制，不会有人（包括老板自己）愿意去沉淀，去扩展平台。目前的情况就是，一帮子真有能力有资源，最后也是握在手里，然后独立出去自立门户了。原来的两个最大业务部门的负责人就是这样情况。

         这一点，和著名企业、前面待过的国企差别还是比较大的。国企是分得太细，人太多，管太死，待遇上不去；但团队组织比较完善，平台的投入还是比较大的。

   2、控制成本，不愿意找人、特别是高素质人才，极力压缩成本

           这个也许是优点，但在进入一个新行业和新业务时，就可能是问题了。感觉现在这个平台肯定是做不大了，这样下去估计也做不长了。过两年还得转行。

           找人帮忙，不愿意出成本。人我们去找了，但是成本要全部团队出，公司和部门不愿意分担，其实就是上面说的政策倾斜，哪还搞个屁啊，消耗我有限的人脉资源啊。哪我们也就不必用力了。一遍不断强调很重要，很有难度；一边不愿意投入，不给政策，在这种层层结算的机制下，执行者当然不可能太卖力。

二、个人层面（吐槽技术面）

          没啥说的，技术层面有欠缺，始终搞不定设计，加上动力确实不足，因此团队的工作成果实在乏善可陈。

1、中台策略：

         目前普遍提的中台，感觉也是个坑。数据中台实在原来大数据平台基础上，普遍加上数据治理概念。再套上知识图谱，让人工智能插上翅膀。

          说来说去，数据平台的要害，还是组织要做好数据梳理，对需要开展的业务模式，务必要有清楚的认识和描绘。而实施团队一定要摸清现有系统的情况，尤其是需要接入处理的数据情况。在这个基础上统一数据标准，做好数据规划。其实框图很好画，但是这个梳理确实要花功夫。

        另外一个业务中台，现在大家都在说，其实这个也就是互联网企业炒概念，对于业务规模不大的单位，其实没啥意义。就是搞成不同业务系统就好了。另外，业务中台怎么规划，也不单纯是个技术架构问题，其实必然会涉及到业务规划，影响未来的组织架构。

2、架构设计

        最烦一些部门内的资深人士，啥也不懂，就在旁边指手画脚。一说就把网上找来的框图扔出来，要这样那样。但比PPT架构师还糟糕的是，这个XX引擎是干啥的，为什么要用，不知道，就觉得AT的文章里有，我们也画上就好，时髦啊。问题是这样瞎搞，还我还要花时间来应付。

三、学习笔记

       借着这个项目，赶紧提升一下自己的实力，速成一下中台，增强架构设计的意识。 下面总结一下经验。

1、咨询设计的过程。（老生常谈，再次强调）

不提行业背景、竞争对手、数字化全景这些，先看看具体的需求调研与现状调研。

1）内部需求调研

• 客户业务目标。客户想要做成什么样，达到什么样目的，战略层面的目标和战术层面的。  调研时绝对不能停留在表面，一定要摆出一些具体的调查内容。否则就始终浮在表面。
• 搞清实际用户。用户有哪些，内部和外部的，各自的要求。如果是宏观战略规划，有时这个实际上是模糊的。
• 搞清楚数据和流向。内外部的数据、系统接口。
• 最后是硬件分布和部署。现在很大一块还要一并调研安全、运维的服务方案。

     一定要搞定业务接口人。一个强悍的内部代理人会帮助外部咨询设计团队搞定绝大部分事情。

     还是前面说的：数据图、业务图、部署图这些能够画出来，基本上需求调研就OK了。整体架构图自然而然就出来了。但是宏观规划类的，一般是很难有准确的，通常需要设计方去启发、引导。所以规划人员一定要有相关的知识储备。如果啥都不懂，就像我开始一样，完全是去存心忽悠，当然会死得比较难看。

2）现状调研

• 针对目前的系统、目前规划中的系统的情况进行调研。一般被调研方会有自我保护的意识，屁股不同，想法又会有很大差异。因此，期望粗浅的调研解决问题一般是不实际的。一定要细致地设计问题，拿到第一手资料。

• 规划数据接口。重点调研现有系统的数据。了解规划中在建系统的情况。系统的槽点。

 2、数字中台设计。

（参考书：钟华. 企业IT架构转型之道：阿里巴巴中台战略思想与架构实战）

1）概念。

·服务：指服务端暴露出来的一种服务接口，代表服务端一个具体的能力。

·服务化：核心 是从产品能力转化直接服务客户的能力。

中台就是把共享的能力转化成服务并提供良好的服务治理支持。

a、确定服务接口；

b、建设服务治理基础设施；

共享服务的基础设施就是提供服务元数据规范与工具，帮助API完成从普通服务到组件化服务的蜕变。

可以提供API、产品、解决方案级别的不同层级的服务方式。

2、建设内容

（参考书的偏向业务和性能，但一般搞中台是为了方便业务扩展，性能要求没那么高。）

1）建设目标和绩效考核机制

业务中台除了提供对前端应用的高效支持，同时也承载了业务持续沉淀和创新的使命。

绩效考核机制：

服务稳定性	40
服务创新性	25	允许一定级别和一定数量的故障
服务应用数	20
服务满意度	15

2）能力开放，构建基于数据的生态体系

体系内参与者，仅仅是被动的使用者，往往是由于利益被捆绑进来而加入的，这个就是上下游的概念；

而主动加入者，就是能力开放平台的主动介入方，利用平台开放的接口，获得数据和能力支持，从而提供贴近用户的服务的，这个才是主动的，才会去创新和帮助平台繁荣，成为一种生态。

信息中心在企业中的组织职能从长久以来的业务支持走向了基于企业核心业务和数据进行服务运营之道

3）业务中台的价值

• 服务重用。带来服务培育业务创新，赋予业务快速创新和试错能力。以快打慢，降维打击。
• 真正发挥大数据威力。业务中台需要大数据统一标准、积聚数据--数据资产，培养基于数据进行业务分析建模的专家--数据洞察，进一步产生基于业务的创新。--业务创新。
• 信息化部门由业务支持转向企业核心业务和数据运营、服务运营

4）技术体系建设

      CAP、BASE原理。深入看，几乎大型系统都面临的问题就是大规模用户带来的性能问题，高性能背景下，一个小的事务都是一个很值得深入探究的大课题。

• 业务中台分布式服务框架       基于微服务，而不是SOA的另外一种--ESB。
• 中台服务划分原则                          通用的，但不宜设置得太碎。目的是通过业务拆分来降低系统的复杂性；通过服务共享来提供可重用性；通过服务化来达到达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。“以终为始”。
• 数据库分库分表，分布式数据库    
• 业务性能       业务流程异步化，优化业务并发处理流程，处理速度提升。缓存技术的运用。
• 数字化运营（运维）      埋点；输出日志
• 平台稳定性       限流、降级；流量调度；业务开关；全链路压测；业务一致性审计平台