第01课:业务架构和数据架构松耦合

第01课:业务架构和数据架构松耦合

概述

任何系统尤其是事务性系统(与分析性系统对应),从本质上来说都可以将其分解为三个主要的部分:参与者、对象、操作。系统功能可以进一步理解为:参与人对某个或者某几个对象的一系列操作。

参与者可以是真实的人,也可以是一个第三方系统或者自动化终端。对象指的就是领域对象。操作就是系统功能处理过程。

下面以我们最熟悉的购物场景为例进行分析,会发现通过明确这三个组成部分,有助于我们更快、更准确、更清晰的理解需求:

  • 参与者:买家、卖家。
  • 领域对象:商品、支付信息、订单。
  • 操作:购买及结算、发货。

买家查看商品、添加到购物车、确定购买、生成订单并结算。卖家收到订单后,确认并进行发货。

那有人可能会说,这不就是用例吗?也对也不对。用例(指用例图)多是对参与者、用例以及它们之间的关系的描述,其中用例对应了系统的功能,它包含了对象和业务过程两部分,是一种综合性描述。

虽然通过用例图很容易知道参与人是如何协作并操作系统功能的,但这种方式并不能使我们很好的发现领域对象以及业务过程的边界,尤其我们的业务过程是横跨多个子系统、系统的情况。还有用例图只是一种概要性描述,并未详细描述业务过程,更多的情况是,我们需要结合用例图、BPMN 等从不同角度来进行描述。

而且本文更多是侧重于如何来分析一个系统的需求,而不是需求的最终描述形式。也就是说我们讲的更多是一个方法论,而不是这个方法论的输出结果。

尤其是对于复杂的业务系统集,弄清有哪些参与者、每个参与者可以操作哪几个系统的哪几个功能,需要与哪几个参与者协作完成。所有这些问题都有助于我们划分系统的业务边界和数据边界,构建松耦合的系统。

业务过程框架

如果你稍微了解电信行业的业务系统,那么就会对 eTOM 不陌生。简而言之,它是一套业务过程框架(Business Process Framework),是一种参考框架或者分类模型,通过这方法论将服务提供商所涉及的所有业务活动进行分类。

通过这种分类方式,可以有效的实现服务提供商业务过程的治理,使得任何粒度的变更都会体现到业务过程框架中来。

我们在变更业务过程时,尤其是对于跨系统、子系统的业务过程变更。有时候很难理清它涉及的变更点,也很难直观的评估这些变更对业务过程的影响,这主要是因为我们常常在一个固定的粒度考虑业务变更。如果这个粒度过粗,那么有可能使得变更点不够具体、很难指导开发,如果这个粒度过细,那么又会导致变更点遗漏。除此之外,还会容易导致业务过程的边界不够清晰,使得各个系统或者模块产生耦合。

一种合理的业务过程管理方式就是按层级进行分解,而这也是 eTOM 所采用的方式。通过借鉴 eTOM 这种业务过程框架,可以使我们在业务架构上实现松耦合,有助于对业务过程进行有效管理。

在 eTOM 中,业务过程被按照不同层级进行了分解,主要体现为以下几个级别:

  • Level 0——业务活动:识别和建模业务目标、价值流和环境约束,确定产品线作为最终交付的业务目标。在这一级别可以明确各产品线之间的边界。
  • Level 1——过程组:设计产品结构、产品交付和支持流程链、企业级数据模型、组织结构,识别业务知识,这是所交付业务的功能结构。定义不同的视图来描述业务过程是如何结构化交付 Level 0 中的业务活动的,过程组织形式必须是从功能角度端到端的。
  • Level 2——核心过程:识别行业标准参考模型;开发通用流程、过程层次结构;识别和建模业务数据定义、系统结构;定义业务角色。该级别主要是可识别的端到端业务过程的子过程。
  • Level 3——业务流程:设计详细流程、分配业务角色、确定支持系统及数据流。将业务数据模型映射到系统数据模型,考虑失败路径、队列和瓶颈,该级别主要定义 Level2 中过程的具体流程。
  • Level 4——操作流程:开发详细的子流程设计,定义操作角色,将过程链接到书面过程,确定详细的系统、设备和资源使用情况,该级别主要是对 Level3 的进一步细化。
  • Level 5——详细的流程:通过工作流系统、电子商务解决方案和系统开发自动的交付流程。链接过程和数据模型到系统和软件开发环境,该级别主要是对 Level4 的进一步细化。

