中台和微服务规划
对于中台规划实际上可以理解为传统企业架构和信息化规划，传统SOA架构规划的一个子集。其核心还是业务驱动IT，基于业务流程和业务对象梳理分析，识别核心可复用的业务组件和能力。共性业务能力下沉，提供粗粒度接口给上层使用。
中台本身是一个业务概念，而非技术概念。
能做中台规划的不是技术很牛的新兴咨询公司或软件服务商，而是传统的扎根在某个垂直业务领域的传统咨询公司或软件服务商。即对垂直行业业务理解的深度，传统的咨询规划能力，远远超过技术能力。
一个新兴的企业到处去给客户做中台规划，这个是不合适的，没有业务领域的沉淀你如何给别人规划中台，如何识别可重用的业务能力。你没有业务积累和沉淀，再好的方法论也无法指导你实践。虽然我文章里面整理中台规划方法论，同样我不熟悉的业务领域我实际也无法给别人做规划。
熟悉一个技术架构思想可能需要1周时间，但是熟悉一个垂直行业至少需要1年甚至更久。所以做技术规划相对容易，但是做业务和中台规划难，其难点不在于方法论，而在于业务积累和沉淀。
微服务-不要将标准僵化
实际上我们在进行微服务架构转型，包括和客户讨论微服务化的过程中往往出现两个极端。一种情况是大应用应用层拆分了，但是数据库还是一个;还有一种情况是严格地去做到拆分的微服务和数据库1对1。
对于第一种情况由于DB没有拆分，实际上仍然是一个紧耦合的系统。而第二种情况微服务拆分后导致大量独立细粒度的数据库实例，进而带来大量的分布式事务问题。而实际上更好的做法应该是根据企业业务域的情况进行折中，按业务子域来进行数据库拆分，而业务子域内部的应用层，还可以拆分为多个微服务。
包括在微服务实施中，经常有人会说你的架构前后端没有分离，不是微服务。而实际上前后端分离同样不是微服务的必要条件。
比如有些客户在实施微服务的时候，虽然前后端分离，但是后端提供的API接口服务全部都是细粒度的，同时和前端方法1对1，这样的前后端分离拆分并没有体现领域能力，服务可复用等关键特性，反而是增加了前后端协同和联调的复杂度，这样的分离没有意义。
DevOps首先是过程，其次才是工具集成
对于DevOps，虽然在我前面文章也详细说明了当前的我们规划和研发的DevOps支撑平台。但是所有人还是要意识到DevOps首先是过程改进和优化，其次才是工具集成和自动化。
比如我们看到一些企业实施了CI/CD集成，过程自动化等，但是你会发现从用户需求收集到版本规划，到最终的开发实现和上线，整个过程管理还是很混乱，有了工具仍然出现需求，研发，测试人员大量的人工沟通和协同。那么DevOps实施的意义何在?
因此，对于DevOps首先是一种敏捷和持续集成和交付过程的改进，其次才是使用什么样的工具和技术。技术往往很难反推过程优化和改进，过程改进需要的是组织，团队和文化的改进。
大数据平台到数据中台
可以看到，当前很多做数据中台的服务商实际就是原来做大数据平台的服务商。那么大数据平台和数据中台究竟有什么样的区别?
对于大数据平台你可以理解为一个纯粹的数据技术能力平台，里面本身是空的。就像我们理解ESB总线一样，本身是一个技术平台，一开始没有接口服务注册在上面，需要你自己不断地接入新的服务，才能够形成服务目录体系。
而对于数据中台则是基于一个大数据平台的技术底座填充了具体的数据资产，这个数据资产需要进行分层，需要进行抽象建模，需要对外提供可复用数据服务能力。
因此数据中台建设难点从来不在大数据技术平台，而在于里面的数据建设，如何对数据进行建模，如何采集数据，如何清洗数据，如何抽象聚合等。而这个同样又回到了中台规划的关键，即需要业务域业务能力和经验沉淀，你才能够做这个事情。
简单来说如果企业要做数据中台，新兴的很多大数据平台或数据中台厂商不一定靠谱，反而是哪些传统的垂直领域长期做BI规划实施的厂商更值得托付。
从云原生到企业上云迁移
我在前面谈到过，对于阿里，华为和腾讯等公有云厂商，2020年在云原生解决方案，协助传统企业上云上宣传得很猛，虽然整个云原生是技术大趋势，但是企业一定要意识到从传统的企业内部IT架构迁移上云仍然是一个相对漫长的过程。
特别是企业已有内部私有云或数据中心，已经有大量遗留IT系统的情况下，在业务连续性保障，如何确保平滑迁移难度极大。
各个公有云厂商都推出自己的迁移方案和计划，包括自己的DevOps研发一体化平台延伸到企业内部，虽然易用性和方便性在增强，但是对企业的强绑定也在增强。简单来说你采用了某个公有云服务商的方案和服务，实际后面你要脱离是相对困难的事情。
其次，前段时间做了下简单的比较，即不直接购买虚拟机而是直接购买数据库服务，发现整体每年的成本相对高。有时候考虑直接购买云服务厂商的技术服务能力，但是实际上很多时候你仍然需要有运维工程人员，这个成本并没有省略掉。
同时由于企业IT系统是逐步迁移的，企业内部私有云和公有云将并存相对长一段时间，包括有些传统的内部IT系统在性能需求，安全性等方面往往并不适合上云，这些都必须考虑清楚。
服务治理和管控能力
有些企业盲目地崇拜新技术，总希望自己在新系统的开发中采用最新的技术，最高性能的技术。但是实际上在后期管控运维上都出现了问题。
对于微服务而言也一样，刚开发的微服务拆分，接口定义并没有马上发现问题，但是最终到了开发后期乃至上线的时候才发现微服务拆分的太细，微服务间的接口交互太多。也就是说微服务拆分后，各个微服务间仍然是紧耦合状态。
系统一上线，发现整个微服务环境完全不在自己的掌控范围，运行故障问题难解决，日志难以排查，接口变更大量依赖导致上线故障等。这些都是典型的整个IT组织的架构能力，服务管控治理能力跟不上导致的，刚开始用新技术很爽结果到后面留一个无法管控的烂摊子下来。
中台和微服务
对于中台构建一定要采用微服务架构吗?
在前面文章也谈到过，理想化的中台构建采用微服务架构是最佳的方式。但是中台的核心是共性业务能力下沉并对外提供，能够支撑上层应用快速构建。
那么企业存在大量遗留IT系统的时候，全部推翻原来的微服务化就不是最佳的方法。更好的方法是围绕你构建的中台是否提供可复用的共性业务能力为最终衡量标准。如果做到了，企业就构建了很好的中台。底层是否使用微服务反而不是关键点。
因此中台和微服务虽然紧密结合，但是实际上没有必然关系。
中台的构建可以不采用微服务，可以采用传统架构，也可以通过对遗留IT系统接口适配的方式来构建。而对于微服务同样不一定体现中台特征，微服务核心仍然是在于传统大单体的拆分，拆分后的接口服务可重用性是充分条件而非必要条件。
不要神化低代码开发平台
重新回归下在2020年技术发展，发现低代码开发平台反而是一个热点中的热点，出现了大量的低代码开发平台的厂家和云服务商。有些是传统的做BPM类的厂家，也有些是本身就是做快速开发平台的厂家，当然还有些完全提供零代码组装的平台。
没有银弹说了这么多年，这个短期不会有大改观。
那么低代码平台本身的尴尬点在哪里?
对于中小型企业来说，需要的并不是低代码开发，而是直接的SaaS服务，对于SaaS服务产品能够提供一些灵活的流程，权限，数据项的配置能力足够。而对于大型的企业来讲，很多业务流程和业务场景，特别是复杂的业务规则，低代码平台并不能解决。即使解决仍然存在大量的复杂脚本代码。
低代码平台假设了每个对象，每个功能相对来说都尽量独立，但是实际上对于复杂的业务来说对象之间有关联，功能之间有协同和集成，业务逻辑难配置等。这些不是低代码平台能够解决的问题。
如果真要做低代码开发平台，你会看到唯一好的方向是垂直业务行业+业务系统。越做到垂直，越容易将可复用的东西抽象出来提供。也就是说实际是提供了一个垂直行业+垂直业务下的一个业务平台能力，这个才是最有价值的。
