这个周末我去参加了2021年华南CIO大会，发现基本上每年大会都有一个热点，比如今年的热点就是低代码开发平台。
我们可以回顾下最近几年的热点变化。
- 17-18年：微服务
- 18-19年：中台
- 19-20年：RPA，数字化营销
- 20-21年：低代码，云原生
就我自己的文章输出来看，基本上也和这个大趋势符合。比如我17年左右会更多地写微服务架构设计和实施方面的文章，18，19年输出了不少关于中台建设的文章。而最近几年关注重心则是云原生整体解决方案和低代码开发平台。
在IT行业，各种新兴技术层出不穷，互联网大厂的各种造词能力也相当强大，也让每年基本都有新热点和新技术产生。
类似19年可能刚兴起低代码开发，而到了今年可以看到做低代码平台的各种厂商，不论是做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，项目管理，运维管理等偏工单和流程类的业务系统构建在低代码开发平台上，积累相关的实践和应用经验。
最后就是低代码开发平台在选择的时候要考虑不要被平台厂商绑架的情况，任何低代码开发平台开发完成的应用一个基本要求就是能够脱离低代码平台运行，并具备足够的高可用和扩展性要求。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。