这个分享是基于从2020年初的一个疫情之后，我们作为一个技术产品公司的一种思考。

从我们分析角度来讲，我今天会从三个维度进行阐述：

第一个维度，从宏观角度来讲，整个社会的运转方式在潜移默化的发生一些变化。

第二个维度，我们对IT从业人员或者程序员工作方式的一种思考以及现状的一种延伸。

第三个维度，基于现状，对我们产品研发工作的一些思考以及趋势的一种展望。

1、疫情加速转变社会运转方式

首先可以用简单的数字来看一下美国在线的零售业。美国在线的零售业其实是很有意思的事情：在疫情之前，美国在线或者说网商、电商数据较差，直到2020年疫情的发生，有了一定上升。从这个角度来讲，所有的社会运转可以看到潜移默化的变化。

同样国内的在线教育付费用户，也发生了一些变化，预计到2020年可能在2.6亿人次。这体现了在疫情情况下，大家对在线教育的从不认可到认可，也隐含了社会的运转方式在变。

2、程序员的工作方式正在面临转变

对于我们程序员，在这个社会里难免会遇到各种随着时代变化的转变。从这个角度去看一些现象：疫情期间，程序员的工作方式也发生了一些变化。众所周知，在疫情期间，尤其美国那边，很多人无法回到自己的办公地点。据某一个科技媒体报道，微软已经允许每周有半数的时间在家自由的办公，如果经过主管的批准，可以永久在家办公。同样Facebook也在发生变化，Facebook的首席执行官预测在5~10年内，Facebook的人员可能有半数以上的在家办公。

这就引发的我们的一个思考。传统的方式回到办公室，办公室里会给你创造各种优良的环境，提供各种舒适的环境，甚至可以带你宠物上班，这种方式都是让大家聚焦在办公环境去办公。而现在我们面临的是在家办公，整个IT的建设和程序员的工作方式到底发生什么变化呢？这个其实可能会在未来一段时间内形成一个深远的影响。

作为一个供应商，我们反思了一下疫情期间我们面临的情况。在疫情期间，我们甲方的IT系统由于人员不到位情况下，IT建设是停滞的，甚至包括一些新项目的采购。因为疫情的控制，最核心的本质是说大概在2、3、4月份左右，其实供应商是很难入场的。

对于供应商本身角度来讲，遇到的问题是什么？我们现在无法入场，导致没有收入，成本和现金压力都非常大。比较幸运的是说在中国较好的疫情控制下，供应商也都顺利的进入场地了。这里面就有一个隐含的反思，我们是解决好了在疫情这种远程办公情况下的，供应商和甲方的一个合作模式？还是说现在因为疫情控制住了，问题不存在了？

问题不存在了，但是问题并不是因为真正解决了而不存在的。这个就开始反思我们到底整个IT建设会何去何从？那么我在思考这个问题的时候会想到：其实整个社会在进行数字化，而我们的工作，我们程序员的工作是不是真的数字化了呢？

回到我们这一个核心的主题，我们认为数字化其实有一个很核心的方向。福布斯在9月21日发布了一个2021年的十大数字化转型趋势。每年都会发布，我每年都会去看。我惊奇的发现了一个点：work from home。从疫情之后，可能在家办公远比疫情还要持久，简单点说疫情会改变我们整个的工作模式。这个模式的变化会导致的一个问题：疫情之后仍然会在家办公，或者是远程办公将成为一个主流。

这个趋势是如何改变我们的IT建设？

我个人认为程序员也在迎来一个数字化时代。现在绝大多数情况工作环境是IT信息化的时代，我们有时候会有Jira、有Git等去建一些编译系统。其实本质来讲，传统行业也会有自己的信息化，其实是在做我们程序员工作或者是IT工程师的一个信息化工作，而未来我相信一定会趋向于一个数字化时代。

数字化时代，相对于传统的信息化时代，大家有很多争论说区别在哪里？从我核心的角度来讲，数字化是改变的一个行为模式，而不是简单的把工作信息化掉这个过程。为什么这么说？我们传统理解说我需要一个版本管理，需要搭一个Git，Git可能需要一个账号，我需要注册一个账号，这只是把我们的工作变成了一个信息化工作，未来可能会融入一体的进行数字化改变。

