对 aPaaS 的产品认知
#62
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
-
从业以来，一直是在企业软件领域摸爬滚打，最开始接触的就是流程、表单引擎这些东西。行业应用领域对应用架构的诉求通常就是要充分支持扩展和可定制性，因为通常会把一个业务平台交付给几十甚至上百家需求各异的客户，基于成本考虑，必须在同一个基础版本上迭代出各客户的需求，如果做不到这块，交付给每家客户的版本毫无共性，或者共性过少，那就可能出很多问题。架构的不合理性会影响业务团队的组成方式，进而影响盈利水准。
后来，大概在 2012 年那段时间，参与尝试做了一次元数据驱动的定制抽象引擎，回头看，这次尝试有很多不如意的地方，主要还是经验不足，对很多事情的理解不够深刻。也正是这段经历促使我去探索一些事情的解决方案。可以说，目前在网络上看到的我的全部输出，都是在那之后产生的，都是为了解决其中可能的问题而进行的有目的的探索，而不是纯粹为了学习技术本身。
再后来，我又经历过小型 SaaS 团队，对于小企业付费订阅这个事情，也有了不少认识，这种一个小团队每年付费几千块的模式，对我是一种很好的知识补充，因为之前积累的都是面向单笔数百万到上亿合同额交付型软件的认知。
近年来，aPaaS 这样的概念逐渐火热，借此机会，正好把自己领悟的产品观简单总结一下。
轻量级业务中台
小型工具 SaaS 的生存难度很高。我们可以看下这几年最火的两个小型 SaaS，从它火爆的结果里面寻找原因。
之所以这两家火，并不是仅仅它们的产品体验只是满足了表象上的“好”，其最大价值是，有希望成为小微企业的“业务中台”。
这两个产品，看上去跟什么中台一点关系都没有，为什么要说他们能成为一种业务中台？
本文将从某些角度阐述以 aPaaS 形态作为业务中台的价值，并尝试用上述两个产品为例，解答这个问题。
数据治理
从企业数字化的角度看，数据治理是一件从开始就要干的事情。每当有新业务产生，需要新的数据或者业务系统接入的时候，需要及时做好数据的集成和归并工作。
假设初期你采购了某个任务管理系统的 SaaS，后期由于业务扩展，需要购入某种 CRM 或者 ERP 系统，那么，就会面临很多集成相关的问题：
此外，企业的数字化、精细化运作，必然需要引入某种 BI 或者数据分析体系，它的先决条件就是数据是语义化的、可被理解的，这对数据的形态也提出了比较高的要求。
所以说，不管多小的公司，都存在数据中台所面临的问题，而有能力对此进行规划的人员很稀缺，并且其成本也不是小微企业能够承受的。
随着这类企业的成长，这些问题累积到一定程度，将会对企业的运作带来很大负担。当一个企业的信息系统年久失修，其管理效率也必然是大受影响。
如果存在致力于解决这些问题的数据中台，让数据的采集、分析、组合过程变得更智能化，再对企业的 IT 部门进行相关的培训，可以使得前面提到的这些问题中的大部分得到及时解决。
业务治理
另外一个角度，数据治理的根源是业务治理。如果想要使得企业运作过程中产生的数据成为宝藏，而不是垃圾堆，需要控制这些数据的产生过程，也就是对业务进行治理。
业务治理是一个难度很高的工作，因为业务的集成过程往往是比较复杂的，如果不存在很先进的管理手段，只是流于文档，则其维护代价也会非常之大。
举例来说，我们可以画一些架构图，来描述当前的业务系统集成关系，然后，细化进去，每个业务系统模块内部，又可以呈现出模块与结构等更细节的组成元素。
遗憾的是，传统意义上的这类架构，都是纸面架构，它与真实系统之间的对应关系是需要人工花费巨大精力去维持的，因为业务架构的存储形态就是静态化的，业务系统的技术实现与业务架构描述之间，是不存在任何自动同步环节的。
当业务专家调整了业务模型或规则，他需要标记出更改的部分，然后交由开发团队去实现出来。这种研发方式一直是业务软件开发的主流，最主要的原因是上手成本低，并且容易被流程化，灵活性也足够。
历史上曾经出现过一些潮流，比如让业务专家学习一些领域建模知识，借助 UML 这样的表达形式，去描述软件的各种结构：实体、关系、流程、交互。很遗憾，这种方式并没有那么普及，其原因是什么？
在这些表达方式流行的时段，IT 系统是一种很昂贵的东西，只有利润非常丰厚，或者面临很高管理成本的行业，才会去大力建设，比如我国早期信息化最好的行业就是银行和电信体系。只有较高的利润，才足以支撑技能很高的业务专家团队，而大部分行业是很难承担这样的代价的。业务的表达成本必须再次大幅降低，才能满足社会对数字化的需求。
所以，如果致力于提供在线化的业务 SaaS，需要采取很多手段，把业务的表达成本尽可能降低，并且能够用多种方式把业务尽可能准确地呈现给业务专家，使其有机会介入，及时调整不合理或者不适应业务发展状况的部分。
技术栈的升级
回顾业务软件研发领域，技术栈的变迁可谓非常频繁，各种终端设备蓬勃发展，操作系统、编程框架、编程语言层出不穷，然而从业务实现的角度，今天我们每编写一行代码，就立刻为明天增加了一份历史负担。
如同城市管理，老旧小区的维护是一种非常复杂的问题。在快速发展的趋势下，大拆大建式的手段是很普遍的，所以，在大型互联网企业中，信息系统的生命周期大部分只有一两年甚至更短，使命完成之后就被拆除了。
这种方式实际上是一种不计成本的策略，因为有很大的利润来支撑，但是这种情况无法适用于大部分行业。时至今日，IT 系统的建设费用仍然是比较高的，绝大部分公司都会在这块的投入上斤斤计较。
所以，每次采购新软件的时候，大家都期望它能尽可能支撑得久一些，像大型 ERP，企业都会倾向于用到十几年之后，尽可能让自己去迁就软件系统，直到实在无法跟上业务发展。同时，不是每个行业都有足够的高技能开发人员，一旦软件的初始技术栈确定，后续很可能因为人员技能或者迁移代价，就再也不会升级了。
这就形成了一种局面，一方面，时常重构和更新迭代的代价是很多行业无法承受的，另一方面，当一套软件再也跟不上这家公司的业务发展，如何迁移到一套新版系统，也会成为非常棘手的事情。当前，有无数企业面临这样的问题，数据和业务逻辑的迁移困扰着几乎每家企业。
立足于此，凡是致力于打造业务中台的的产品，都必须能够说清自己将要如何避免之前见到过的这些问题。因为这些问题如果不解决，只是历史的周期性循环而已，并且，当客户企业的业务复杂度达到某个数量级之后，就好比老旧小区的面积大到了一定程度，拆除重建成本已经高到无法接受，只能另起炉灶造新城了，这对一家企业的运作是非常致命的问题。
随着企业管理越来越建立在数字化的基础上，这类问题也许会成为阻碍企业成为百年老店的最重要因素之一。
因此，我们需要描述数据、描述业务，并且寻求某种能把业务实质和技术栈不要绑得这么紧密的实践方式，不妨畅想，在某种理想情况下，技术栈的升级并不十分影响业务的正常运作。这种抽象过程一定是很困难的，但是我们可以寻找在“完全重建”和“部分复用”之间的平衡，寻找“抽象成本”和“迁移代价”之间的平衡。
研发环节提效
长期以来，基于 Web 的系统以易开发、易部署等特性，逐步成为了应用系统的主流技术栈。
然而，人们从不满足于现有研发流程的效率，总是尝试各种提升方式。
如何提高业务系统的开发效率？怎样的工具或者工程体系才能提效？我们先从效率的损失过程看起。
效率的损失过程
从整体性来说，一个 Web 系统，或者泛化为一般 GUI 系统，其典型架构都是这样：
这个 X，在不同架构模式下有不同含义，也有省略它的，但总的来说，M 表达与实际存储相关的模型层，V 表示展示层，模型驱动视图，是大家的共识。
通常，这个实践链路会跨越不同的部署结构，兼有多种开发语言，并且，在某个规模以上，不可避免地涉及一系列人员的协作。
人类的协作是效率降低的本源，因为人跟人的传输协议是不标准、不稳定、语义不清的，两个人沟通一天，也许就传递了不到 1K 的有效信息，所以，重构生产关系才是提高生产力的核心手段。
另外一个很重要的问题则是需求与实现的统一管理。我们之前提到，传统的研发体系中，需求的描述是偏纸面的，它跟代码天然就有断层。每当业务进化，会需要两种截然不同的版本管理方式。如果能够找到一种方式，让需求的描述与业务实现变得更加紧密，比如说，能够以某种可视化手段描述出某次需求迭代所产生的业务变更点，并且与需求的描述一一对应，有可能让这个环节的负担变轻。
协作环节的消除
以一般的 Web 系统需求变更为例，它涉及的协作环节可能有：
一般的团队中，这些角色往往都有一定程度的合并，比如说，DBA、运维的职能，合并给后端；在不太需要高体验的场景，去掉设计师，由前端来发挥；开发人员自测，等等。
再继续合并，就对个人能力要求很高了。前后端的合并，不仅仅是开发语言的统一就可以的，还需要从思维模式上去融合，现代软件开发技术的技术栈已经门槛稍高，不太适宜于这种全栈化了。
人员的全栈化是一种很难的方式，虽然大家总是说学习某种技术很容易，但是要成为熟练工，需要很多时间，而且人的精力有限，很难在多个领域同时跟进技术的发展过程，所以，需要尽量再屏蔽掉很多不相关的因素，把技术细节隔离出去给较小的专业团队去维护，形成一种协作机制，以期能够让更多的人参与进来。
这个角度，也就是现在被称为：“低代码”、“无代码”的 aPaaS 平台所试图解决的问题。
物料的标准化
回顾人类历史，工业化的一个重要因素是物料的标准化。在制造业，广泛存在通过编号描述的元器件，并且会在装配过程中，使用物料清单（BOM）来明确描述制造一个成品所需的物料种类和数量。
但是我们注意到，在软件行业，研发人员创造业务软件的工作方式更像是裁缝，而不是电子设备的装配工，这说明大家都是以比较自由灵活的方式去开发软件的。这种方式当然有其优势，因为程序员是比较讨厌约束的，但是也带来了一些弊端：
通常，在研发过程中，团队内部总是会尝试做一些约束，比如规定代码的典型形态，或者引入某些模式，进行一定程度的封装，在遇到某类问题的时候，能够尽可能使用比较一致的方式去表达，但是这个过程仍然是比较宽泛的，我们很难用一种通用的检查工具去提取关键的业务信息，业务专家不得不细致地进行测试，也没有一些视角能够更详细了解这些系统生产过程中的状况，目前的管控设施都过于技术化了，缺少更业务视角的解读。
所以，如果期望能够在某些业务领域有所改进，就需要从一些很基本的方面做起，比如物料的标准化。
最容易被认识到的标准物料是基础的 UI 组件库，这个环节，只要不是做得特别差，一定能够提升效率，也比较容易认识到大致的实践路线，但是从基础组件库再往前走一步，大家对于路的看法就不同了。
必须意识到，如果以装配一体化为最终的实践道路的话，从最基础的业务无关的组件库再次封装出的组件库，基本都是非标准物料，物料的业务属性需要被抽象掉。
组件物料本质上是交互物料，某个领域的组件物料，需要从交互层面的可组合性去看待，否则就会让业务设计师的成果停留在纸面上。
除此之外，也存在很多逻辑层面的元件，比如针对某种数据源的封装、针对某种数据类型的通用校验规则、常见动作的配置化描述等等。
此类细节，不在本文中详细叙述。
业务与技术实现的隔离
从整体来看，整个应用系统其实可以用一个公式简单表达：
这个公式是 MDV（模型驱动视图）的核心理念，那么，这里面的 f 是什么？
这个 f，在实践中，实质上是若干引擎的叠加：交互场景、流程、规则等等。
前面环节提到的物料标准化，是有助于隔离业务属性的，比如说，视图层级物料很大程度上跟业务的关联较小，并不属于业务的核心部分。
一个比较粗陋的业务隔离形态，可以化解为：
这样的一套东西，理想状态下，是技术栈无关的。
从比较容易理解的交互层面来举例：
他们的业务实质并无不同，只是引擎所启用的解释插件集有所差异而已，只要多种插件集的表达能力一致就可以了。甚至说，在面临多系统的集成的时候，被集成方的交互风格可以自动适配到集成方的。
同理，对存储、规则、流程等等方面，都是有机会去做这样的事情的。
需要注意的是，整个这套体系的抽象代价是非常高的，需要去从整体角度，结合业务场景作很多权衡。比如说，从极其简单轻量的场景切入，或者是侧重于某种具体业务领域去设计引擎插件的某种子集。
据此，可以把业务的表达形态从硬编码中抽象出来，并且对此作更定制化的管控。
版本的管控
传统软件研发过程中，版本管理是基于文本的，因为输出物是代码。但是，基于这类描述式的业务表达机制，不应该继续使用这样的版本管理方式。
因为现在的业务结构是可理解的，完全可以有一种更立体化的表达。
比如，因为某需求的变更，导致：
每一块东西，都拥有了语义性，可以被更加细致地呈现出差异。本质上，业务交付的版本还是一种基于树形结构的差异描述，只是其细节更加丰富了而已。
这样的版本管理方式，对于业务迭代是一种非常有价值的提升，可以让业务专家能够更容易验证需求，也便于大规模全量自动化测试的覆盖，业务的可验证性大大增强。
小结
理想和现实之间，总是存在权衡的。我们有理由相信，当今的时代，一个面向企业领域的 SaaS，其底层一定需要某种定制化能力才足以支撑差异化需求，然而其定制化能力的边界在哪里，则需要结合自己的业务领域去作判断。
如果面向的是很轻量的需求，完全可以在 aPaaS 的基础上，以业务模板的形式提供各种预制产品能力，用户可以在此基础上根据自己的需求进行更个性化的定制。
这个时候回头看 Airtable 和 Notion，就可以发现很多有趣的地方。我之前曾经提过，这两个东西很可能是殊途同归，一体两面。
从产品角度，两者都可以有很好的延伸。如果 Airtable 能够把自己的视图结构描述化，它就天然拥有了 Notion 的编排能力。Notion 因为要支持基于记录的模块集成，必然也需要实现关系数据的结构化表达能力。
之后的文章中，会附带一个系列的技术文，侧重从实现的角度讲述一个比较简单的这类原型系统的构建过程。
Beta Was this translation helpful? Give feedback.
All reactions