查看原文
其他

中台指挥官体系建设系列 八- 中台建设中技术平台的考虑

乔新亮 数据工匠俱乐部 2021-10-15

前面发过一篇文章,《大道至简:企业需要的中台是什么?答案是:指挥官体系》,收到诸多朋友的积极反馈,很多人都希望我再写一篇完整的文章,聚焦中台的建设挑战和建设路径等落地操作层面。此系列便应大家所需,再话中台,作为前作的姊妹篇 ——“中台指挥官体系”终极篇。

今天是第八篇:中台建设中技术平台的考虑。

指挥官体系建设中需要支持的平台的分类

前面文章的读者对象主要是CIO/CTO、产品经理、企业架构师,这个章节的读者对象主要是企业架构师/首席架构师。本篇内容长、专业内容多,建议收藏仔细阅读。

今天要讲前面介绍的指挥官体系的作战体系/能力视角、指挥体系/响应视角、生产体系、稳态视角、敏态视角如何具体落地。

指挥官体系建设中涉及的高阶技术架构
2.1服务是业务和技术的二位一体

各个企业的指挥官体系的建设过程中,最终发挥价值的是产品,而IT技术团队看到的产品是什么呢?是一个个服务。服务既是业务功能,也是技术上的实现接口。

企业的作战体系体现企业的能力视角,这些能力是由服务来体现的。

指挥体系体现了企业的响应视角,这个视角是由服务的关系来体现的。

我们引入一个术语:事件,这里事件就代表服务间发生了关系。所以企业里的基本关系就是:服务-事件-服务。这个构成了事件驱动的架构(EDA)。这个构成了指挥官体系的敏态视角

我们可以看到服务之间的关系可能是稳定的,也可能是不那么稳定、随着时间动态变化的。如果服务间的关系是稳定的,我们去掉“服务-事件-服务”中的事件, 关系就变成了“服务-服务”,这个就变成了面向服务的架构(SOA)。这个构成了指挥官体系的稳态视角。从这里可以看出,大多数企业整体的设计过去都基本是从稳态视角出发的。

面向敏态视角的EDA架构适应性更强,但是设计耗费的人力成本也更大。在具体的设计过程中,要分析服务之间的关系是相对稳定,还是变化频繁。前者适合采用SOA架构,后者适合EDA架构。

2.2企业会是EDA+SOA的架构

过去的系统设计多采用SOA架构,现在的指挥官体系中,采用EDA架构的服务会越来越多。因为在这个VUCA时代,变化才是常态,但从整体的架构看, 企业的架构会是一个EDA+SOA的架构。

两个因素决定了EDA架构比重会越来越大:一是VUCA时代的常态变化;二是团队识别服务本质的能力差距,也需要变化。为了隔离不断调整服务所带来的影响,最小化其影响,采用EDA架构就会越来越多。

我自己的体会是:稳在敏中求,没有敏,很难出来理想的稳;而稳的固化,会让企业更加的敏。敏中求稳,稳中得敏,此敏已非彼敏!稳和敏不是对立关系,而是统一关系,对方的存在可以让自己更好!

作战体系/能力视角从业务流程到具体实现,在面向服务的建模方法论中,涉及服务的识别、确定和最后的实现。有了服务的基本单元后,服务交互的角色就出现了, 主要的角色包含服务提供方、服务消费方、服务管理方以及底层的服务集成框架。
服务各方的关系就构成了一个面向服务的架构(SOA)。SOA意味着应用设计的最佳实践的总结。
SOA的设计构成包含两部分工作,第一部分是应用层级的工作,这涉及到服务的识别和确定。

这部分的方法有很多,比如IBM有一个五天的面向服务的建模方法论(SOMA),TOGAF的应用架构设计,领域驱动设计(DDD)等都大同小异,都可以帮助识别服务、定义服务。

整体而言,这些方法都太重,实际分析设计中,研发团队实际遵照执行的很少。这里面有很多原因,例如研发进度紧张、团队成员能力不足等。但据我观察,大体还是因为方法论太重导致,团队在使用前最好做一番裁剪。