这里面首先我要去重申一下，我们的认知的一个变化。我在产品预研的过程中，包括对一些友商的竞争产品的了解以及未来趋势的了解，我会发现有很多认知是在打破我十几、二十年老程序员的一个理解。

比如最典型的在Linux下你去使用一个root权限，我们传统认知里是需要知道root的一个用户名密码，否则我是无法工作的。

第二个问题就是说，既然我们程序员经常会用到一些代码提交，那代码提交，我们现在最早用CVS、SVN，现在变成了Git，对于我来讲，我肯定会被分配一个Git账号和密码，这是我专属的。

这两个问题在未来的数字化时代的时候，这种方式是否合理？是不是必须？从我的分析看答案是不必须的。我举两个例子，第一个：我们在试用一些云化的产品的时候，比如说Google cloud，Google cloud默认其实是不提供root的密码的，这里面就是说我如何去使用 root权限去做？其实root的权限只是一种服务，当我去使用一个需要root的时候，我仅需要去作为一个sudo这种方式去做，不需要用密码，然后就可以获取到相关的权限，只要在我的账号体系里或者认证体系里，我是被认证成可以使用root的，这里面有一个问题就是说这个账号的密码是什么呢？

其实是有平台提供的，我去尝试一下是否可以在Google cloud上去使用root密码的登录？答案是可以的，但是非常繁琐，我需要开通很多东西才可以使用，这里面其实就是说在未来的默认的很多方式里，我可能只是需要，我有权限使用 root这个服务，而不是说我需要这个用户和密码。

同样我们有很多人在使用一些小程序开发，小程序开发的时候，其实有对应的代码提交和版本，我们可以看到，我会去下一个小程序开发工具，我在整个过程中我会有版本管理的概念，但是我根本就没有对应的Git的一个账号和密码，甚至我都可以理解为我看了结构，我才知道它是Git，而实际上它不需要任何的Git的相关知识。

未来的数字化里很多对于系统的边界会被模糊掉，而对于所有的系统的提供的服务，会以一个以我们程序员为中心的这种使用习惯的转变而转变，这也将是会对我们整个理解的一些变化。

我们也会发现一些开发环境或者是习惯上的一些变化。因为在这个过程中，我们已经不是单纯的面向于一些我们的JVM（一些函数）去编程，我们可能面向大量的服务，甚至是说传统的，包括老的一些服务，这个过程中其实是未来是会基于大量的基础服务或者运转的，甚至连root权限，我就认为是一种可被使用的一个服务。

3、面向中台的开发或许成为一种趋势

未来的数字化时代、IT建设其实不仅限于一个单纯的用户体验和服务基础，这个是Gartner一个理解。Gartner建议是企业去建立一个网格化的应用和一个服务架构，以实现全局和面向未来的规划和管理。

说的比较罗嗦，整个架构其实可以看到它其实是多用户体验的，以及一个API怎么翻译？其实是一个（API）集成的一种方式，而对应的后端的service其实是多种多样的，它可以有传统的一些方式，也可能会有一些SaaS的服务，甚至是说一些微服务的架构，这都可能会存在。

当然跟这个东西在国内不是特别的流行，从我们直接角度来讲，我们认为国内和国外的环境不是完全相同，也就是说为什么我们会把中台提出来，而不是说MASA这种模式去提出来，我们技术从理念角度来讲可能会去参考一些，但是实践角度来讲，我会发现在国外的一个体系里，其实传统的立柱架构比较严重，甚至可能有七八十年代，或者是八九十年代的一些东西来做，可能大家都也见过新闻，有些系统要召回老程序员去进行改造，但是对于国内其实建设是一个滚动的、持续版本迭代的一种替换式的一个更新，也就是说未来三五年内，或者5年内，或者远的说是十年内有些架构会彻底重新进行做，这些东西其实就会变得一个架构的更合理度上，是更容易去做一些架构的话。

