一个成功的IT企业的发展路径一般是这样的。架构是问题的沉淀和升华，它具有较强的通用性，一旦完成解决的不仅仅是当前的问题。
1，做了某个业务，成功
2，流量增加，高并发，分布式，大数据等问题需要解决，需要技术架构
3，产品线和功能更加丰富，复杂度越来越高，业务软件越来越看不懂，开发效率越来越低下，需要业务架构
我们来看阿里的例子。技术架构能力沉淀到极致便有了阿里云，这是她能向各行各业输出自己底层技术能力的前提。但，挟阿里云成功之余威阿里不满足于此。她想：业务能不能也适用这个模式呢？也许不存在一个对所有业务的通用业务架构；但是在某个细分领域，存在一个较为通用的业务架构。
从2008年左右开始，阿里云一直在尝试打入各个细分市场，提供行业解决方案。2016年，阿里推出了引起业界瞩目的“阿里云产品全向图”，算是对多年来努力的一个总结。在这幅“全向图”里，多达121款阿里云产品几乎涵盖了所有行业。阿里云不但在电商、音视频、物联网、金融、O2O、政务等各个行业推出了个性化的解决方案。到2018年，阿里云又推出针对医疗行业的智慧医疗数字影响解决方案、以及针对房地产行业的数字化解决方案。
事实上，如此自上而下、贯通各行各业、全面提供解决方案的策略效果并不好。一方面，阿里必须耗费海量资源去做到“全知全能”，企图对所有细分领域里的业务实践进行巨细无靡的掌握，其结果则是产品矩阵庞杂，成本高而效率低。
2015年，阿里制定了一个3年的中台计划。以提升效率越来越低下的软件研发。
2018年，悄无声息，一向高调的阿里既没有宣布中台成功，也没有宣布中台失败，而是宣布中台战略将继续执行。
2019年，经过几个月的讨论，阿里智能总裁行癫宣布：阿里云要做被集成，不做SAAS。将行业市场交给合作伙伴；中台要聚焦于云。
在某种程度上，这是一种中台战略的“转进”。其中意味，耐人寻味。这可能是阿里战略上的第二次滑铁卢。第一次是进军社交。
那么业务架构难在哪里？难在复杂性、变化性。SaaS行业是一个很标准的VUCA市场。
对于软件本身而言，它并不区分自己表达的问题什么技术问题或者业务问题，这些不过是人类主观上的划分而已，对它而言都是概念和概念之间的关系，在表达上并不会有什么差异。从这个角度来看，既然大部分中间件类软件的质量是良好的；那么大部分业务类软件的质量也应该是良好的。
但，现实是完全相反的。这是由于两种结构上不同的问题域的性质导致的。技术域问题大多数有限集，结果是开放集；业务类问题很多是开放集，结果是指定集。技术问题难么？难！
但是技术问题，不外是计算机领域内的问题，可能包括CPU，内存，存储器，网络；或者构筑其上的更高层的组件，进程、数据结构；操作系统，中间件……它的问题集终究是个有限集；它的变化是较为缓慢的。花费一些时间，还是能摸清它的问题域的。
它可以看清楚问题的全貌的。
业务问题，它的难度不同，它面对的是现实世界，什么可能都有。
一些领域比计算机领域还要繁杂的多；一些领域甚至不一定能找到它的边界在哪儿；一些领域，它是频繁变化的。并且每一个领域可能都不一样。很多领域，也许穷其一生，你连问题域是什么都没搞清楚。技术类的大多数问题，你解决了，解决方案可以不限定形式，你觉得什么形式最好就采用什么形式。程序员可以选择用还是不用，这是结果是开放集。业务类的大多数问题，你解决了，发现结果形式和要求的不一样，如果要求方是客户，并且这就是客户的既有业务，即使它不合理，是客户改还是你改，你要掂量掂量。这是结果是指定集。
技术架构是随意发挥是蜀道难，业务架构是命题作文是七步诗。不论是什么，是难还是复杂，是优雅还是不优雅，评判架构好坏的永远是好用不好用。软件架构的评委是谁？技术架构的是开发，测试，运维。业务架构还要加上产品，运营。
为什么需要产品，运营？业务架构的最高目的是快速响应业务，最快的当然是让拍脑袋的产品或者运营们在控制台上配置配置就好了。IBM很久以前为银行客户提出了产品工厂和流程工厂的概念。当然这个概念最后黄了——不黄就没支付宝什么事了现在阿里也提出了类似的概念：中台，来解决自己陷入的效率低下现状——这曾经是2年前它极为不屑的银行们的状态——可惜也转进了。这也说明业务架构这个事极难。
从这个角度上来看，阿里的中台战略不合适SaaS开放生态、更像是一个封闭的电商系统。