没有花拳绣腿的服务分析V字法

这里我介绍一个分析服务、设计应用架构的非常简单实用的方法,我总结为服务分析V字法。

上图中左边业务活动拆解构成的模型就是BAM(业务活动图),右边的就是服务/服务组,或者也可以看作企业的应用架构。

将业务流程中包含的活动一层层分解, 最后分析出最小粒度的功能,然后再将这些功能按照相关度进行聚合,识别出服务、服务组,或者应用架构中的应用。建设架构视角的中台时,避免重复建设的分析设计工作就是在这个环节做的。具体识别候选服务、确定服务的过程中,要根据服务的相关性确定服务是否合并,这里有操作数据是否相同、是否业务环节连续等判断,最关键还是要看服务在业务上的相关性。

服务的设计要贴近业务,要进行差异化区分;服务组件的设计要多考虑重用,不同的服务可能是由一个服务组件提供的。服务组件会调用功能组件和技术组件,这样,服务-服务组件-功能组件/技术组件的三个分层就体现出来了。

稳定的服务的识别构成了指挥官体系的能力视角

经过这一层级的工作,服务、服务组就可以被识别出来,比如零售中的订单中心、会员中心等就是在这部分工作中识别出来的。这里要说一下,一些稳定的数据服务也是在这部分工作中识别出来的。

SOA的设计还包括支撑的技术平台的支持,这里列出两个直接相关的平台,其他公共需要的技术平台在最后章节讲述。

第一个平台是服务交互平台,这个平台有两种类型:一种是分布式服务调用框架,最初这种框架适合企业技术标准统一,服务通过注册都可以被服务管理平台进行管理,现在已经演变成为可以支持异构系统;另一种是集中服务调用平台,就是企业服务总线(ESB)。不管是哪种类型,基本都支持服务管理、服务监控、服务熔断、服务流控、服务版本化等共性能力。

第二个平台是主数据管理平台,其本质是一种数据服务,主数据有这几个特点:数据相对稳定、多个应用使用,相对频繁访问。所以设计通过数据分发来实现,其实这是一个技术设计的最优实现。主数据管理平台的主要能力是数据排重、数据分发实时、保证分发的数据的一致性。

指挥体系/响应视角/稳态视角/敏态视角

上面讲了企业的作战体系, 企业已经清楚了自己具备的能力或者服务。这些服务如何响应市场,取决于指挥体系如何响应。

服务的交互构成了指挥官体系的响应视角

这种业务上的关系进入IT体系后, 就变成服务之间的关系。服务是由作战体系提供的。任何一次和用户的交互会触发一系列服务的执行,这些执行本质就是指挥体系在发挥作用,也是指挥官体系的响应视角。

直接和用户交互的服务,在企业内部和其他服务如何进行交互,这是指挥体系要回答的问题。

稳定的服务、稳定的服务关系构成了指挥官体系的稳态视角

以下几种情况可以采用服务直接调用的方式:服务间关系很稳定,或者相对稳定,或者必须等待服务提供方执行完毕、服务消费方才能继续。这个时候,服务消费方强依赖服务提供方,二者耦合关系比较紧。这种耦合关系是设计时确定的,二者形成了服务契约,如果要有变化,需要双方沟通重新设计修改。

服务的调用要有契约精神

SOA的架构一定要管理好服务契约,架构设计、变更要有契约精神,否则会带来很多问题。

这一过程中对用户负责的是服务消费方,但能够确定服务消费方和服务提供方服务契约的责任人是谁呢?很多企业没有明确这样的角色,其实这个角色是端到端产品经理。SOA架构带来的另一个问题是:服务提供方的负责团队的积极性很容易被打击,因为 TA 被服务契约束缚着。团队的感觉是:每次想做点什么,都要沟通、沟通,扯皮的事情太多。根本原因是被一个不好的架构束缚着,每个人都是局中的受困者。

所以我建议:

尽可能少用服务调用

SOA架构在VUCA时代是一个不太好的架构,要尽量少用。