我们认为数字中台，我们整个大的主题里也会提到，数字中台其实跟MASA这种模型其实是异曲同工，而且我们从国内的趋势看，其实中台化的架构演进是一种趋势。当然这里面中台其实大家有各种争论，以最早的阿里系的这种说法，以及包括腾讯系，腾讯会把内容中台作为一个呈现，它其实是一个业务领域的中台，但是我觉着这个东西是会随着认知去发生一些变化的。

基于这个角度来讲上，从现在看未来可能会延续的去发展，现在架构来讲，在普元的这个体系里是一个薄前台，一个厚中台以及一个稳定的后台去做一些呈现。

仔细去看的话，其实跟MASA这个模型其实有异曲同工之处，不同点其实在于MASA这个模型，其实中台是一个更像一个API的快速编排集成，而普元的中台其实是需要一个标准化，甚至有一些分各种领域，数据中台，业务中台，甚至是一些技术中台的承接，它是一个厚平台的理念。

从我们直接角度来讲，这个可能是符合国内IT建设的一种趋势，当然大家也知道IT本身是一个螺旋式上升，未来可能随着时代的发展，可能在三五年内版本不断迭代，可能会有新的特性，一些理念进入，这都是有可能的。

从这个角度来讲，我们去看这件事情，这是一个技术架构上的一个变化，就是说传统的，我们仔细去看一下，其实这里面没有去过多提我们普元经常会提到的微服务架构的一些说法，因为其实架构只是中台理念的一种实践模型，而这个其实是一个没有过多去涉及到的东西（技术细节的实现）。

数字化时代，其实我认为IT的诉求会爆发，然后会推动一个技术的全民化。这个词其实国内很多技术人员分享就叫做技术的民主化，但这个词从我个人角度来讲，我觉得国内不是特别恰当的使用。我们认为未来的IT会分为三大类用户使用，第一个是大众开发者，第二部分是IT或者IT业务人员开发者，第三部分是专业的开发人员。

我相信现在能看到这个视频绝大多数是专业的开发人员和IT开发人员，比如说未来我们会去分享一些，或者是在之前我们已经听到过的我们顾主任的一个分享，他可能是站在一个技术中台，如何去做技术人员分享，这个部分是专业的一个开发人员，他会用专业的工具去解决专业的问题。

对于我们认识最少的一部分其实是大众的开发人员，这也是数字化转型而带来的一个点，这些人员可能是对于业务非常熟悉，对于技术可能就是一个小白。对于这个解决方案来讲，其实它恰恰是在数字化时代里更多承接的一些人群。

我会从几个维度去看，第一个其实技术全民化在不同厂商的理解是不完全相同的。这一部分其实是Power APP，微软的一个产品体系的理解，它基本上把他所有东西都依赖于一个它的service，它的云上的一个service，基于这个把用户分成了一个，你可以理解为全民的developer和一个专业的developer，我觉得这个东西不是特别恰当一个原因是说它把云作为一个基础，说认为所有的云的服务不用你再去承接了。

但对于国内的一些架构体系里，其实私有云或者一些其他的基础能力，其实是需要甲方去进行采购，去建设，而这一部分其实恰恰是更专业的人群在做。比如说像普元这种公司在承接，或者其他的合作伙伴、友商在承接，这个其实是绝大多数云厂商在做的一个方案就是说我不希望让你看到对于IaaS、PaaS层的一个承建，你看到的就是一个广泛的开发者以及部分的人员可能会解决不了的一个问题。

但对于我们的理解里，专业的开发人员是中台的缔造者和技术中台的使用者。我这里面有两个概念，第一个就是中台的缔造者，因为无论怎样中台都会是有人在承建的，无论是甲方自行承建，还是普元这种中台厂商去承建。

其实中台的技术平台部分有大量的一个扩展性的工作，这一部分其实放出去其实是一个，对于一般的IT从业人员，比如说纯业务开发的一些供应商，甚至说一些广泛的一些业务人员，其实使用是很难使用的。

所以从这一点角度来讲，我们认为业务开发人员去面对的是这么一个场景，中台的专业人员他会屏蔽到一个基础环境，也会把中台做成标准化，端到端，柔性的，当然有一部分业务人员会直接去使用技术的特性，有一部分的扩展能力却是专业人员来承接的，这也是我们普元最核心的定位之一。

