本文作者作为软件行业 20 余年的从业老兵，对此问题有一些观点不吐不快，也由此发出了一个新的提问——SaaS 有可能成为中国软件行业的一枚解药吗？
首先，让我们重新审视文章中所提及的“软件行业”。“软件行业”的定义似乎太过宽泛，以至于容易让人忽视其中的细分与差异。实际上，公众热议的焦点，更多集中于我们常说的“传统软件行业”。这里的“传统”，也并非简单的时间划分，而是指向了那些业务主要围绕政府、金融、能源以及制造业等领域展开的企业。这些行业，作为中国经济的中坚力量，长期以来为软件服务市场提供了肥沃的土壤。然而，正是这些曾经风光无限的软件企业，渐渐地被贴上了“躺赚”、“靠关系”、“技术迭代缓慢”、“创新乏力”的标签，背后折射出的是整个行业转型升级的迫切性。
以金融行业为例，它曾是软件工程、业务建模、服务化等技术与理念的先行者，许多国内软件行业的创新实践先从金融行业积累了大量的实践经验，进而影响到其他行业，逐渐在国内流行起来。究其原因，金融行业在进行新一代核心系统建设时，大量引入 IBM、Oracle、SAP 等国际知名软件供应商，这些“洋师傅”不仅带来了先进的技术与系统，将成熟的管理经验和方法论引入国内，更在和本土软件企业的合作中言传身教，促进了本土软件企业的快速成长。
然而，互联网行业的异军突起，吸引了大量优秀人才离开传统行业，加上后来的去 IOE，国外厂商逐渐退出了金融行业。人才的流失加上缺少国际大厂的“领路”，本土软件企业在创新能力与技术迭代的速度明显慢了下来。另一方面，金融行业自身也开始强调“降本控费”，直接把压力传导到那些为他们提供大量数字化服务的软件企业身上。
那么，之前靠向国际大厂们的老师傅学习挣到钱，靠去 IOE 留下的空白市场挣到钱，这些红利逐渐消退以后，软件行业还有机会吗？
首先，互联网一枝独秀的时代已经一去不复返，之前把重心放在服务互联网行业的软件企业现在也越来越重视传统行业，给传统软件行业注入新的动力，也让互联网行业和传统软件行业的边界越来越模糊。以笔者接触到的一些企业为例，不少做风控、数据分析、infra（数据库、云原生等）的团队几年前就已经开始大量参与到金融、交通、政务等这些传统领域的业务中，取得了很不错的成绩。
有什么样的甲方，就有什么样的乙方。甲方有什么样的需求，就会倒逼乙方有什么样的能力。曾几何时，项目中标要靠白酒驱动，关系比方案更关键。然而，随着时代的不断进步，甲方越来越多的决策者比之前更懂数字化，他们既具备深厚的业务知识，又精通技术，更倾向于采用科学理性的评估标准选择合作伙伴。这种思维模式的转变，对乙方提出了更高的要求，也预示着纯粹依赖人脉和关系的模式逐渐式微，而那些真正潜心做产品做技术的企业也会得到越来越多的机会。
众所周知，SaaS 模式是因为抓住了2000年互联网泡沫的契机得到快速发展，经过十几年的发展，变成主流的软件商业模式。如今各行各业更关注降本增效，对做企业服务的软件行业来说，同样也是催生行业变革的机会。照搬美国式的 SaaS 并不适合大部分国内企业，那么我们自己的模式会在哪里呢？
SaaS 之所以在中国活的不好，流行的说法，最主要的原因是中国人不接受标准化软件这一套，越大的企业越不接受，个性化需求也越多。既然如此，我们就需要找到一些打法，给 SaaS 再增加一些外挂，使 SaaS 这种模式在多变的个性化需求面前也能游刃有余。笔者近十年一直从事 SaaS 相关的工作，摸索出一些心得，和大家讨论交流。
API 标准化。在 SaaS 上做定制，绕不开通过 API 把 SaaS 的能力开放。利用 API 进行二次开发的同学都有一个很深的体会，很大一部分开发量都消耗在API适配上。试想，如果每次定制开发都需要学习新的 API 进行适配，这将是一个多么大的工作量。为了解决这个问题，我在自己的团队里推行基于业务场景的 API 标准化，使定制开发的工作效率提升了三倍多。当然，API 标准化带来的收益并不仅仅在代码开发上，有了标准化的 API，产品设计、测试、联调等环节也都有助益。如果把这些环节都能通过 API 标准化串联起来，研发效率还有很大的提升空间。
业务可视化。在标准的 SaaS 上进行定制化开发，真正的难点并不在于定制代码本身，而是在于这些定制的代码如何和标准代码长期和平相处。我们不断通过扩展点为不同客户进行定制化开发，日积月累，代码逻辑就会变得错综复杂，难以为继。业务可视化相当于一个电子地图，对系统中哪些客户在调用哪些业务模块实时跟踪，就像在地图上发现哪些路段拥挤一样，发现那些被商家频繁使用的高价值定制模块，第一时间把这些定制功能标准化。简而言之，通过业务可视化，我们可以发现高价值场景，从而使定制代码可管理，可沉淀。
开放领域化。当我们能通过 SaaS 开放的标准化 API 快速进行定制开发，又能通过业务可视化对定制的功能系统的管理，我们已经离降服 SaaS 定制这头怪兽向前迈进了一大步，只剩下哪些功能可以开放，如何开放的问题了。在标准化的 SaaS 上开发定制需求时，如果不加控制，就像是在身上到处插孔一样，在每个需要定制的服务或者应用上都设置扩展点。这显然不是合理的方式。为了解决这个问题，我们在实践中引入了开放网关的概念，把普遍采用的服务或应用级别的扩展点上升到业务子域层面。实践下来，这样的做法既强化了领域建模带来的数据资产的价值，也较好的解决了 SaaS 定制中存在的扩展点混乱、功能碎片化的痼疾。
建设完善的 API 标准化、业务可视化和开放领域化本身是一个相对复杂的系统工程。有了 AI 加持，使得工程的复杂度大幅度降低。以 API 标准化为例，在具体实践中存在大量的把非标准接口往标准 API 接口上映射的工作。之前这样的工作需要研发同学一个一个接口去适配，工作量很大。通过 LLM 驱动的代码自动生成技术，原本一两天的工作现在只需要一两个小时就能完成。就以腾讯为例，企业微信、腾讯会议、腾讯文档、腾讯乐享、腾讯电子签、腾讯问卷、TAPD、腾讯云 AI 代码助手等腾讯协作 SaaS 产品，目前全部接入了腾讯混元大模型。无论是企业客户还是个人开发者，都可以通过腾讯云上 API 直接调用，实现更便捷的智能化升级，大大提升日常工作效率。
回到正文所驳斥的问题：中国软件行业几乎全军覆没，相信读者朋友们已经能发现这个论断的荒谬之处。不是只有传统的才叫软件行业，也不是只有 ERP 、 CRM 才算软件。
总而言之，通过 API 标准化、业务可视化和开放领域化，部分解决了如何在标准的 SaaS 上大规模开放支撑客户个性化需求的问题，从技术架构层面为推进传统软件架构升级提供了一个可行方案。诚然，这只是 SaaS 模式本土落地过程中的冰水一角。道阻且长，行则将至。相信在这一波风起云涌的科技浪潮中，软件行业一定会抓住机遇，破茧而出。
作者简介
沈淦：正马软件 CTO。二十年工作一直专注技术领域。一直从事中大型系统的咨询、规划、设计和建设工作；十余年的技术管理工作，在规划技术发展路线、推进技术革新、建设技术团队、推行研发团队文化等方面有丰富的经验。管理风格开放、公正、平等、激励，带领的团队有很强的执行力和使命感；热爱技术工作，善于使用技术手段解决各类问题，对大型系统的监控、运维、优化、 持续改进有丰富的经验，学习和掌握新兴技术的能力强；热爱编程，坚持编写代码，坚持深入开发第一线。
-End-
原创作者｜沈淦
