转载本文请联系悦潮IT公众号。这个周末去参加了2021华南CIO大会，发现基本上每年的大会都有一个热点。比如今年的热点就是低代码开发平台。我们可以回顾一下这几年的热点变化。17-18岁：微服务18-19岁：中国台湾19-20岁：RPA、数字营销20-21岁：低代码、云原生从我自己文章的输出来看，基本符合这个大趋势.比如2017年左右我会多写一些微服务架构设计与实现的文章，2018年和2019年输出很多中台建设的文章。近几年主要关注云原生整体解决方案和低代码开发平台。在IT行业，各种新兴技术层出不穷，各大互联网公司的各种造词能力也相当强，这基本上导致每年都有新热点、新技术出现。类似于2019年可能刚刚兴起的低代码开发，而今年，你可以看到各种低代码平台的厂商，无论是SaaS服务，还是传统的toB实现，还是围绕腾讯、钉钉生态。据估计，至少有100家公司在开发低代码产品。如此一来，整个低代码行业也处于竞争和混乱的局面。上半年，ThoughtsWork的徐浩写了一篇文章，把低代码平台说成是行业的毒瘤。首先，我个人不同意这种观点。任何新事物都有它的价值和道理，不可能解决你所有的问题。问题。相反，应该在正确的时间使用最合适的方法。低代码平台本身是个好东西，但是很多厂商都吹嘘说低代码平台无所不能。再复杂的系统和规则，都可以零代码拖拽实现。这根本不是关于武术的。所以，低代码平台不是行业的毒瘤，厂商竞争中的胡说八道、吹牛皮才是行业的毒瘤。回过头来看中泰的概念也是如此。中台本身就是一个很好的概念和想法。强调下沉企业通用的业务能力，进而形成可复用的业务能力中心，提供给上层应用，使上层应用的开发更加灵活、敏捷。这个想法本身并没有错。但是，很多中端厂商，尤其是很多互联网初创企业，一味夸大中台的作用，为企业图大局。如果一个中台是无所不能的，那么企业原有的IT系统也必须从头做起，构建庞大而全面的中台能力，而不是考虑如何保留企业遗留的IT资产。这些也导致大量中台项目的失败，或者根本没有达到预期的效果。这并不是因为中泰的想法不好，而是因为厂商夸张的宣传最终没有达到最终的效果和目的，导致用户大量的连续反弹。这不能怪用户，只能怪厂家。当我们回到微服务时也是如此。倒退3、5年，估计也有不少企业被微服务干掉了。原因也很简单。单个应用本身运行良好，但最终被拆分成20多个微服务，导致多个微服务之间集成复杂，分布式事务失控，后续排查困难，运维监控困难。等等一系列问题。这本身并不是错误的微服务理念，而是错误的应用。一是企业在IT治理和管控能力还没有达到一定水平的情况下，盲目使用微服务。另一种是架构建模前期对微服务的拆分不合理，导致拆分过小，或者微服务之间的拆分紧耦合。微服务思想本身不应该背这个锅。去年参加华南CIO大会的时候，RPA机器人一片狼藉。听说今年有一些RPA厂商或者团队解散了。那么RPA机器自动化好不好？同样，任何新事物的存在都有其存在的理由。RPA机器人与自动化技术的融合，解决了传统业务系统底层集成难的问题，将重复性工作自动化。这种思路没有错。一定有它的应用场景和应用价值。但要意识到RPA与其说是目标，不如说是一种妥协。你为什么这么说？如果甲方公司有能力做底层业务系统之间的数据集成和接口集成，但是你偷懒不自己做，你就通过上层RPA的思路解决问题。那么这是一种明显的治标不治本的方法。对于一棵大树来说，其底部的多根根须相互融合，相互交织，形成合力，支撑起顶部繁茂的枝叶。但是现在底层根部之间的融合已经不做了，都是在枝叶上拉绳子来系线。虽然这样可以暂时解决问题，但到头来这棵树的发育和成长会更加困难，哪天突然倒下也不是没有可能。所以当我重新思考这些热门概念时，我给出了一些关键的想法并将它们总结如下。微服务重申了一个原则，在没有明确要求的情况下，不要随意拆分微服务。即使用微服务开发框架，也不需要做大拆分。对于大部分企业来说，实际的业务并发还没有达到需要微服务来解决问题的地步。其次，应用扩展优先采用传统单体模式下的扩展方式，类似于集群扩展、数据库读写分离等，也可以通过子组织进行横向扩展。如果您的企业本身已经具备了一定的信息化建设基础，构建中台的最佳方式是梳理现有遗留IT系统中可复用的业务能力，基于SOA共享的思想构建业务服务中心。而不是构建一个新的中间平台。对于数据中台来说，如果没有细粒度的微服务拆分，数据反馈给业务的问题不需要数据中台解决，直接在业务中??台或者传统的遗留业务系统中解决。因此，传统企业搭建数据中台，并不是追求数据服务的打通和业务的反哺，而是整合后的数据分析和利用。思路可能还是传统的BI系统建设思路。RPA机器人技术和自动化是一种妥协，而不是RPA的目标。当企业面临众多遗留系统底层接口难以整合的场景时，可以使用RPA来解决重复性工作的自动协同问题。但在一定条件下，底层数据和接口集成仍然是主要关注点，而不是上层接口协同集成。不要把RPA越做越大，这个后期维护会出大问题。一是核心逻辑本身不清晰，二是底层业务系统本身也处于不稳定的变化状态。在低代码平台本身的行业标准规范出台之前，低代码开发平台还没有达到成熟度。企业不应将核心业务系统放在低代码开发平台上。低代码平台企业可以尝试在低代码开发平台上构建OA、项目管理、运维管理等部分工单和流程等业务系统，积累相关实践和应用经验。最后，在选择低代码开发平台时，要考虑不要被平台厂商绑架。低代码开发平台开发的任何应用程序的一个基本要求是能够脱离低代码平台运行，并具有足够的高可用性和可扩展性要求。
