做SaaS的程序员们是时候关注企业架构了

发布日期： 2025-06-08 阅读量： 作者： 小编

　　kaiyun网页登录入口开云在线本文主要以B端SaaS产品为分析对象，分析了B端SaaS产品的挑战和生产系统简易模型，以及企业架构的意义、价值、概念模型和应用场景，点明企业架构对企业数字化转型的重要性。

　　SaaS赛道是一个超级大赛道，足够容纳上万家服务商，不太可能有哪个服务商能满足所有场景，大部分SaaS服务商在某个垂直领域，提供差异化的产品和服务。SaaS产品大部分都是面向B端客户，少部分面向C端客户，本文主要讲的B端SaaS产品。

　　B端SaaS产品为企业提供协同办公的工具，帮助企业解决某类经营管理问题，核心价值在于增加收入、降本提效、管控风险。一般会按业务垂直或行业垂直来细分，业务垂直型的SaaS产品有CRM、人力资源、ERP、推广营销、财税、OA等细分市场；行业垂直型的产品有零售、餐饮、旅游、教育、医疗、物流等细分市场。

　　客户是一个群体：B端SaaS产品为某个企业组织服务，一项业务目标通常需要由多名角色完成，例如，订单履约流程，需要消费者、运营人员、仓储人员、配送人员共同完成，产品帮助他们高效完成分工协作。

　　功能繁杂：由于B端SaaS产品涉及企业经营的方方面面，关联的用户角色多、业务流程长，反应到产品上，菜单、界面、配置项特别多，复杂度远高于C端产品。为了实现一项功能需求，往往会影响其他许多功能，需要进行全面的梳理，考虑各种极端情况，才能保证整体功能正常。

　　定制化功能：B端SaaS产品必然会有很多定制化需求，如果一味抗拒，很容易丢掉一些优质客户，但如果大包大揽地接受，系统复杂度会指数级上升，高昂的研发维护成本将很难承受，所以如何处理好定制化需求，是一项非常艰巨的任务。

　　见效慢、难量化：由于B端SaaS产品的客户是一个群体，产品上线新功能，通常是管理层先评估，能否在企业中适用，如果合适，才会组织一线人员，进行操作培训。这样一来一回，可能要2个月后才有客户正式使用新功能。其次，业务见效的影响因素非常多，很多时候并非因为产品设计问题。

　　这些特点都会导致SaaS产品的软件架构错综复杂，很容易严重腐化，演变成难以维护的“大泥球”，最终导致产品丧失竞争力，被市场淘汰。

　　通过一个SaaS产品的生产系统的简易模型，来描述SaaS产品的各个发展阶段的状态。

　　企业架构既包括对企业的愿景、战略、业务、组织的分析，又包括基于业务架构进行的应用系统分析与设计，是非常全面的架构设计框架。但很少有程序员了解过企业架构，更别提在软件研发过程中应用企业架构。然而，当下消费互联网的流量见顶，产业互联网必将成为未来趋势，企业架构也会越来越普及，谁先上船，谁就有了先发优势。

　　1996年，克林格.科恩法案颁布，美国联邦政府立法，强制要求政府机构使用企业架构理论构建自己的IT系统，最重要的机构是国防部、财政部，这一举措，直接让政府机构的数字化水平，像坐上火箭般高速发展。

　　同一时间，大名鼎鼎的TOGAF也在猥琐发育，它大量参考了政府机构的企业架构理论，沉淀出一套更加通用的企业架构方法论。

　　目前80%的福布斯排行榜前50名的企业，以及60％的美国500强企业，都在使用TOGAF理论改善自身的IT架构。

　　信息孤岛：业务与IT技术存在信息鸿沟，各业务域间存在信息鸿沟，协作效率低下。

　　灵活性差：新业务无法基于已有的解决方案和能力快速组装上线，业务无法快速迭代创新。

　　有些人可能会问，认知框架能有什么价值？常见的价值不是新签客户数、客单价、销售收入这些吗？说的没错，这些都是最直观的业务价值，但架构想创造的是更深层次的价值，并不是很直观。

　　要说清楚认知框架的价值，首先要了解什么是认知负荷。认知负荷是专业的心理学理论，简单来说就是，人脑的短时记忆和处理的信息数是极其有限，一般人就2-3条信息，牛掰点的4-5条。但是，长时记忆的容量几乎是无限的，长时记忆就是我们积累的知识。知识以框架的形式存储于长时记忆中，框架就是根据信息元素的使用方式来组织信息，它提供知识组织和存储的机制，可以减少短时记忆负荷。

　　说人话就是，人脑的短时记忆和长时记忆，可类比为内存和硬盘，人脑的内存容量就芝麻点大，只能存储2-3条信息，但硬盘空间是无限的。为了提高人脑处理效率，就必须将信息进行抽象，原来有30条信息，抽象后就变3条了，这样就能处理过来了，而抽象的框架就是我们要说的架构。

　　其实整个研发周期，真正在生产（敲代码）的时间非常少，可能连20%都不到，产研团队大部分时间都花在澄清信息和认知信息上，有了认知框架，能够显著降低整个团队的认知负荷，进而极大地提升生产效率。

　　这个比较好理解，通过架构规划和治理活动，可以有效提升整个软件系统的质量属性。

