零代码、低成本快速创建采集表
基于大数据引擎，通过可视化组件、托拉拽式实现数据汇聚与集成开发
指标定义、指标建模、指标固化、指标分析，一体化完成指标的落地与应用
组件化、零sql实现各类复杂报表和丰富多样的图表分析
面向业务人员，简单拖拽即可生成可视化图表
内置150+特效组件，快速打造酷炫灵动的可视化大屏，支持在线编码，拓展视觉体验至极致
搭载自然语言分析引擎，引入AI大模型技术，通过简单的对话问答实现快速数据分析
移动采集、审批、分析一站式解决移动办公诉求
一站式数据分析平台
了解ABI
全程“零”编码，高效实现主数据模型、主数据维护、主数据分发、主数据质量的全过程管理，为企业主数据管理落地提供有效支撑，实现各业务系统间的主数据共享，保障企业主数据的唯一性、准确性、一致性。
内置多类主数据模版，可视化实现多视角模型定义，满足复杂规则的编码自动控制
多种数据接入方式，支持不同场景的审批管控，数据版本可回溯，满足主数据的全生命周期管理
拖拽式任务设计，内置丰富组件，支持主动式、被动式分发模式
全过程质量管控，支持内置及自定义规则，提供图表式质检报告
主数据管理平台
在线模型设计，深度融合数据标准，规范数据定义
自动化元数据感知，全链路血缘提取，理清数据资源
智能化标准推荐，一键式数据落标，树立数据权威
“零”编码规则搭建，全流程质量整改，高速数据质检
规范资产目录，自助式数据共享，释放资产价值
基于大数据引擎，通过可视化组件、托拉拽式实现数据汇聚与集成开发
超30+主流数据库、国产库、大数据库、文件、消息队列等接口之间极速交换结构化、非结构化数据
构建分级分类体系，动态数据脱敏，保障数据安全
全盘监控数据，决策数据周期，释放数据资源
智能数据治理平台
了解睿治
覆盖数据建模、采集、处理、集成、共享、交换、安全脱敏于一体，一站式解决数据开发所有的问题。
结合标准体系的可视化建模工具，支持模型的正、逆向构建
拖拽式任务编排，内置丰富组件，支撑亿级数据的快速处理与迁移
具备高并发、高吞吐量、低延迟的一体化任务编排能力，可视化设计、分布式运行
提供图形化的任务监控和日志跟踪，面向运维、管理人员的完善监控体系
数据工厂系统
纯web设计器，零编码完成基本表、变长表、中国式复杂报表、套打表、问卷调查表等制作；支持年报、月报、日报，以及自定义报表期等多种数据采集报送频率
提供在线填报和离线填报两种应用模式，也支持跨数据源取数；填报数据自动缓存在WEB浏览器中，即使宕机也不会丢失
内置灵活轻便的工作流引擎，实现了用户业务过程的自动化；支持层层审批、上级审批、越级审批、自定义审批等多种审批方式
对于下级填报单位上报的数据，上级汇总单位可将其进行汇总；支持层层汇总、直接下级汇总、选择单位汇总、按条件汇总、按代码组汇总、按关键字汇总、自定义汇总等
提供数据锁定机制，防止报表数据被意外修改；支持数据留痕，辅助用户过程追溯；未及时上报的用户自动催报；所见即所得的打印输出等
提供多种类型的数据接口，可以导入EXCEL、DBF、二进制、文本等格式的数据，可以将报表数据批量输出为HTML、EXCEL、XML、TXT等格式
数据采集汇总平台
统一指标定义，实现“一变多变、一数多现”的数据管理效果，为企业提供强有力的数字化保障和驱动效应。
采用可视化、导向式方式构建指标业务域，形成指标地图，全局指标一览在目
流程化自助式的定义、开发、维护各类指标，零建模，业务人员即刻上手
助力企业更好地查询、使用指标，提供共享、交换、订阅、分析、API接口等应用服务
指标管理平台
企业级智能体平台，低门槛搭建智能体，灵活编排流程，融合 LLM 实现“问数”、“问知识”
面向业务的对话式问数，即问即答，更懂你的诉求
理解数据，洞察数据，更懂数据内容，把数据见解讲给你听
动态地分析数据特点，提供最合适的图表类型展示，让数据展现更简单
完全是颠覆做表的方式，一句话看板创建，启发式内容制作
智能化生成包含深入分析和建议的报告，复杂数据简单化，释放数据潜力
数据跃然屏上的AI大屏汇报，让数据讲述故事
海量知识，一触即达，提供更智能的知识检索服务，快速找到“对”的人
不止于工具，更是随时待命的得力助手。一声指令，为您提供即时的数据分析和决策支持
智能数据问答平台
面向企业级数据资产交易运营场景，助力企业实现数据资产的价值挖掘、升值和资产变现。
提供上百类数据交换、汇聚、处理能力；零代码数据模型开发。
全链路数据治理，把控资产质量，理清资产血缘。
定义、盘点、规划无序的数据类和应用类资源，构建数据资产管理体系。
提供数据资源门户，及数据API、数据服务等快速检索能力；动态脱敏、加密保障数据安全。
提供用户注册、审批、订购等一体化管理，持续提升企业数据资产价值。
数据资产运营平台
从采、存、管、用四大方面构建数据治理体系，实现数字化经营
主数据全生命周期管理，保障主数据一致性、权威性、共享性，提高企业运营效率
以元数据管理摸清家底，以资产编目盘点数据资产，提供数据服务
集数据采集补录、数据ETL建模、数据实时存储、数据分析展现等应用场景于一体
集数据集成、数据治理、资产规划开发、资产运营等场景应用于一体
集元数据采集和规整、数据标准建立与评估、数据质量管控等场景应用于一体
面向业务和技术提供指标管理指标分析等服务的指标统一管理平台
涵盖数据存储、数据集成、数据交换、数据共享等方面，为企业用户提供云原生仓湖一体解决方案
提供数据全生命周期过程的数据服务手段，实现数据应用到数据运营
基于大模型AI的智能化低代码数据开发平台,助力企业高效构建现代化数据仓库、数据湖
基于大模型（LLM）与BI引擎深度融合的新一代数据智能平台，致力于打造会说话的数据助手
构建标准化的高质量数据集体系，打通从采集到训练的全链路
案例中心
学习中心
认证中心
培训活动
亿信社区
伙伴招募
供应商招募
了解亿信
亿信动态
亿信ABI
数据治理
产品解决方案
金融
租赁
医疗卫生
制造
能源
教育
央国企
其他
案例中心
学习中心
认证中心
培训活动
亿信社区
伙伴招募
供应商招募
了解亿信
亿信动态
IDC蝉联数据治理解决方案市场第一
一、元模型定义
“元模型（Meta Model）又称“模型的模型”，通常用于定义模型中具有哪些基本元素、元素之间的关系或者关系表示，是比模型抽象度更高的模型表示或者模型定义。之前介绍过的DoDAF就是一种以元模型为核心的架构构建方法。TOGAF也定义了自己的内容元模型，以表明业务架构、应用架构、数据架构和技术架构的核心内容及相互之间的关系。
元模型体现了方法论的架构观，即方法论是如何理解设计对象的。这一定义源自笔者对“世界观”的理解，所谓“世界观”就是基于对世界的观察而形成的对世界的观念，也即对世界的理解。根据观察，如果认为地球是绕着太阳转的，对应的世界观就是“日心说”；如果认为太阳是绕着地球转的，对应的世界观就是“地心说”。“世界观”通常不是一个观点，而是一组相互关联的观点体系。
“当我们思考设计对象的架构时也是如此，架构观就是基于对设计对象的观察而形成的对设计对象的理解。观察都需要视角，架构观主要受观察视角的影响，对于架构设计而言，基础的视角就是侧重于分析设计对象的结构、关系、演进原则，架构师可以从这几个点出发去理解所有设计对象。基于此形成的架构观，就是反映了设计对象的结构、内外部关系以及演进原则的一组观点体系。
基于该观念，架构高阶元模型如图4-1所示。”
“这个高阶元模型说明，事物都是由不同的构件组成的，构件之间具有相互联系，事物拥有或者可以为其设计作用于其构件的规律，架构设计的任务就是处理好这些关键点。
以高阶元模型为基础，可以产生各种实例的元模型，比如TOGAF内容元模型、FSDM的九大领域、DoDAF元模型、价值链高阶模型等，这些都可以归类为这一高阶元模型的元模型实例，图3-1，也是一个元模型实例。这有些类似“道生一、一生二、二生三”的逻辑，“道”就是架构观，“一”就是架构高阶元模型，二、三就是元模型实例。在本章中提出的企业架构元模型也属于高阶元模型的一种实例。
“以高阶元模型的抽象结构为指导，本书基于笔者的实践与思考，采用了面向数字化生态、面向战略、面向构件的思路，以业务架构为核心构建了企业架构的元模型，以明确企业架构设计的核心要素及其关系。该企业架构元模型如图4-2所示。
图4-2中的战略元模型、组织元模型、业务元模型和业务构件元模型都属于业务架构元模型。按照笔者观点，这是传统业务架构与数据架构融合后的业务架构，应用架构元模型承接业务架构元模型，技术架构元模型实现应用架构元模型并在一定程度上受到业务架构元模型的约束。
“图中标记了五角星的元素，为该元模型相较以往的方法论重点改良的元素。未标注连线的元素之间可以通过其共同连接的元素传递连接关系，比如“组织元模型”中“岗位”执行“业务服务”，“业务服务”活动于“空间”，可以认为“岗位”也是活动于“空间”的，这种关系与数据建模中数据实体之间的关系类似，毕竟元模型本身也可以视为一种数据模型。4.3节将分别介绍元模型的各个组成部分。”
“战略是企业发展的方向性指导，也是凝聚企业力量的关键，很多互联网企业都非常重视自身战略管理能力的建设，尤其是会影响企业文化的愿景、价值观等的能力。
“根据TOGAF的定义，企业是具有相同目标的一系列组织的集合。这是一个外延很宽的定义，并非特指通常认为的生产性、经营性企业。根据这个定义，企业其实本就没有内外部之分，而是一个目标导向的非固化集合体，很有今天常说的生态型、开放型企业的意味。”
“业务是企业实际的价值创造过程，是岗位通过一定的服务方式为用户（含内部）实现价值的过程。在某些行业中，这个过程可能很长，比如医疗行业为慢性病患者提供的治疗服务；而在另一些行业，这个过程可能非常短暂，比如互联网内容服务商提供的短视频服务。但是抽象来讲，所有的业务都是由用户、岗位、规则、服务、数据和空间等元素组织起来的。这些内容加起来，更像是今天大家常提及的“场景”，“场景”其实是一个影视剧术语，指在一定的时间、空间（主要是空间）内发生的一定的任务行动或因人物关系而构成的具体生活画面。
“1）业务规则。业务规则是由岗位制定的，是业务服务过程中必须遵守的约定，既包括常见的业务制度，如银行中大量的内部经营管理制度，也包括产品服务承诺，比如快递送达时间的承诺，以及数字化产品中经常出现的算法规则，比如用户画像到产品推荐过程中的各种算法，这些算法并没有被抽象成制度，但实际上比制度的可执行性、约束力更强。业务规则一旦形成，也会形成对岗位的约束。
2）业务活动。业务活动通常是由岗位遵循一定的业务规则执行的业务过程。从抽象角度讲，企业对外的营销活动、产品服务、售后服务、监管报送等，企业内部的战略制定、落实监督、目标制定、目标考核、架构设计、方法论研究等都属于业务活动。业务活动的服务对象可以是外部用户，也可以是内部岗位，业务活动总是在一定的空间中进行的。
“业务活动会生产或消费（经常同时进行）业务对象。业务活动可以根据需要聚合成业务领域，也即，业务领域实际上是多个业务活动的聚类。从抽象角度讲，如果一个领域内的多个活动可以“无缝”连接，那一个业务领域实际上就是一个很长的、端到端的业务活动。经常有读者询问笔者关于业务领域的定义原则，在笔者看来，业务领域其实不需要特别明确的定义，它是业务活动的灵活聚合，类似组织单元与岗位的关系，细分的业务活动和业务对象是相对稳定的，业务领域可以根据战略、组织单元和对用户的理解进行灵活的定义与调整。
“业务活动与业务对象的关系识别就是实现“一切业务数据化，一切数据业务化”的起点。知识服务是企业转变成知识型企业所必须建立的业务活动，所以，知识也是很重要的业务对象。严格来说，“愿景、价值观”“战略”“战略能力”也属于业务对象，”
“但考虑到上述元素的重要性以及让元模型更容易理解等因素，我们将它们与业务对象分开描述。
业务对象（Business Object，BO）一词在软件设计中也指对数据进行检索和处理的组件，包含状态与行为两部分，但是笔者本处使用该词仅指业务人员对业务处理对象的认知，是数据模型建立初期的识别过程的产物，是用于后续细化数据实体的输入。
业务对象也有聚合能力，可以向上聚合成更高阶的业务对象主题域，而是否要执行这一聚合则是可选项，执行聚合通常是指为了更好地确认业务对象之间的关系和业务对象识别的完整性。”
“业务构件是业务架构中构件设计的关键，是提炼用于组装业务服务的基础元素。”
“1）业务构件。业务活动可以发生一定的变化，与支持活动的基础能力相比，业务活动是不够稳定且可变的，如同岗位与组织之间的关系。业务构件是对业务行为和业务数据的“封装”，战略能力通过岗位传递到岗位执行的业务活动上，进而沉淀在业务构件中包含的业务能力上。业务构件可以按照业务活动的需要进行组装，这是对业务的结构化。业务构件可以聚合成业务组件，聚合的依据则是不同业务构件包含的业务数据之间的业务关系。这种定义要遵从业务的理解，其表达也应是业务人员可以理解的。业务构件的设计要尽可能减少行为重叠，行为重叠会造成资源浪费。但在实际业务中，完全不重叠可能较难实现。尽可能避免数据重叠，数据重叠会造成耦合，并向开发侧传递数据一致性问题。业务构件应尽可能被技术人员以系统化的方式实现，但并非所有业务构件都可以实现系统化。
2）业务任务。业务任务是实现业务预想结果所必须执行的一系列动作，可以固化成一段操作过程、一个具体的操作动作或一连串软件行为。业务任务在执行过程中会消费或产生一定的业务数据，无论是否是由业务系统支持的执行过程。可能有一些业务行为不易数据化，比如与用户共情，但是不应放弃以数据进行描述的努力。业务规则也可以被直接实现为业务行为，比如特定风控规则的实现会表现为针对特定场景的风控行为。
“业务架构设计是结构化分析、设计企业整体业务能力的过程，包括了对战略、组织、业务、构件的分析与连接。本书提出的业务架构元模型所代表的业务架构设计模式并非全新的、颠覆性的业务架构设计模式，依然是在传统企业架构方法论上的演进，其自身的特点主要集中体现在对业务的深入构件设计上，这是实现真正的构件开发模式的基础。以往的构件开发实践（模块化、SOA、微服务等）在业务侧的分析不足，更多聚焦在技术侧的设计，缺少对业务人员结构化思维的培养和对业务自身的构件设计。如果业务自身没有很好地进行构件设计，通常技术侧也不会产生好的构件设计。”
“应用架构是业务架构与技术架构的连接环节，业务的结构化分析成果通过应用架构转化为逻辑服务、逻辑数据并由技术架构最终实现。经过应用架构设计，业务需求转化为技术需求，尤其是功能性需求，因此元模型也聚焦于功能性需求的连接上。应用架构元模型如图4-8所示。
1）逻辑功能。逻辑功能是根据业务任务设计的，逻辑功能会生产或消费一定的逻辑数据，因为是面向系统设计的，所以逻辑功能必须生产或消费逻辑数据。逻辑功能会组成应用构件。业务任务与逻辑功能之间可以不是严格的一对一关系，但考虑到整体能力地图的清晰性，应该尽可能保持业务能力对逻辑功能的一对一、一对多关系（以一对一关系为主，一对多关系主要是考虑实现的制约）；应尽可能减少业务能力对逻辑功能的多对一关系，这种关系意味着业务构件的边界重叠。
“2）逻辑数据。逻辑数据同样是逻辑级数据模型，但是考虑到设计实现，与业务数据相比，可以适当进行“降范”，考虑派生数据等，并允许一定程度上的冗余，但这不意味着无限放开冗余，而是在考虑设计必要性时放开。主题域由业务数据聚合而成，逻辑数据是“降范”的业务数据，因而不再考虑通过聚合的方式定义这一层级的主题域。
3）应用构件。应用构件是对逻辑功能和逻辑数据的“封装”，是技术层面设计的“积木块”，是构件设计在技术侧的体现。应用构件的设计要以业务构件为指导，尽可能保持一致，以确保业务侧对业务构件的可组装预期能够顺利过渡到技术侧对应用构件的可调用设计。应用构件可以聚合成应用组件（相当于逻辑子系统），组件可以辅助开发任务的分工。组件可以再聚合成应用架构的分层，但是应用架构的分层无须在元模型层级展现。”
“4）应用编排。业务活动通常是经过一定的过程来实现的，在业务侧，笔者将其定义为业务活动对业务构件的组装；在技术侧，笔者将其定义为应用编排对应用构件的调用。应用编排反映了技术侧对业务活动过程的实现，但需要注意的是，业务活动的范围可能大于应用编排，这意味着存在线上线下协同的场景。此外，应用编排也有可能出现不同层级的调用，也即，应用编排可能调用其他应用编排，这通常意味着更大范围的业务活动之间的组合。但是，考虑到应用的不稳定性，设计过于复杂的应用间调用需要慎重。”
“技术架构是对应用架构的物理实现。技术架构本身是非常复杂的，但是考虑到元模型面向的是企业中业务和技术两侧，因此技术架构中对元模型要素进行了高度简化。技术架构元模型如图4-9所示。
2）技术平台。技术平台用于实现物理构件（或者聚合后的物理组件），可以基于特定技术类型建立平台，如人工智能、区块链、大数据等平台；也可以基于语言类型划分业务功能平台，如C语言、Java语言等平台；也可以基于特定目的建立平台，如监控平台、任务调度平台等。技术平台还可以聚类成技术架构的分层，但技术架构的分层属于聚合元素，无须在元模型层级展现。”
“出于对数字化转型的特殊考虑，虚拟空间构建技术是未来技术发展的焦点，因此，战略元模型中的“空间”元素越过了“应用架构元模型”，直接对应到了“技术架构元模型”中的“技术平台”上，这也反应了业务架构与技术架构之间的联系方式。搭建虚拟空间需要的技术平台应该在企业实力允许的情况下，以战略级的发展要求进行尝试。
“构件设计并非只是技术侧的问题，而是需要业务与技术两侧的共同努力，因此，从业务架构开始，有一条关键链条影响着构件设计的最终实现效果，如图4-10所示。
“这个关键链条上元素定义的一致性或者说映射关系的清晰性决定了构件设计的最终效果，以往的企业架构设计或者软件设计没有很好地解决从战略分析开始到最后技术实现方面的一致性问题。元模型并不意味着软件设计会被复杂化，因为无论采用何种策略进行软件开发，最终开发结果都会映射到这些元素上，而难以令人满意的开发结果往往会缺少该链条中的某些元素，或者没有做好某些元素的设计。我们没有任何理由忽略这些设计元素，任何对这些元素的忽略最终都会导致技术债务。同样，元模型也不意味着软件设计会大幅度简化，而是更加清楚地展示了重要的元素及其关系，加强架构师、开发人员对设计重点的关注，提供一个更有效率的分析路径。
从这个链条上看，详细分解战略能力、标准化岗位设计、持续优化业务流程、标准化管理企业数据、与业务保持一定程度的一致性去设计应用构件，是实现高效的构件开发的必要条件，这也是其他开发模式不可忽略的要素。当然，这并不意味着没有对这些元素的万全设计，就不能进行软件开发，而是应当通过元模型使我们对架构关键点的认识更清晰，知道有哪些“坑”需要持续去填，也知道填“坑”的意义。”
“1.总体原则
1）尽可能遵循康威定律，以弥合组织与系统之间存在的差异。
2）在总体上尽可能考虑基于构件的设计，以便扩展。
3）企业架构的分析过程中尽可能保持行为（业务）与数据的强关联。
4）企业架构设计尽可能保持简洁，突出关键要素，不要在企业复杂度上额外叠加架构复杂度。
5）企业架构设计本身不会替代需求分析，不必增加过多细节。
2.操作性原则
1）业务架构必须可以被业务人员理解并认可，因为这是对业务的结构化过程。
2）业务架构面向的是企业全部业务，因此，业务架构范围可以大于应用架构范围。
3）愿景应当具有一定的用户指向。
4）价值观必须是由企业领导者带头实践的。
11）为了支持组织单元的灵活性，岗位必须相对具有更好的稳定性，岗位必须承载战略能力并且容易被识别，以支持对组织单元的灵活聚合。
12）业务规则最好能够进行适度的抽象和剥离，以便与业务活动、业务任务进行结合和调整。
14）业务活动可以聚合成业务领域，这将保持业务领域的灵活性。
15）业务构件应当同时包含业务任务和业务数据，这样的构件才是独立而完整的。
16）业务构件设计应当减少构件之间业务能力的重叠，避免构件之间业务数据的重叠。
17）业务构件可以聚合成业务组件，聚类主要依据其包含的业务数据对应的业务关系。
18）业务构件应尽可能被系统化实现。
19）战略能力最终应当沉淀在业务任务和业务数据上。
20）业务数据必须具有企业级的唯一性定义，应尽可能将业务对象数据化。
21）业务任务到逻辑功能应尽可能保持一对一或一对多关系（以一对一关系为主，一对多关系主要是考虑实现的制约），尽可能减少逻辑功能到业务能力的一对多关系。
22）逻辑数据允许“降范”设计，但是不意味着无限放开。
23）应用构件的设计应尽可能与业务构件保持一致。
24）应用之间可以互相调用，但设计复杂的应用间调用应当慎重，设计应用间调用时要考虑被调用对象的变化是否需要传给调用者，如不需要，意味着不做应用间调用更合适。”