如何理解零代码开发平台（跟着案例学习信息架构和零代码搭建）

如何理解零代码开发平台（跟着案例学习信息架构和零代码搭建）TOGAF框架定义了企业架构内容和实施步骤及交付物，将企业架构划分为业务架构、应用架构、数据架构和技术架构，形成了涵盖企业各方面的架构体系，是一个面向各种不同组织、具有很强通用性的企业架构。对于实际的架构工作，其指导意义高于实践操作的意义。其中，业务架构：定义企业战略、企业治理、组织结构以及关键的业务流程。数据架构：描述组织的逻辑与物理数据资产的结构和组织的数据管理资源。应用架构：提供描述应用系统的部署、交互以及系统与组织核心业务流程之间关系的蓝图。技术架构：描述用于支持业务、数据、应用服务的软件、硬件的能力。这些软、硬件以及逻辑技术部件包括 IT 基础设施、中间件、网络、通信、处理机制、标准等。TOGAF模型全称The Open Group Architect Framework，目前由The Open Group负责维护，已经发展到9.x版本。在这些方法中，来自IBM的Zachman框

零代码平台赋能了业务开发者，让他们可以不写代码就能完成应用实现。但是企业应用设计和开发毕竟是一个复杂过程，对于大多数用户来说，即兴创作是很难的。对于比较复杂的应用搭建需求，它依然需要一个完善的分析和计划的过程。

在企业信息系统建设过程中，开发和实施前都离不开架构设计工作，对于复杂的系统，信息架构所花的工作时间比例更高。而且，信息架构是一个长期过程，它不仅服务于具体业务系统开发和实施的需求，还包括中长期规划和服务于应用的迭代与迁移需求。

本章重点介绍企业信息架构（Enterprise Architect）的一般方法，以及如何简化它们来服务零代码应用搭建的过程。

1. 企业信息架构的一般方法

从上世纪七八十年代开始，企业信息架构就开始成为一个专业领域，形成了一整套方法论。这些方法论围绕复杂组织的信息系统建设提供了抽象的思维框架和计划工具，它们虽然大多来自军工、航天和政府需求，但经过整合以后，同样适用于企业领域。

在这些方法中，来自IBM的Zachman框架和源自美国国防部的TOGAF框架是比较典型的信息架构方法论。我们对这两个方法论做一个简单介绍。

1.1 Zachman框架

Zachman框架起源于John Zachman先生在1987年完成的信息系统架构论文“A framework for information systems architecture”，他把信息系统架构设计相关的各种元素归纳到如下表格之中：

从这个复杂的表格可以看出，信息架构是一个多层次和多要素的复杂工作。他服务于组织的不同层面需求，也需要多角色一起参与建设。这是一个在宏微观层面都非常完整的框架。依照这个框架来完成分析和计划工作必然是相当完善的。但因为它的完善，也给企业界的使用带来繁冗的工作。五种参与角色和六大考量要素综合起来就是三十个格子，如果都按照这个标准来做架构设计，企业信息系统的规划成本就太高了。所以，我们往往把Zachman框架当作一个分工和思考的检查清单来使用，至少可以帮助我们避免重要的遗漏。

1.2 TOGAF模型

TOGAF模型全称The Open Group Architect Framework，目前由The Open Group负责维护，已经发展到9.x版本。

TOGAF框架定义了企业架构内容和实施步骤及交付物，将企业架构划分为业务架构、应用架构、数据架构和技术架构，形成了涵盖企业各方面的架构体系，是一个面向各种不同组织、具有很强通用性的企业架构。对于实际的架构工作，其指导意义高于实践操作的意义。其中，业务架构：定义企业战略、企业治理、组织结构以及关键的业务流程。数据架构：描述组织的逻辑与物理数据资产的结构和组织的数据管理资源。应用架构：提供描述应用系统的部署、交互以及系统与组织核心业务流程之间关系的蓝图。技术架构：描述用于支持业务、数据、应用服务的软件、硬件的能力。这些软、硬件以及逻辑技术部件包括 IT 基础设施、中间件、网络、通信、处理机制、标准等。

附图：TOGAF架构开发方法

TOGAF的一大特色在于其独特的架构开发方法AMD (Architecture Development Method)，它是一个以需求为中心的循环过程。在总体框架和规划原则的前提下，ADM方法从架构愿景出发，经过业务架构规划，确定信息系统架构和技术架构，然后结合现有的信息化基础，给出企业信息化建设，适应性改造的解决方案。迁移计划针对实施方案中不同项目的优先权，评估各个项目的依赖程度、迁移费用、收益等，并形成具体的实施规划；实施治理制定了各个实施项目的建议，建立架构规约来管理所有实施和部署的过程，以确保实施项目架构与相关项目架构的一致性。架构变更管理关注业务目标、环境和技术等方面的演变和发展，为是否启动和规划新的架构进化周期提供。

TOGAF目前是企业架构专业领域最知名的框架，它也有完善的培训、认证体系。但它和Zachman框架一样，都过于庞杂，缺乏实际项目落地的可用性，更多地演化成为一个职业，而难以被一般企业实践直接所用。

接下来的小节会专门介绍一个简化的信息架构方法。它保留了经典企业信息架构的战略视角，但更多着眼于IT项目的落地需求，简化了参与角色和架构实现中的环节，让非专业人员也能够从事信息架构的实质性工作。

1. 一个简化的信息架构方法（RPIC）

方法论的介绍很容易陷入晦涩的程序说明，它最好能够结合实例来表达。为此我们专门准备了一个大多数企业用户能够有代入感的案例。但在解析案例之前，还是有必要先简单概述一下这个方法论的核心思想。