这个时候每个服务都属于一个产品,属于一个运营团队,也属于一个研发团队。每个服务设计的时候,监控事件,当某个事件发生时,触发服务执行。服务到底如何做,是由服务提供方的团队负责,团队的主观能动性就被激发了。

解耦的服务的关系,EDA的架构定义了指挥官体系的敏态视角

整体设计时,大家定义抛出的事件、监控的事件,从全局角度去定义这些事件。整体架构是被事件驱动的,服务和服务的关系是被事件驱动的,事件是有业务含义的;另外最关键的是部门和部门间的关系变成协作关系,不是指挥关系。当某个事件发生时,如何做出响应是自己部门的职责,自己要思考,自己要和自己的业务目标、产品目标对齐。为了达到自己的目标,要主动对事件关心,当事件触发时完成目标。EDA架构完美的解决了服务关系的不确定性问题。

另外EDA架构也能支持企业对于及时响应的更高要求,除非是统计意义上的数据处理,否则都是实时、准实时进行了服务处理。所以从这个意义上来说,设计中也要:

尽可能减少对于作业/job,批处理/batch的使用

这些事件中,有一种共性的事件,就是服务契约没有达到企业要求,这些事件都会被指挥体系捕获,有专门的监控服务进行处理。

另一个就是针对数据实体的不确定性的处理,过去都基于数据实体设计属性进行处理,如果涉及到数据实体的结构变化,需要从底层改起,影响很大。

数据标签可以帮助应对数据的不确定性

今天类似于服务的交互设计,针对相对静态的数据,设计为数据实体的属性;针对相对动态的数据,设计为数据实体的标签,所以针对数据实体的标签平台会在系统中占有一席之地,用来应对企业处理的数据的不确定性,从面向数据实体属性向面向数据实体属性和标签进行演变。属性处理数据实体的静态特征,标签处理数据实体的动态特征。

指挥体系在明确了作战体系的各自服务/产品职责后,协作通过事件来进行,持续监控服务/产品契约,确保达到契约承诺,可以看出打赢战争的最终保障在指挥体系,指挥体系是指挥官体系的神经中枢。

生产体系

生产体系保证作战体系、指挥体系需要的产品/服务快速、稳定的交付到生产环境。

包含持续集成(CI),持续部署(CD),持续运行(CO)。在这方面业界已经很多商业化产品,也有散着的很多开源的产品。

生产体系需要具备的能力:

1. 快速集成,快速部署,比如一个单一的发布 ,是否能在1S发布完成。

2. 为失败设计,灰度发布,秒级回退,A/B测试等,就是任何的发布包都可能有技术、业务上的问题,缺省假设是出问题。

3. 规模化并行集成、部署,一个大的项目,涉及10个产品、300个服务,能否支持各自相对独立集成测试、发布,但整体目标统一,形散而神不散,整体目标可视,各自相对独立。

4. 一切兼资产,所有的产品、服务、系统等都是数字化资产,都被管理、监控起来。

对于公共技术平台的要求

IaaS平台一定要达到公有云的水平

一句话:不要自己做,对公司不好,对自己也不好。对于中国大部分公司,自己做这部分没有意义,纯粹是给自己找个学习机会和造第一百个轮子。两个基本的考核点:1 、申请资源除去审批环节的耗费时间是否能在分钟内获得?  2 、是否和研发环节无缝集成?如果这两个没有做到,就不要吹牛了;如果做到了,还可以和厂商谈商务,用自己的投入和厂家谈,云厂家一定可以做到比你便宜。

海量交易高并发一定是公共平台/组件

比如一般的数据库分库分表、缓存服务、集成服务,都要采用技术平台解决掉海量交易高并发的问题。

另外一条路就是serverless,这个一定是方向,合适的时机切入,可以获得技术红利。

事务一致性处理是很多企业技术管理薄弱的地方