我们的IT从业人员或者业务开发人员是基于业务中台进行快速的创新的，这里面就有一个隐含的主题，业务中台是谁建设的？在我们整个理念里，首先是有专业开发人员和IT人员去统一建设去完成的，为什么这么说？

其实业务的理解其实不是一个技术单纯这么理解的，所以从这个角度来讲，我们可能会有更多的中台，比如产品中台、渠道中台、运营中台、营销中台。甚至可能细分到业务领域，比如说像腾讯信息平台的内容中台，内容是它的核心。比如说由不同厂商提供了不同的中台，我认为专业（业务）人员的开发是基于一个业务的开发。那么这一部分其实我们一般理解来讲，它应该是统一的开发工具，他可能基于VS code做了一个二次开发的工具，它也可能将来走上一个web端的开发工具，但他都是一个相对于偏开发的人员，当然少量的会用一些低代码的一个方式去做。

第三部分，重点去阐述大众型的开发人员，他会基于一个web端的开发，对于这个角度来讲，我认为他未来会结合着人工智能驱动的一个低代码的，配置化的平台支撑。

为什么这么说？因为未来如果你中台化以后，你大量的开发人员使用的习惯形成，就会在中台被沉淀，他也有可能去做一些工作，这里面我们会提到了几个概念：

第一个，可以移动端通过一个很简单的配置，能把一个APP进行开发出来。 第二个，业务的配置，业务配置其实有各种属性，或者是相关的一些内容，可以看到它是个标签化，纯业务化的业务人员开发的，这两部分实践分别落在了我们某一个产品里，移动平台里以及某一个甲方里做的一个业务中台，它面向的是一个业务人员使用的开发平台，或者是中台体系去做的，这个是我们认为是未来大众化开发的一个很核心理念。

其实在微软整个Power APP的体现里，右侧里会提到了一个两种开发人员做，他会提到一个概念DevOps，回到我们对这个东西的一个理解，因为未来我们会去基于任何时间、任何点都能接入的情况下，无需进入甲方场地的情况下去有被控制的使用，相关的开发能力，或者远程使用开发能力。

它是个集中的、统一、动态的授鉴权的一个远程开发为基础的。为什么这么说？就是说我们会发现如果我们开了VPN，我们其实是对用户或者对于一个开发者开放了所有权限。如果是我给它开放了一个root密码，我不可能为它去把root密码修改掉，而集中的管理其实是确实可以做这件事情。

我们直接来看，其实未来可能会有一个承载体去承接相关的统一授鉴权的这一套体系里，对于云的厂商，对于云的IaaS层的管理，他可能在云的一个平台里去做，但是PaaS业务层的这种访问是谁会在承接呢？未来是在中台去做的。中台哪部分？可能会在一些有单独的授鉴权，也可能是一个DevOps，因为很多甲方那边是很难有一个很好的载体，DevOps却是一个很好的载体。

从我们直接角度来讲，我们会把软件研发协作平台也作为一个中台化的一个重要支撑。它支撑未来能够授鉴权的动态化的一个很核心的基础支撑。

总结回来看，我们认为未来面向后疫情时代的一个场景是什么样的？

首先我们可以允许开发人员在不同场合下去使用相关的资源、服务以及开发环境，而这些授鉴权是可以动态的去授鉴权的，而不是开放了root权限用户名密码方式。

第二部分，未来的架构一定不是基于裸的API这种方式去做的，一定会有一个更复杂的类似于MASA这种架构的支撑。它是一个粘合的一种方式，集成的方式做。我们中台有一部分功能是承接这一部分能力的，这是我们认为第二个观点。

第三个观点，面向未来的三种开发人员，大众开发人员往往是被忽略的人群，未来会形成一种全民化的IT承建的时候，它其实是整个中台发展的一个重要的核心的趋势，这也是为什么现在有很多做这一类平台的会被高估值的原因。

最后，我们认为会有一个相关的体系去把相关的概念粘合在一起。未来可能会有更多新的概念或者新的一个合理架构去承接，但是从现在看可能DevOps是一个很不错的载体。希望我们未来的中台能够让我们一起去预见未来！

