

我们开始的时候往往习惯于用显而易见的方式进行建模,比如业务人员都喜欢用流程来表示做一件事情的先后顺序,可是不同的人看待流程的方式会有不同,使用的符号也会不同,所以业界就会创造出BPMN(Business Process Modeling Notation)标准,这样不同的人就可以使用相同的符号和语言来建模业务流程了。有时候不同的流程又有共通性,为了不重复定义流程片段,就会将可重复使用的流程片段建模为子流程,整个业务活动就变成了主流程在不同情形或阶段下对子流程的调用。但是,由于企业业务的复杂性,我们不能仅依靠流程对业务逻辑进行建模,从流程角度往上看,这些业务过程纷繁复杂,如果都细化到流程级别,太过于细节,以至于无法获得对业务整体的感受;另一方面,我们从流程角度往下看,流程是有一个个的任务基于不同的业务逻辑规则串接起来的,如何才能进一步看清楚这些业务任务,如何确保流程中各个任务的粒度的一致性,不同流程的流程任务的粒度一致性,我们不得不将任务进行进一步的打开。将业务流程折叠起来,就是我们所称的业务活动,通常一个业务活动由一到多个业务流程构成,通过折叠端到端的业务流程为业务活动,我们可以从更高的视角来审视我们的业务。业务活动是企业的成本项,需要付出人力和系统资源来实现这些业务流程,那么勿容置疑,我们就潜在地要求这些业务活动必须要带来业务价值,而且要最大化地带来价值,即在合规的情况下,尽可能付出少的成本获得最大化价值。一个业务活动,要么为企业带来收益,要么帮助企业降低成本,要么能确保企业合规运营,或者是能够带来社会价值,比如ESG可持续性。我们从客户细分市场和企业的视角来看这些业务活动流,将多个相关的业务活动按照价值递增的过程串接起来,这就形成了企业的业务价值流,如果将相关合作企业之间的价值流转和增值过程串接起来,就形成跨企业的价值链地图。另一个方面,针对一个业务流程里面的任务,我们采用什么样的粒度去建模,才是合理的,才能符合架构的基本原则,如高内聚松耦合,关注点分离原则。在2000年初的SOA和BPM时代,业务流程中的任务在实践中可以是一个外部系统webservice调用,或者传统接口的一次适配调用,甚至是一段可执行的代码片段,那时我们关注的是业务流程是否能够顺畅的运行和结束,关注的是集成,关注的是充分利用已有的系统投资,关注的是流程所支持的业务应用,我们往往忽略了业务的本质,业务的内聚性。这也是一个技术和认知进步的过程,随着互联网业务的发展,面对海量的互联网用户和资源需求时,互联网企业不得不抛弃传统行业的IT建设思路,由于没有历史包袱,互联网企业可以基于实践,面向市场,构建出全新的满足互联网高并发,横向可扩展,但又具有成本优势的分布式系统,支持微服务架构实践的各种技术栈,以及尤为重要的敏捷文化的实践。现如今的企业正都秉持着以用户为中心,由外而内重新架构整个企业,包括建设多云基础设施,挖掘数据价值,利用人工智能等革新技术重构业务活动,构建敏捷文化和组织,运用各现代化平台底座能力实现企业核心能力的现代化,构建以用户为中心,用户体验驱动的场景化,生态化数字产品和服务等。通过数字化转型培养企业新质生产力,已经成为当下各企业的战略主旋律。业务架构是整个企业战略和价值主张得以落地,确保企业可持续性发展的灵魂,在企业架构中扮演着承上启下的作用,企业战略和倡议可以体现在各个具体的业务模型中,而业务架构可以指导应用架构、数据架构,并间接影响到了技术架构的选择和规格要求。在传统的业务架构活动中,我们在进行流程建模的同时,还需要建模业务对象实体,并建模这些业务对象的监护主体,即相关的业务组件,我们通过流程将业务组件对外提供的服务能力进行串接使用,在使用业务组件时,基于业务对象实体和组件域的规则实现对我提供的服务能力。然而,同一个行业各个业务组件粒度的选择、划定也会因人而异,因企业而不同。我们可以总结上述现在企业在业务建模时面临的问题:1. 业务建模如何向用户再走进一步,向生态再走进一步?2. 业务建模如何融合数据和人工智能,特别是生成式人工智能,提升用户体验,提升企业生产力和价值产出?3. 如何构建开放标准化的企业服务能力,以融入生态,适应技术的进步和市场的发展?为了回答这三个问题,我们需要引入业务架构思维新范式。

