中台概念的提出
随着数字化转型不断深入，企业面临着严重的数据割裂、系统隔离等问题。在这样的背景下，“敏捷响应，低成本地快速创新”成为了推动一站式商业智能软件的内在诉求。
阿里于15年提出中台架构概念，抓住了企业数字化转型的核心诉求，即“敏捷响应，低成本快速创新”。然而，阿里作为一家生态公司，在16年时基本上是带着合作伙伴来给企业交付，但由于伙伴对互联网技术的理解和能力的限制，基本上都做得不好，甚至失败。
中台落地遇到的三大问题
在2017年，阿里成立了原生交付团队，希望能够树立一些标杆案例。我和公司的核心成员也都来自于这个团队。在做完几个客户后，我发现阿里也做不好，但这次做不好的原因不是技术不行或项目上不了线，而是上线以后预期的效果没有达到，其本质是企业的IT组织能力无法驾驭复杂的互联网中台架构。当无法驾驭的时候，所谓的目标“敏捷响应，快速创新”就无从说起了。结果客户会反馈以下三类问题:
1.不是说敏捷响应吗?为什么改个需求这么慢，不但时间更长，付出的成本也更高了?
是因为中台架构需要一定的技术能力和经验才能有效地应用，就像一个只会骑自行车的人给他一辆汽车或者飞机，他也不能驾驭它们，更不用说是手动挡的。
2.不是说能力中心吗?当引入新供应商或有新场景开发的时候，为什么前期做的能力中心不能支撑了?
是因为能力中心是一种面向业务的能力组织方式，它将不同的业务能力抽象出来，以服务的形式对内提供。然而，由于业务场景的差异，不同的业务需要的能力也会不同，因此能力中心需要不断迭代和升级。对于新引入的供应商或新场景开发，需要根据实际情况对能力中心进行定制化和扩展化，但谁来负责呢?新项目的供应商还是客户自己?
3.不是说性能好吗?为什么我投入的物理资源更多了?
是因为中台架构采用微服务来解决单点瓶颈问题，提高系统性能和可用性，但是在初始阶段，投入的资源可能会更多。每个块至少需要两个实例来保障高可用性，因此物理资源的投入量可能会比以前更多。
企业级数字化的两种演变方案
目前，企业数字化软件建立，主要有两种方案：
第一种是以自建研发团队为核心。
中国的大型企业已经开始尝试这种模式，看起来似乎是一个时下比较流行的可行性方案。然而，绝大多数企业由于成本、人才团队等原因而难以坚持下去，只能与供应商合作开发。
第二种是以供应商为核心。
由于大多数企业无法选择第一种路径，他们必须接受目前分散的情况，并通过系统集成尽可能拉通各个系统。尽管如此，在数字化时代中，真正意义上的一站式商业智能软件供应商还未出现。
对企业来说，这两种方案都非常艰难，但在大规模数字化历程中又不得不做出选择。此外，我们还能清晰看到以下几点:
1."敏捷响应，低成本地快速创新"成为企业推动一站式商业智能软件的内在诉求
2.目前没有一家软件供应商能满足企业所有外围商业场景，也不可能有这样的供应商
绝大部分企业需要软件供应商，而不是自建！
如何突破这种局面也成为中国软件行业发展的一个机遇。强化第一种路线只能服务于极少数头部企业，因此我们数式Oinone更希望优化第二种路线并形成全新的模式。
因此，我的思考是：
1.我们的目标不是让企业学会复杂的互联网架构，而是降低互联网架构的门槛，让更多企业真正拥有“敏捷响应，低成本快速创新”的能力。
2.我们的目标不是输出中台方法论，而是提供中台建设的技术平台
3.我们的目标不是只服务大企业，而是真正赋能不同IT组织能力的企业，让它们都具备持续创新的能力。
所以为了能够把我的技术思考转为现实，我19年创建了数式科技，凭借在互联网架构和大型企业软件服务领域十余年的深厚经验，加之五年专注的研发与实践测试， 打造了数式Oinone品牌（基于互联网架构的专注复杂场景的低代码平台，屏蔽了互联网架构带来的复杂性）
往期文章推荐
多层次深度对比，一文看清数式Oinone带来的效率提升-CSDN博客
软件公司在工程化领域都关注哪些特征？这些特征应与研发个体能力无关-CSDN博客
扫一扫
4546
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