如果网络不抖动,如果机器不宕机,程序一切正常;事实是网络一定会抖动,机器一定会宕机,所以很多企业的程序整天有问题。这个的原因很简单,没有处理好事务。这个时候企业要制定自己的事务处理规范,确定事务处理技术平台,任何一个服务都要遵守该事务规范,采用该事务处理平台,这个问题就解决了。

监控一切

无数据不管理,无监控不研发。制定业务监控、系统监控规范,根据监控规范确定监控平台,一切的产品、服务、系统都要被监控,监控是指挥体系的眼睛。

控制一切

任何的异常,一种是转生产体系,一种是转作战体系。不管是哪一种,都要有控制手段。

决策一切

今天决策由人工+智能构成,不断的将人工的部分持续的转智能,第一步是将规则系统化,交由系统根据规则决策;第二步是学习人的决策数据,交由系统通过机器学习、深度学习智能决策。在这个环节利用的技术目前主要有RPA机器人+AI技术+数据湖。

作战指挥室(决策系统)是企业的指挥中枢

指挥官体系是一个充分授权的体系,各个产品独立进化,各个组织持续改进。怎么保证整体为共同目标一起努力呢?

第一是设计阶段,整体目标对齐,要有整体规划这里可以借用类似CBM、EA等方法论做整体规划,利用OKR/KPI等手段赋予做这些事情的意义,激发人的主观能动性。

第二是运行阶段,能够在整体看到全局,公司的高层持续在全局进行关注,持续优化。有整体视角,在每个季度都做对全局最优的工作,进而赢得这场商业战争。

在IT系统里面,什么元素承担这一职责呢?业务活动图(BAM)。

大家要注意到, 我说的是BAM,不是流程。为什么不是流程呢?  流程太细了,很难维护设计态和运行态的一致性,如果采用了类似BPM等平台, 又束缚了一些团队的主观能动性。

如何用好BAM呢?第一设计阶段,明确企业的业务活动以及业务活动的关系,识别出服务。

运行阶段,能根据服务间的交互关系,生产一个动态的BAM视图,供企业高层、研发团队二次迭代使用,这里最关键是可视化,直观形象的展示企业能力-业务活动-服务的关系,是哪些服务在阻碍企业的核心能力落地。

下一步工作

今天介绍的技术平台是在逻辑层面、应用层面,具体到落地,还要做技术选型,产品选型,上面提到的产品或多或少在市场上都有,大家知道自己所需后,做选型其实也就很简单了。

到此为止,指挥官体系/中台系列的主要内容就介绍完了,感谢大家耐心看到这里。这是一个具体可行、可落地的系列,希望对大家能有所帮助。

我相信每一个IT人都不想在企业里面做着外包的工作,一定希望成为企业的核心竞争力。时代在呼唤指挥官体系,想明白了“该不该”的问题,就努力去解决“能不能”的问题。

千里之行始于足下,开始行动吧,加油!

(欢迎大家加入数据工匠知识星球获取更多资讯。)

联系我们

扫描二维码关注我们


微信:DaasCai

邮箱:ccjiu@163.com

QQ:3365722008

热门文章

中台/指挥官体系建设系列一:什么是中台,为什么需要中台


中台/指挥官体系建设系列二:中台建设的挑战以及应对策略


中台/指挥官体系建设系列三:中台的建设路径以及关键决策


中台/指挥官体系建设系列四:中台建设中平台分类和职责


中台/指挥官体系建设系列五:企业中台建设中个人能力成长


中台/指挥官体系建设系列六:稳态/敏态视角下的中台审视


中台/指挥官体系建设系列七:中台建设谁主导?中台建设都要自建吗?

我们的使命:发展数据治理行业、普及数据治理知识、改变企业数据管理现状、提高企业数据质量、推动企业走进大数据时代。

我们的愿景:打造数据治理专家、数据治理平台、数据治理生态圈。

我们的价值观:凝聚行业力量、打造数据治理全链条平台、改变数据治理生态圈。

了解更多精彩内容


长按,识别二维码,关注我们吧!

数据工匠俱乐部

微信号:zgsjgjjlb

专注数据治理,推动大数据发展。

: . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存