这个分享是基于从2020年初的一个疫情之后，我们作为一个技术产品公司的一种思考。 从我们分析角度来讲，我今天会从三个维度进行阐述： 第一个维度，从宏观角度来讲，整个社会的运转方式在潜移默化的发生一些变化。 第二个维度，我们对IT从业人员或者程序员工作方式的一种思考以及现状的一种延伸。 第三个维度，基于现状，对我们产品研发工作的一些思考以及趋势的一种展望。 1、疫情加速转变社会运转方式 首先可以用简单的数字来看一下美国在线的零售业。美国在线的零售业其实是很有意思的事情：在疫情之前，美国在线或者说网商、电商数据较差，直到2020年疫情的发生，有了一定上升。从这个角度来讲，所有的社会运转可以看到潜移默化的变化。 同样国内的在线教育付费用户，也发生了一些变化，预计到2020年可能在2.6亿人次。这体现了在疫情情况下，大家对在线教育的从不认可到认可，也隐含了社会的运转方式在变。 2、程序员的工作方式正在面临转变 对于我们程序员，在这个社会里难免会遇到各种随着时代变化的转变。从这个角度去看一些现象：疫情期间，程序员的工作方式也发生了一些变化。众所周知，在疫情期间，尤其美国那边，很多人无法回到自己的办公地点。据某一个科技媒体报道，微软已经允许每周有半数的时间在家自由的办公，如果经过主管的批准，可以永久在家办公。同样Facebook也在发生变化，Facebook的首席执行官预测在5~10年内，Facebook的人员可能有半数以上的在家办公。 这就引发的我们的一个思考。传统的方式回到办公室，办公室里会给你创造各种优良的环境，提供各种舒适的环境，甚至可以带你宠物上班，这种方式都是让大家聚焦在办公环境去办公。而现在我们面临的是在家办公，整个IT的建设和程序员的工作方式到底发生什么变化呢？这个其实可能会在未来一段时间内形成一个深远的影响。 作为一个供应商，我们反思了一下疫情期间我们面临的情况。在疫情期间，我们甲方的IT系统由于人员不到位情况下，IT建设是停滞的，甚至包括一些新项目的采购。因为疫情的控制，最核心的本质是说大概在2、3、4月份左右，其实供应商是很难入场的。 对于供应商本身角度来讲，遇到的问题是什么？我们现在无法入场，导致没有收入，成本和现金压力都非常大。比较幸运的是说在中国较好的疫情控制下，供应商也都顺利的进入场地了。这里面就有一个隐含的反思，我们是解决好了在疫情这种远程办公情况下的，供应商和甲方的一个合作模式？还是说现在因为疫情控制住了，问题不存在了？ 问题不存在了，但是问题并不是因为真正解决了而不存在的。这个就开始反思我们到底整个IT建设会何去何从？那么我在思考这个问题的时候会想到：其实整个社会在进行数字化，而我们的工作，我们程序员的工作是不是真的数字化了呢？ 回到我们这一个核心的主题，我们认为数字化其实有一个很核心的方向。福布斯在9月21日发布了一个2021年的十大数字化转型趋势。每年都会发布，我每年都会去看。我惊奇的发现了一个点：work from home。从疫情之后，可能在家办公远比疫情还要持久，简单点说疫情会改变我们整个的工作模式。这个模式的变化会导致的一个问题：疫情之后仍然会在家办公，或者是远程办公将成为一个主流。 这个趋势是如何改变我们的IT建设？ 我个人认为程序员也在迎来一个数字化时代。现在绝大多数情况工作环境是IT信息化的时代，我们有时候会有Jira、有Git等去建一些编译系统。其实本质来讲，传统行业也会有自己的信息化，其实是在做我们程序员工作或者是IT工程师的一个信息化工作，而未来我相信一定会趋向于一个数字化时代。 数字化时代，相对于传统的信息化时代，大家有很多争论说区别在哪里？从我核心的角度来讲，数字化是改变的一个行为模式，而不是简单的把工作信息化掉这个过程。为什么这么说？我们传统理解说我需要一个版本管理，需要搭一个Git，Git可能需要一个账号，我需要注册一个账号，这只是把我们的工作变成了一个信息化工作，未来可能会融入一体的进行数字化改变。 这里面首先我要去重申一下，我们的认知的一个变化。我在产品预研的过程中，包括对一些友商的竞争产品的了解以及未来趋势的了解，我会发现有很多认知是在打破我十几、二十年老程序员的一个理解。 比如最典型的在Linux下你去使用一个root权限，我们传统认知里是需要知道root的一个用户名密码，否则我是无法工作的。 第二个问题就是说，既然我们程序员经常会用到一些代码提交，那代码提交，我们现在最早用CVS、SVN，现在变成了Git，对于我来讲，我肯定会被分配一个Git账号和密码，这是我专属的。 这两个问题在未来的数字化时代的时候，这种方式是否合理？是不是必须？从我的分析看答案是不必须的。我举两个例子，第一个：我们在试用一些云化的产品的时候，比如说Google cloud，Google cloud默认其实是不提供root的密码的，这里面就是说我如何去使用 root权限去做？其实root的权限只是一种服务，当我去使用一个需要root的时候，我仅需要去作为一个sudo这种方式去做，不需要用密码，然后就可以获取到相关的权限，只要在我的账号体系里或者认证体系里，我是被认证成可以使用root的，这里面有一个问题就是说这个账号的密码是什么呢？ 其实是有平台提供的，我去尝试一下是否可以在Google cloud上去使用root密码的登录？答案是可以的，但是非常繁琐，我需要开通很多东西才可以使用，这里面其实就是说在未来的默认的很多方式里，我可能只是需要，我有权限使用 root这个服务，而不是说我需要这个用户和密码。 同样我们有很多人在使用一些小程序开发，小程序开发的时候，其实有对应的代码提交和版本，我们可以看到，我会去下一个小程序开发工具，我在整个过程中我会有版本管理的概念，但是我根本就没有对应的Git的一个账号和密码，甚至我都可以理解为我看了结构，我才知道它是Git，而实际上它不需要任何的Git的相关知识。 未来的数字化里很多对于系统的边界会被模糊掉，而对于所有的系统的提供的服务，会以一个以我们程序员为中心的这种使用习惯的转变而转变，这也将是会对我们整个理解的一些变化。 我们也会发现一些开发环境或者是习惯上的一些变化。因为在这个过程中，我们已经不是单纯的面向于一些我们的JVM（一些函数）去编程，我们可能面向大量的服务，甚至是说传统的，包括老的一些服务，这个过程中其实是未来是会基于大量的基础服务或者运转的，甚至连root权限，我就认为是一种可被使用的一个服务。 3、面向中台的开发或许成为一种趋势 未来的数字化时代、IT建设其实不仅限于一个单纯的用户体验和服务基础，这个是Gartner一个理解。Gartner建议是企业去建立一个网格化的应用和一个服务架构，以实现全局和面向未来的规划和管理。 说的比较罗嗦，整个架构其实可以看到它其实是多用户体验的，以及一个API怎么翻译？其实是一个（API）集成的一种方式，而对应的后端的service其实是多种多样的，它可以有传统的一些方式，也可能会有一些SaaS的服务，甚至是说一些微服务的架构，这都可能会存在。 当然跟这个东西在国内不是特别的流行，从我们直接角度来讲，我们认为国内和国外的环境不是完全相同，也就是说为什么我们会把中台提出来，而不是说MASA这种模式去提出来，我们技术从理念角度来讲可能会去参考一些，但是实践角度来讲，我会发现在国外的一个体系里，其实传统的立柱架构比较严重，甚至可能有七八十年代，或者是八九十年代的一些东西来做，可能大家都也见过新闻，有些系统要召回老程序员去进行改造，但是对于国内其实建设是一个滚动的、持续版本迭代的一种替换式的一个更新，也就是说未来三五年内，或者5年内，或者远的说是十年内有些架构会彻底重新进行做，这些东西其实就会变得一个架构的更合理度上，是更容易去做一些架构的话。 我们认为数字中台，我们整个大的主题里也会提到，数字中台其实跟MASA这种模型其实是异曲同工，而且我们从国内的趋势看，其实中台化的架构演进是一种趋势。当然这里面中台其实大家有各种争论，以最早的阿里系的这种说法，以及包括腾讯系，腾讯会把内容中台作为一个呈现，它其实是一个业务领域的中台，但是我觉着这个东西是会随着认知去发生一些变化的。 基于这个角度来讲上，从现在看未来可能会延续的去发展，现在架构来讲，在普元的这个体系里是一个薄前台，一个厚中台以及一个稳定的后台去做一些呈现。 仔细去看的话，其实跟MASA这个模型其实有异曲同工之处，不同点其实在于MASA这个模型，其实中台是一个更像一个API的快速编排集成，而普元的中台其实是需要一个标准化，甚至有一些分各种领域，数据中台，业务中台，甚至是一些技术中台的承接，它是一个厚平台的理念。 从我们直接角度来讲，这个可能是符合国内IT建设的一种趋势，当然大家也知道IT本身是一个螺旋式上升，未来可能随着时代的发展，可能在三五年内版本不断迭代，可能会有新的特性，一些理念进入，这都是有可能的。 从这个角度来讲，我们去看这件事情，这是一个技术架构上的一个变化，就是说传统的，我们仔细去看一下，其实这里面没有去过多提我们普元经常会提到的微服务架构的一些说法，因为其实架构只是中台理念的一种实践模型，而这个其实是一个没有过多去涉及到的东西（技术细节的实现）。 数字化时代，其实我认为IT的诉求会爆发，然后会推动一个技术的全民化。这个词其实国内很多技术人员分享就叫做技术的民主化，但这个词从我个人角度来讲，我觉得国内不是特别恰当的使用。我们认为未来的IT会分为三大类用户使用，第一个是大众开发者，第二部分是IT或者IT业务人员开发者，第三部分是专业的开发人员。 我相信现在能看到这个视频绝大多数是专业的开发人员和IT开发人员，比如说未来我们会去分享一些，或者是在之前我们已经听到过的我们顾主任的一个分享，他可能是站在一个技术中台，如何去做技术人员分享，这个部分是专业的一个开发人员，他会用专业的工具去解决专业的问题。 对于我们认识最少的一部分其实是大众的开发人员，这也是数字化转型而带来的一个点，这些人员可能是对于业务非常熟悉，对于技术可能就是一个小白。对于这个解决方案来讲，其实它恰恰是在数字化时代里更多承接的一些人群。 我会从几个维度去看，第一个其实技术全民化在不同厂商的理解是不完全相同的。这一部分其实是Power APP，微软的一个产品体系的理解，它基本上把他所有东西都依赖于一个它的service，它的云上的一个service，基于这个把用户分成了一个，你可以理解为全民的developer和一个专业的developer，我觉得这个东西不是特别恰当一个原因是说它把云作为一个基础，说认为所有的云的服务不用你再去承接了。 但对于国内的一些架构体系里，其实私有云或者一些其他的基础能力，其实是需要甲方去进行采购，去建设，而这一部分其实恰恰是更专业的人群在做。比如说像普元这种公司在承接，或者其他的合作伙伴、友商在承接，这个其实是绝大多数云厂商在做的一个方案就是说我不希望让你看到对于IaaS、PaaS层的一个承建，你看到的就是一个广泛的开发者以及部分的人员可能会解决不了的一个问题。 但对于我们的理解里，专业的开发人员是中台的缔造者和技术中台的使用者。我这里面有两个概念，第一个就是中台的缔造者，因为无论怎样中台都会是有人在承建的，无论是甲方自行承建，还是普元这种中台厂商去承建。 其实中台的技术平台部分有大量的一个扩展性的工作，这一部分其实放出去其实是一个，对于一般的IT从业人员，比如说纯业务开发的一些供应商，甚至说一些广泛的一些业务人员，其实使用是很难使用的。 所以从这一点角度来讲，我们认为业务开发人员去面对的是这么一个场景，中台的专业人员他会屏蔽到一个基础环境，也会把中台做成标准化，端到端，柔性的，当然有一部分业务人员会直接去使用技术的特性，有一部分的扩展能力却是专业人员来承接的，这也是我们普元最核心的定位之一。 我们的IT从业人员或者业务开发人员是基于业务中台进行快速的创新的，这里面就有一个隐含的主题，业务中台是谁建设的？在我们整个理念里，首先是有专业开发人员和IT人员去统一建设去完成的，为什么这么说？ 其实业务的理解其实不是一个技术单纯这么理解的，所以从这个角度来讲，我们可能会有更多的中台，比如产品中台、渠道中台、运营中台、营销中台。甚至可能细分到业务领域，比如说像腾讯信息平台的内容中台，内容是它的核心。比如说由不同厂商提供了不同的中台，我认为专业（业务）人员的开发是基于一个业务的开发。那么这一部分其实我们一般理解来讲，它应该是统一的开发工具，他可能基于VS code做了一个二次开发的工具，它也可能将来走上一个web端的开发工具，但他都是一个相对于偏开发的人员，当然少量的会用一些低代码的一个方式去做。 第三部分，重点去阐述大众型的开发人员，他会基于一个web端的开发，对于这个角度来讲，我认为他未来会结合着人工智能驱动的一个低代码的，配置化的平台支撑。 为什么这么说？因为未来如果你中台化以后，你大量的开发人员使用的习惯形成，就会在中台被沉淀，他也有可能去做一些工作，这里面我们会提到了几个概念： 第一个，可以移动端通过一个很简单的配置，能把一个APP进行开发出来。 第二个，业务的配置，业务配置其实有各种属性，或者是相关的一些内容，可以看到它是个标签化，纯业务化的业务人员开发的，这两部分实践分别落在了我们某一个产品里，移动平台里以及某一个甲方里做的一个业务中台，它面向的是一个业务人员使用的开发平台，或者是中台体系去做的，这个是我们认为是未来大众化开发的一个很核心理念。 其实在微软整个Power APP的体现里，右侧里会提到了一个两种开发人员做，他会提到一个概念DevOps，回到我们对这个东西的一个理解，因为未来我们会去基于任何时间、任何点都能接入的情况下，无需进入甲方场地的情况下去有被控制的使用，相关的开发能力，或者远程使用开发能力。 它是个集中的、统一、动态的授鉴权的一个远程开发为基础的。为什么这么说？就是说我们会发现如果我们开了VPN，我们其实是对用户或者对于一个开发者开放了所有权限。如果是我给它开放了一个root密码，我不可能为它去把root密码修改掉，而集中的管理其实是确实可以做这件事情。 我们直接来看，其实未来可能会有一个承载体去承接相关的统一授鉴权的这一套体系里，对于云的厂商，对于云的IaaS层的管理，他可能在云的一个平台里去做，但是PaaS业务层的这种访问是谁会在承接呢？未来是在中台去做的。中台哪部分？可能会在一些有单独的授鉴权，也可能是一个DevOps，因为很多甲方那边是很难有一个很好的载体，DevOps却是一个很好的载体。 从我们直接角度来讲，我们会把软件研发协作平台也作为一个中台化的一个重要支撑。它支撑未来能够授鉴权的动态化的一个很核心的基础支撑。 总结回来看，我们认为未来面向后疫情时代的一个场景是什么样的？ 首先我们可以允许开发人员在不同场合下去使用相关的资源、服务以及开发环境，而这些授鉴权是可以动态的去授鉴权的，而不是开放了root权限用户名密码方式。 第二部分，未来的架构一定不是基于裸的API这种方式去做的，一定会有一个更复杂的类似于MASA这种架构的支撑。它是一个粘合的一种方式，集成的方式做。我们中台有一部分功能是承接这一部分能力的，这是我们认为第二个观点。 第三个观点，面向未来的三种开发人员，大众开发人员往往是被忽略的人群，未来会形成一种全民化的IT承建的时候，它其实是整个中台发展的一个重要的核心的趋势，这也是为什么现在有很多做这一类平台的会被高估值的原因。 最后，我们认为会有一个相关的体系去把相关的概念粘合在一起。未来可能会有更多新的概念或者新的一个合理架构去承接，但是从现在看可能DevOps是一个很不错的载体。希望我们未来的中台能够让我们一起去预见未来！