也许你对 eTOM 这种划分感觉有点不知所以然。没关系,接下来通过一个例子进行说明,你或许会理解这套方法论在业务系统构建过程中的价值。

业务过程分解示例

本节试图通过一个示例来演示业务过程的逐步分解,当然本节对于业务过程的理解(尤其是高层分解)并不与 eTOM 一致,这也是仁者见仁智者见智的事情,关键是如何将这套方法论用到我们的实际工作中,去改进我们的业务过程管理,而不是生搬硬套。

业务活动

如果你不是孤立的分析一个系统,而是全局考虑企业整体的业务活动,就会发现,企业的业务和数据是分区域而且最终形成一个闭环。

业务数据基本上按照下面的一个示意图进行流动,以确保企业活动的正常运行:

enter image description here

基础:如果你是一家销售类企业,那么在业务活动开始之前,需要有一些基础数据进行驱动。这些数据包括产品及价格、销售策略、供应商和合作伙伴等等,这些都应该认为是基础数据,它们是先于业务活动开始而存在的。

运营:当基础数据具备之后,在这些基础数据的驱动之下,业务活动便可以开始运行。如产品销售形成的订单、支付记录、配送以及后期的服务,这是业务活动的核心。

分析:基于对运营过程产生的数据进行各维度分析,并将分析结果应用于“基础”和“运营”的调整与优化,从而形成数据上的闭环。

企业:前面三者形成了业务数据的闭环,而“企业”则作为一个横切面贯穿三者。它主要用于企业对各环节的监控、管理,如人员管理、绩效管理、财务管理、经营指标监控等。

有了这四者,企业业务活动才能正常运行,但是这只是一个通用概念,我们再将其具像一下——电商类运营系统(受业务知识所限,不确保业务域的完整性,如有遗漏,实在抱歉)。

在这四个环节的基础上,我们可以将系统的业务目标进行一个初步拆分:

enter image description here

我们初步将整个的业务活动拆分为五部分:

  • 产品及客户的管理:包括产品定义、产品销售、客户注册及管理、客户购买及支付等等。
  • 库存:在整个产品销售过程中涉及的物品的管理,一部分属于销售过程,如销售出库及退还,一部分不属于销售过程,如进货、盘库。
  • 服务:对产品销售各环节的服务跟踪及保障,如投诉处理等。
  • 商家及合作伙伴:如商城入驻商家的管理、分成等。
  • 企业:企业内部的管理,如销售人员、财务管理等。

从我们对这五部分的介绍会发现,你可以根据这个分解划分产品线(可以再拆分或者合并,但最好与你的业务过程视图相符)。

过程组

通过“业务活动”的分解,我们会自然而然对于它的每一部分再进行细分,如下图所示:

enter image description here

这里需要注意横向拆分和纵向拆分的区别:

横向拆分表示功能相关的过程,纵向拆分表示端到端的业务流程。

也就是通过横向拆分,将业务过程按照功能耦合程度聚合成不同的组。通过纵向拆分,则是对功能组内的端到端业务过程进行的拆解。

以“产品、客户”为例,从横向看,它包括了产品策略及定义、客户注册、购买、计费等整个交易链条的功能。从纵向看,这个交易链条被拆分成了几部分:首先是产品策略的定义,其次是产品生命周期管理,然后是运营准备(客户注册、支付账户设置等等),再就是运营实现(购买、生成订单),最后是计费(支付、生成账单等等)。

核心过程

显而易见,通过“过程组”两个维度的划分,我们很容易在此基础上做进一步的细化,明确核心功能。由于本部分非常复杂,不再整张视图显示,我们只拿“产品、客户”部分作为示例(假设这两部分我们作为一个系统,当然你可以进一步拆分为产品和客户两个系统)。

通过“过程组”的横向和纵向分析,我们可以推导出下面的图(部分示意):

enter image description here

这部分我们可以视为系统模块视图,你也可以将这部分与上一部分结合,提供一个总体的业务架构图。注意每一部分所在的纵向拆分区域。

业务流程

该步主要是针对第二步,细化业务流程。以上一步中的“订单管理”为例:

enter image description here

通过图可以发现,它将订单管理做了进一步的拆解,这个层面我们可以将其视为每个模块提供的服务。

