关于软件架构的一些反思

我最近看了一个纪录片《无节制消费的元凶》。其中，生产厂商在产品设计和生产过程中，本身就会设计大量的生产缺陷，即计划报废期，从而导致消费者不断地购买，避免有些人的“一劳永逸”。

我在想软件设计中是否也存在这样的缺陷设计，从而使客户不断地为其服务买单。常见的一种方法是根据用户数量、业务规模来设计软件，推出所谓的SAAS化。但这些从真实意图来看，都是表面的，或者应用层的。

中国具有全球最完善的供应链体系，拥有最庞大的业务场景和应用数据。这是很大的特点，绝无仅有，因此诞生了很多互联网公司。但是真正的软件公司，却乏善可陈。很多软件公司都是以项目定制为主，便是所谓的“解决方案”。软件的生命周期便是项目的生命周期，因此，很多公司的信息化建设都是随着项目一次又一次地推倒重来，就好像种地，还没有长出果实了，结果又翻新了一遍。当然，国内的很多软件厂商，也得益于此。这种“计划报废期”并非来自于软件厂商精湛的软件设计和开发能力，而是来源于生产企业的对信息化智能化这些新一代技术的错误认识。

对于中国的软件厂商，我并不确定是否有厂商真正地把软件架构这东西研究明白。是否能像SAP那样随着业务和规模的变化而不断完善更新。曾经有一个非常有意思的故事，说德国某地的下水道工程，几百年了，仍然运行正常。真正的软件工程也是一个如此的非常庞杂的系统工程和项目工程，而不单单是功能性的，实现某些功能而已。这种单单满足功能需求而开发的，不能称之为“产品”，存在巨大的应用性风险、可靠性风险和安全风险。我觉得这是TO G/B 软件项目交付，甲方经常抱怨“用不起来”的关键因素。

为什么iPhone、打印机这类硬件产品会设计计划报废期，从而促进客户反复不断消费，而在软件工程领域却缺乏这样的设置，关键还是无法把握软件架构。肯定不是市面上常见的IaaS、PaaS、SaaS三层工业互联网应用架构。我认识很多架构师，也面试过一些架构师。我觉得他们大多都不具备真正的架构能力，只是有此头衔的“高级开发工程师”。软件架构这条路还是路漫漫，需要更多同道之人，上下求索。