　　功能性：指软件产品能够提供正确的、符合预期的结果，能够安全地保存信息和数据，用户权限与访问权限匹配等。

　　性能：软件的响应时间符合预期，在极端场景下（例如高并发、大批量数据处理等），也能维持一定的性能水平。

　　可维护性：软件容易修改，不会牵一发而动全身；容易调试和修复bug；容易落地自动化测试。

　　系统不做什么和能做什么同样重要，就像成功的经验需要固化下来，并规模化复制。成熟的认知框架也需要固化下来，并约束团队，让团队在正确的路上行进，错误的路就别再尝试了。例如，团队A做了商品管理，其他团队拿去用就行了，别再重复造轮子，最终导致一座座数据孤岛。

　　可能有人会说，这会约束团队创新吧？但创新和荒诞常常就一步之遥，这一步可能就是遵守最基本的约束规则。

　　本文主要参考TOGAF企业架构理论，但TOGAF的内容非常非常多，也常常被批评太“笨重”，不太可能应用到所有知识，这里介绍的已经是裁剪后的企业架构概念模型，保留最精华的内容，方便大家理解和实践。

　　业务项目：指的是长期的、持续性的业务项目，一般需要制定明确的经营计划和财务预算。

　　业务能力：业务能力描述了企业目前能做什么或需要做什么。业务能力建模的关键点在于它定义了企业做什么，而不是如何做（由业务流程描述）。业务能力独立于组织架构、业务流程、资源，准确地说，这些业务要素是支撑企业的业务能力而存在的。以“招聘人才”为例，“招聘人才”包括人力部门（人力资源团队）、业务流程（例如吸引、筛选、面试、雇用）和IT系统（例如招聘系统、人事系统）。准确定义的业务能力是非常稳定的，在过去的几十年中，招聘的流程、技术、模式发生了翻天覆地的变化，但“招聘人才”这项业务能力始终恒定存在，业务能力遵循高内聚、低耦合的特性，正是因为业务能力的这些特性，业务能力对构建IT架构提供了至关重要的帮助，围绕业务能力构建的IT系统会具备更加稳定的结构，并易于扩展。

　　组织架构：想要深入理解企业的组织架构，是非常困难的一件事。因为大部分人都没有实际经营过一家企业，更没有参与设计过企业的组织架构。但组织架构属于 B 端 SaaS 产品非常底层的架构，非常考验架构能力，几乎所有的业务场景都需要应用组织数据，背后反应的是企业决策层的经营战略和财务战略，因此需要掌握一定的企业管理知识和财务知识，如果能够掌握组织架构的概念和要点，对设计好 B 端 SaaS 产品帮助巨大。

　　业务流程：是指为达成特定业务目标，由不同的角色分工完成的一系列活动。活动之间不仅有严格的先后顺序限定，并且活动的内容、方式、责任等也都必须有明确的安排和界定，让不同活动在不同岗位角色之间进行流转与交接。业务流程对于B端产品的意义不仅在于对B端客户业务的一种描述，更在于SaaS产研团队对B端业务运营的理解和剖析，这种理解是对企业资源的优化、对企业组织机构的优化以及对管理制度的一系列深入探究。只有真正理解业务流程，才能帮助B端客户达成期望的目标：降低企业运营成本，提高市场需求的响应速度，争取企业利润的最大化。

　　应用系统：即应用系统的架构设计，它起到统一规划、承上启下的作用，向上承接了企业战略目标和业务发展，向下规划和指导各个IT组件的定位和功能定义。通常包括系统、容器、组件、代码等元素的划分规范，以及它们的定义、边界和交互协议。

　　IT组件：具体的IT技术组件，例如，mysql、kafka、虚拟机、es等。

　　技术类别：通过抽象IT组件的共性特征，对组件进行分类的方法，用于管理IT组件。

　　赋能企业数字化转型是SaaS产品非常重要的发展方向，而数字化转型最重要的一步，就是将企业的业务模式和商业模式从真实世界搬到数字世界，这需要对业务进行全量全要素的建模和采集。

　　企业架构在国外已经发展了二三十年，为什么又被重新提及。因为企业架构是一套非常优秀且在国外有大量成功案例的架构方法论，能够显著提高数字化的效率和质量。这样说可能比较虚，我们以零售行业为例，列举一些数字化水平低的经营痛点。

　　会员数据没有合理采集和使用，只能基于销售数据或财务数据决策，单客价值挖掘效率低下。

　　线上线下交易履约流程没有标准化，线上运营主要依赖外部人员，业务数据散落在各处。

　　渠道全链路数据无法收集，没有数字化手段洞察消费者需求，不同渠道的商品布局规划只能依赖经验做决策。

　　企业内部系统烟囱式发展，系统之间数据没有打通，数字资产无法共享，无法相互连接。形成一座座数据孤岛，完全没有发挥出数据的价值。

　　建设IT系统非常烧钱，企业花了大把的投入，但缺乏企业自上而下的全局设计，对业务收益甚微。

　　企业数字化转型已是必然趋势，掌握数字化这项武器是大部分企业的必经之路。企业数字化转型不仅推动和加速SaaS发展，也是SaaS的巨大红利。

　　当然企业数字化转型肯定不是一件简单的事情，道阻且长，既要循序渐进，也要掌握好的方法论，企业架构可能是需要重点关注的解题方法。