还需要注意,通过从产品、模块到业务服务的分解,我们需要逐步识别参与人及其在每个系统中的角色。如产品管理,企业运营人员是否可以操作?合作伙伴是否可以操作?它们分别是通过哪个系统进行操作?这会影响最终的系统实现方案:是在产品系统中提供多种角色限制还是将产品作为服务提供给合作伙伴系统。

在这一级别,我们已经可以以业务过程的形式描述一些核心功能,如订单处理:

enter image description here

注意它们在每个系统中的分解(不同背景色),这会影响业务边界的确定以及各系统服务的发布。

当你的业务系统需要对企业外部组织提供服务时,这个流程也可以用于映射你的业务过程编排工作。

操作流程及详细流程

你还可以针对业务流程中的每一个节点再进一步分解(这也是必须的,作为服务实现的依据)。

如上一步的“订单创建”,我们需要详细描述创建的步骤,需要记录哪些关键数据,做哪些完整性校验等等,此处不再赘述。

通过这种逐层分解,我们很容易明确每个产品、产品中每个模块、模块中每个服务的边界,以及它们是如何协作的。通过这种协作,我们支撑了系统哪些业务过程。

只有这样,我们才会知道业务过程有没有缺失,能不能有效支撑企业业务的开展。当业务过程变更时,我们也会更有效的将其分解为各个产品、模块以及服务的变更,以风险和影响范围可控的方式。

数据架构松耦合

说实话,数据架构松耦合这个词听起来还是有些抽象,如果换句话说数据拆分,估计就具像的多。但是我们说数据拆分只是数据架构松耦合的一部分内容,而且是偏应用架构层面更多一些。

数据架构的松耦合需要包含两个方面,一个是数据模型的松耦合,体现在业务过程各个环节流转数据的解耦,一个是数据拆分策略,这体现在对共享数据的处理方式。

前者决定于业务模型的分析能力,后者决定于技术架构及部署架构的复杂度以及是否满足用户需求。

数据模型松耦合

数据架构中,数据模型的分析与建立与业务架构设计是同时进行的,如果在业务架构完成之后,孤立的进行数据架构设计,那么就很难达到预期。

当我们进行数据架构设计时,也需要与业务架构一样,进行逐层分解,这样有助于让我们发现数据域的边界,而数据域的边界则是我们需要解决耦合的地方。

考虑一下业务过程的分解,我们就会很容易得出在产品、模块级别数据模型的边界,并且完成对核心模型的逐步细化。例如:

  • 在“业务活动”阶段,我们得出的核心模型是产品、客户、库存、供应商/合作伙伴、服务等。
  • 在“过程组”阶段进一步细化,如客户又细化为:客户基本信息、账户、订单、账单。
  • 在“核心过程”阶段,客户订单又细分为:订单基本信息、订单项、订单操作记录、支付记录等等。

通过这种方式,我们可以形成能够导出为数据结构设计的输出结果。重要的是这些业务模型的边界很清楚,不会导致管理混乱。

数据拆分

数据拆分这部分相对比较难描述,在这一阶段理论上不应该规定具体的技术方案细节,如采用文件还是采用共享数据库,是否考虑对数据库做垂直拆分或水平拆分,采用什么样的主键策略。这些应该放到应用架构去考虑。

该部分的侧重点还是要与业务过程结合。需要确定哪些数据需要共享,共享的边界是什么:产品间、产品内、模块内。实际上绝大多数考虑的应该是产品间的数据共享问题,因为基本上产品内的数据是共享的,除非你倾向于更细粒度的组织你的系统。

除了共享数据,还要考虑数据冗余(这是另一种形式的共享),如供应商订单是否需要冗余客户信息,如何冗余,当客户信息发生变更后如何处理,这会影响到后续的接口设计,需要提前明确下来。

通过合理的共享、冗余以及更新策略,确保数据模型之间的独立性,实现系统之间的拆分,以便从数据上实现松耦合。

小结

本节简单讨论了一下业务架构和数据架构的分层处理。通过对业务架构的逐层分解,可以明确业务过程边界,以可控的方式管理及演进业务过程,实现业务架构的松耦合。在业务过程分解的过程中,可以同步对数据架构进行分解,明确数据边界,实现数据架构的解耦。

上一篇
下一篇
目录