RPIC是Role，Process，Information和Content的缩写，意思是角色、流程、信息和内容。它是一个循序渐进的分析计划过程，从企业管理和运营角色的分解出发，为每个涉及到的角色（可能包括外部角色）分析他们在业务活动中需要完成的流程和接触的信息（数据），当枚举出所有的流程和信息后，就能够取得它们的不重复并集；通过这个并集内容分项规划数据架构、角色权限、统计报表和工作流程四项核心架构内容。

这四种架构内容是非常具体的IT项目落地蓝图，无论是外购系统配置，还是自行开发，包括使用零代码应用平台搭建，都能够通过这个方法获得完善的计划引导，建立有秩序的执行步调和达到预期的结果。

整个过程简洁明快，着眼于具体规划产出。稍有IT经验的职场人员经过简单训练就能够掌握。尤其是结合零代码平台，规划人员甚至可以直接上手完成具体的应用搭建。当然，使用者要了解这是一个简化的框架。它不可避免地会忽略一些内容，比如企业战略视角、复杂企业组织的干系人网络、规划的长期视角、应用的迭代和迁移计划。这些被裁剪的内容并非不重要，只是它们不一定出现在每个应用的需求时刻。而且我们也会有其他办法来针对性补充。

接下来的案例，我们会按照这个方法论，一步一步引导大家理解和掌握企业信息架构技巧。

1. 结合案例的方法论解析

3.1 案例背景

案例中的企业叫“普渡餐饮”，是一家成长中的企业餐饮服务企业。它为周边企业提供员工送餐和宴会送餐服务，面对的客户对象是企业。因为普渡餐饮重视菜品质量和口味，它的服务获得了一些高福利企业的欢迎。一般企业会为员工常年订购早餐和午餐，遇到有会议用餐需求的时候，也非常乐意继续使用普渡餐饮的服务，因此普渡餐饮的这两种业务有明显的客户交叉现象。

普渡餐饮的产品目录是有独立菜品和套餐组成的综合菜单。员工早午餐可以从数十种套餐中进行选择，宴会则可以选择套餐或者自选的菜品组合。大多数客户会倾向于选择订购套餐。

因为在发展的早期阶段，普渡餐饮目前只有一个生产加工中心。出于成本控制的目的，普渡餐饮除了包装材料以外，几乎不保留任何生鲜原料库存，采购完全根据前一天的订单，在当晚完成采购，次日根据订单加工和派送。菜品加工完全在自营的生产加工中心完成。因为营业规模有限，普渡同一时期只在数家固定的生鲜配送商那里采购，每月结算费用。

普渡餐饮的物流服务是外包的，通过固定合作的物流公司将制作好的菜品和包装快递给本地客户。物流公司每月根据实际的物流费用与普渡餐饮结算。

3.2 案例目标

结合以上的案例背景，我们的目标是为普渡餐饮设计核心业务系统的信息架构，并通过零代码平台来实现整套应用。为了控制篇幅，我们把核心业务系统定义为从普渡餐饮接单开始到餐品交付，并完成收款的全部过程，舍去行政、人事、营销等环节。

我们要获得的产出物具体包括：

• 信息架构中的数据结构定义
• 工作流程定义
• 可用的应用系统
• 配套的使用文档

3.3 架构设计过程

（1）价值创造过程总览

为了梳理清楚一家企业的信息架构需求，我们一般可以先绘制一张流程图。这张流程图可以从宏观的层面将这家企业的价值创造过程表达出来。在流程图中，节点表达的是参与主体，既可能是内部部门，也可能是外部角色。价值创造按照从左往右的方向进行，这样既容易绘制（减少交叉），又能够有条理地遍历所有的参与角色。而角色是RPIC方法中的出发点，我们不能遗漏任何参与业务流程的重要角色。

在本例中，客户向普渡餐饮的销售部下订单，销售部据此向内部的加工中心下加工单，加工中心再据加工单向生鲜配送商下采购单。以上是整个业务活动的信息流部分。然后生鲜配送商向加工中心配送食材原料，再被加工成最终产品，并通过物流服务商配送给客户。在这个流程图中，信息流用虚线表达，实物流用实线表达。在后面的信息架构工作中，我们重点要关注的是信息流，以及和信息流相关的角色主体。

通过以上的流程图，我们获得了以下参与角色：

• 销售部
• 加工生产中心
• 客户（外部）
• 生鲜配送商（外部）
• 物流服务商（外部）

在角色定义中，内部用户一般要精确到特定的职能，而外部角色一般不需要细化，因为上下游协作主体一般都有固定的角色来和本企业进行交互。比如在本例中，无论是物流服务商，还是生鲜配送商，都是由客户服务部门来对接的。

所以接下来，我们按照这个分析结果逐项厘清所有的流程参与角色

（2）参与角色盘点

从总览流程图，我们挖掘出了和业务活动有关的角色。在列举具体角色的时候可以分别从管理角色和运营角色这两种类型出发。因为必然存在的科层分工，每个企业组织中都会有不同的岗位层级，他们在业务活动中需要接触不同的数据对象和完成不同的工作内容，因此，分开列举运营用户和管理用户能够帮我们把信息架构设计得更完善。

下表是我们根据主体对象继续开发出来的角色清单。为简化案例，我们只细分了和案例目标有关的两个职能部门和总经理角色。这样我们就有了RPIC方法的出发点——角色（Role），后续的架构设计工作将围绕这些角色的工作视角进行。如果你需要通过用户访谈来帮助架构设计，也可以明确地将这些角色用户当作访问对象，观察他们的业务活动，搜集来自他们的工作材料。