范式一:由外而内,以用户为中心,用户体验驱动来重新架构企业业务流程活动。
范式二:以AI+的思维重新思考我们的业务流程,不论是跟客户运营相关的,还是企业内部运营相关的。
范式三:基于开放标准构建企业级能力,实现积木式创新。
范式一和范式二,我们都可以采用设计思维,从用户的角度去重构企业的业务流程,AI及智能自动化作为数字劳动力可以参与到新的业务流程数字化重塑中。
我们重点讲一下范式三,如何构建开放标准的企业级积木能力,实现积木式业务流程和场景应用的创新。
前面也提到了,传统上的业务流程,我们只关注流程能够跑起来,流程没有断点,没有太关注于流程节点的服务标准化问题,也就是某个流程节点所使用的服务也可以在其他的流程节点上被使用,现代的中台思想也是寄希望于建立共用的业务能力中心,实现对多流程上节点的共性支撑,那么如何划分能力中心呢,业界实践出了基于事件风暴进行业务建模、领域驱动设计进行IT设计,通过确定出限界上下文以划分能力中心边界的思路。在限界上下文下,大家统一语言,跨限界上下文基于一定的集成模式实现隔离。领域驱动设计从实践出发,驱动架构的迭代涌现设计,但边界划分带有较强的主观性和试验性。为了更加标准地划分领域边界,我们可以引入一个新的思维,其出自银行业架构网络(Banking Industry Architecture Network,BIAN),是对其参考业务架构框架标准进行基本业务能力划分的思维模式。其思维的核心认为,任何一个基本的业务能力需要具备唯一稳定的业务职责或角色,体现了最基本的价值创造。作为最基本的能力,其体现在标准的交互模式作用在企业最基本的资产上,创造最基本的业务价值,如上图所示,基本资产+标准行为=服务域。
标准交互模式作用于企业最基本的资产上,构成了基本的业务能力或业务组件,这里称为服务域。整个企业业务能力可以按照资产进行逐层分解,确保满足MECE(Muturlly Exclusive, Collectively Exaustive)原则,即相互独立、完全穷尽的原则,分解到一个具备单一业务含义的资产,在这样的基本业务级别,如果再进一步分解就会分解成公用utility级别了,按此原则分解的资产再作用以标准的交互模式,比如指导、设计、管理、操作、分析,就形成了不同业务职责或角色的基本能力构建块,即服务域。以客户关系资产为例,作用以运营管理交互模式,则形成客户关系管理服务域;作用以注册交互模式,则形成参与方数据管理服务域;作用以分析交互模式,则形成客户行为洞察服务域和客户信用评级服务域;作用以同意条款交互模式,则形成客户协议服务域。每个服务域都进行相关服务域实例的全生命周期管理,并以此对外提供服务,其也可以消费(或代理)其他服务域提供的服务完成其自身状态的管理。进一步地,某种交互模式可以用一组标准动词来表示,由此就可以按照统一的模式构建出服务域的标准化服务操作接口。基于这样的原理,可以将某个行业的基本能力标准化为一个服务域组合,由于分解到的资产符合MECE原则,作用的交互模式也是相互正交没有重合且完备的,形成的服务域的组合就也是符合MECE原则的,我们称之为服务图景。以这种方法得到的某个行业的服务图景、服务域、服务操作是稳定的,标准的,再结合统一的数据建模方法构建出各个服务域的业务对象模型,后者我们这里不做深入解释,两者结合就可以作为行业的参考架构使用。按照这样的参考架构设计应用架构的服务中心,其业务边界划分和范围定义是明确的,稳定的,可以为跨业务域的业务场景、业务流程提供稳定的、共享的基本能力构建块支撑。这样的业务边界划分方法和架构实践已经在不少银行进行了实践,跟DDD方法一起使用,得到了非常积极正面的评价。银行业架构网络的第二版也正在翻译成中文版本,中文版的书名是《银行业架构网络BIAN:全球数字化时代金融服务业框架》,有兴趣的读者可以期待这本书八月份同读者们见面。
