CBF Studio是什么？能提供什么样的能力？
在解答标题内容前，需要了解传统业务需求的提出到落地的实施过程。一般来说它分为以下几个阶段：
- 业务人员提出需求
- IT人员根据需求进行设计
- 设计完成后交付测试中心进行部署测试
- 测试通过后交付数据中心进行部署投产
在未来这样的实施过程会发生一些变化，它演变成了如下几个阶段：
- 战略层提出愿景（明确为实现战略愿景需要具备的业务能力）
- 工程实施：
a）企业级的架构设计；
b）实施领域级项目； - 发布、部署、测试、投产等环节
在做企业级架构设计时，就要明确需求在整个企业级架构中的定位，为满足需求需要在企业级架构层面进行哪些补充（过去这部分工作比较弱，原因在于具备企业级架构能力的资源很少，如果实施方法不当，后期维护成本反而更高，对企业级架构的重视程度不高）。领域级项目实施又会分为以下几个环节：
- 提出业务需求即业务建模
- IT部门介入即IT建模
- 低代码开发
过去的需求以文档的方式承载，而业务建模是结构化的业务需求的提出，这个过程叫业务建模，成果是业务模型，业务模型成果就是一些业务元素以及元素之间的关系，业务模型能够更加直观的表达需求。在行业标准中业务模型被划分成四类即：业务流程模型、业务数据模型、产品模型和用户界面体验模型，这四类模型设计完成，业务需求就可以阐述的很清晰了。
业务建模结束后，IT部门就要开始介入了。在过去IT部门拿到需求后需要转化成解决方案即概要设计、详细设计方案等等，载体依然是文档。现在也变成了结构化的IT解决方案即IT模型，包括IT数据对象模型和应用模型。应用模型描述的是做哪些应用系统，系统中包含哪些组件，组件中包含哪些应用程序，程序之间的关系如何。
最后一个环节就是程序处理流程，过往是通过编码方式实现的，现在转为低代码方式来完成。图形化的、结构化的低代码开发语言对开发人员的技能要求有所降低，甚至业务人员也可以进行设计。
可以看出这是一种全新的工艺流程，从提出需求到需求落地的过程可以参考下图：
不过即使业务需求的提出到落地转变成了新的模式，但没有合适的工具帮助企业来承载模型设计成果，各阶段的成果不能有效的串联起来，就不能很好的提升协作效率，也很难保证最终成果的品质。因此我们研发了CBF Studio，它就是为了让工程实施环节即业务建模、IT建模开发、部署和测试等环节获得最高的自动化程度、协作效率、成果的品质和价值，而研发的一套工具。
使用CBF Studio的用户角色很多，并不同传统的编程人员，包括了企业级架构师即规划人员、业务设计人员、IT部门的架构师和开发人员等等，他们都会在平台上工作，这些角色通过统一的、结构化的语言来分享和衔接设计成果，从而以模型驱动、架构驱动的方式来实现业务需求。
显而易见的，团队的规模愈大，那么CBF Studio带来的收益提升效果愈发显著。中国金融新闻网一篇名为《深入实施新阶段金融科技发展规划 高质量推进数字化转型》的文章中就介绍说：
在战略部署方面，建立健全企业级数字化转型组织架构和治理机制，通过数字化能力成熟度评价等方式科学衡量转型质效，找准行业标杆、明确发力方向，因企制宜制定数字化转型策略与实施路径，构建涵盖规划、生产、管理等职能的特色化发展矩阵，为科技创新在制度、组织、流程方面留足空间。在敏捷创新方面，探索数字化工厂、创新实验室等创新模式，通过设立创新项目基金、孵化平台等方式健全企业级创新试错容错与激励机制，合理运用业务开发运维一体化、低代码等手段提升快速交付能力，建立技术与业务高效联动、前中后台密切协作、决策与执行高度统一的创新协同网络，更好满足数字经济时代灵活多变的市场需求与用户诉求。在中台建设方面，采用低耦合、高内聚架构搭建便捷易用的技术中台，打造模块化、可定制、高复用的业务中台，构建集成数据整合、提纯加工、建模分析、质量管控、可视交互等功能的综合型数据中台，健全一体化运营中台体系，更有力地赋能产品创新、提升研发质效、降低试错成本，推动业务数据化向数据业务化进阶发展。在业务赋能方面，运用知识图谱、机器人流程自动化等技术构建环节无缝衔接、信息实时交互、资源协同高效的运营模式，在依法合规前提下基于海量多维数据深挖共性行为模式、升级智能风控模型、优化金融服务策略，构建覆盖用户全生命周期、业务全流程的数字化经营能力，提升业务运营、用户管理、风险防控等的前瞻性、精准性和有效性。
CBF Studio正是这样一种能够真正帮助企业平滑的完成数字化转型的工具。最近出现了一个新的名词：BizDevOps，也叫DevOps2，即Business（业务）+ Development（开发）+ Operations（运营），从这个角度来看，CBFSutido是一个典型的BizDevOps平台。
使用CBF Studio建模如何对应行业建模标准？
在CBF Studio上的模型成果被分为两大层面：架构模型和应用程序。架构模型包含业务、数据和应用三个维度，并把三个维度的模型打通，使其相互关系能够得到妥善管理。三个维度的模型和工程实施环节的对应关系如下图所示：
从上图可以看到，做业务建模时，覆盖了业务架构、部分数据架构和少量应用架构模型。做IT建模时仅覆盖了绝大部分的应用架构和部分数据架构。
之所以数据架构在业务建模和IT建模中都有涉及，是因为数据架构中包含了业务数据模型和IT数据模型，数据建模有A、B、C、C’、D五级模型，C级就是业务数据模型，是有属性、有关系的逻辑数据模型，那么为了便于应用开发，或者提升运行效率，还需要对C级模型进行扩充，在补充了一些和IT设计相关的实体、属性和关系后，就形成了C’级模型。
应用架构的少部分出现在业务建模中，是因为行业建模标准中提及的用户界面体验模型是由应用架构中的前端程序来提供相应能力支撑的。
那么业务建模都包含哪些内容呢，可以参考下图：
首先要对产品模型做一个解释，根据行业建模标准来看，产品模型是业务流程模型、业务数据模型和用户体验模型中和产品有关的那些模型，一般来说产品主题域下的数据模型都归属于产品模型，构成了产品模型的主体。
业务流程模型是从最初的价值链开始，逐步的分解到很细致的、局部的流程模型，因此需要分级，同数据模型分级一样也分为五级，分别对应业务领域、业务阶段、活动、任务和步骤。比如说信贷业务领域，按生命周来看，还需要分为贷前、贷中、贷后三个阶段，理财业务也是同样分为投前、投中、投后。再往下就是各阶段中能够确定的、能够工作的流程即活动，活动一个组织或部门为了处理一个事件，而执行的一个协同工作的过程，一般是需要多角色协同完成不同的任务。更低级别的是任务，是某个角色（包括系统）处理某个任务时内部的处理流程，如柜员存款就是一个任务。存库任务需要执行检查是否开户、账户是否列入黑名单、查询账户信息、输入存款金额、提交数据等逻辑规则，即五级流程即步骤。
只有业务流程是不够的，业务需求最终处理的是业务数据，因此必须要有业务数据模型的存在，业务需求的描述才是完整的。业务数据模型按照主题划分成不同的域，如产品、客户、渠道等等，就形成了主题域。再往下是业务对象（很容易和单一的业务数据发生混淆），它实际上是一组业务数据构成的包，如贷款产品业务对象，内部是和贷款产品相关的所有业务数据模型。最后是具体的数据定义了，其中一类数据定义是域即字段的定义，如卡号、客户号等，它包含了域值的规则，如长度、赋值约束等等；还有一类数据定义是实例组，实例组可以包含N个实例，是一种数据字典，如性别（包含男、女实例）、学历（包含高中、专科、本科等实例）等等。域、实例组常作为其他对象、实体的属性。
需要注意的是，上图中有些蓝底的架构元素如业务领域、业务阶段、主题域，这些类型的架构元素可以看作目录型元素，它本身不具备具体的数据信息，仅为了划分业务模型定义而存在，并且可以嵌套，如产品主题域下还可以继续划分中间业务、资产、负债子主题域。有些灰色底的架构元素如业务组件、业务对象，则是真正包含了业务模型定义的。
前文介绍过用户体验模型，它定义了人机交互的界面，由应用架构中前端程序来提供模型定义的能力。向导程序主处理过程主要解决的是通过菜单触发的应用界面的处理过程，事件处理指按钮和其他控件的点击、录入、拖拽等触发的事件的处理过程。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
