基于大数据引擎，通过可视化组件、托拉拽式实现数据汇聚与集成开发
指标定义、指标建模、指标固化、指标分析，一体化完成指标的落地与应用
组件化、零sql实现各类复杂报表和丰富多样的图表分析
面向业务人员，简单拖拽即可生成可视化图表
内置150+特效组件，快速打造酷炫灵动的可视化大屏，支持在线编码，拓展视觉体验至极致
搭载自然语言分析引擎，引入AI大模型技术，通过简单的对话问答实现快速数据分析
移动采集、审批、分析一站式解决移动办公诉求
一站式数据分析平台
了解ABI
全程“零”编码，高效实现主数据模型、主数据维护、主数据分发、主数据质量的全过程管理，为企业主数据管理落地提供有效支撑，实现各业务系统间的主数据共享，保障企业主数据的唯一性、准确性、一致性。
内置多类主数据模版，可视化实现多视角模型定义，满足复杂规则的编码自动控制
多种数据接入方式，支持不同场景的审批管控，数据版本可回溯，满足主数据的全生命周期管理
拖拽式任务设计，内置丰富组件，支持主动式、被动式分发模式
全过程质量管控，支持内置及自定义规则，提供图表式质检报告
主数据管理平台
在线模型设计，深度融合数据标准，规范数据定义
自动化元数据感知，全链路血缘提取，理清数据资源
智能化标准推荐，一键式数据落标，树立数据权威
“零”编码规则搭建，全流程质量整改，高速数据质检
规范资产目录，自助式数据共享，释放资产价值
超30+主流数据库、国产库、大数据库、文件、消息队列等接口之间极速交换结构化、非结构化数据
构建分级分类体系，动态数据脱敏，保障数据安全
全盘监控数据，决策数据周期，释放数据资源
智能数据治理平台
了解睿治
覆盖数据建模、采集、处理、集成、共享、交换、安全脱敏于一体，一站式解决数据开发所有的问题。
结合标准体系的可视化建模工具，支持模型的正、逆向构建
拖拽式任务编排，内置丰富组件，支撑亿级数据的快速处理与迁移
具备高并发、高吞吐量、低延迟的一体化任务编排能力，可视化设计、分布式运行
提供图形化的任务监控和日志跟踪，面向运维、管理人员的完善监控体系
数据工厂系统
纯web设计器，零编码完成基本表、变长表、中国式复杂报表、套打表、问卷调查表等制作；支持年报、月报、日报，以及自定义报表期等多种数据采集报送频率
提供在线填报和离线填报两种应用模式，也支持跨数据源取数；填报数据自动缓存在WEB浏览器中，即使宕机也不会丢失
内置灵活轻便的工作流引擎，实现了用户业务过程的自动化；支持层层审批、上级审批、越级审批、自定义审批等多种审批方式
对于下级填报单位上报的数据，上级汇总单位可将其进行汇总；支持层层汇总、直接下级汇总、选择单位汇总、按条件汇总、按代码组汇总、按关键字汇总、自定义汇总等
提供数据锁定机制，防止报表数据被意外修改；支持数据留痕，辅助用户过程追溯；未及时上报的用户自动催报；所见即所得的打印输出等
提供多种类型的数据接口，可以导入EXCEL、DBF、二进制、文本等格式的数据，可以将报表数据批量输出为HTML、EXCEL、XML、TXT等格式
数据采集汇总平台
统一指标定义，实现“一变多变、一数多现”的数据管理效果，为企业提供强有力的数字化保障和驱动效应。
采用可视化、导向式方式构建指标业务域，形成指标地图，全局指标一览在目
流程化自助式的定义、开发、维护各类指标，零建模，业务人员即刻上手
助力企业更好地查询、使用指标，提供共享、交换、订阅、分析、API接口等应用服务
指标管理平台
零代码+AI，有“问”必答的数字助理，利用AI大模型和数字人技术，通过语音&文字输入问题，自动识别业务指令，深度理解用户意图的问题，洞察数据，人机交互，重新定义BI新体验。
面向业务的对话式问数，即问即答，更懂你的诉求
理解数据，洞察数据，更懂数据内容，把数据见解讲给你听
动态地分析数据特点，提供最合适的图表类型展示，让数据展现更简单
完全是颠覆做表的方式，一句话看板创建，启发式内容制作
智能化生成包含深入分析和建议的报告，复杂数据简单化，释放数据潜力
数据跃然屏上的AI大屏汇报，让数据讲述故事
海量知识，一触即达，提供更智能的知识检索服务，快速找到“对”的人
不止于工具，更是随时待命的得力助手。一声指令，为您提供即时的数据分析和决策支持
智能数据问答平台
从采、存、管、用四大方面构建数据治理体系，实现数字化经营
主数据全生命周期管理，保障主数据一致性、权威性、共享性，提高企业运营效率
以元数据管理摸清家底，以资产编目盘点数据资产，提供数据服务
集数据采集补录、数据ETL建模、数据实时存储、数据分析展现等应用场景于一体
集数据集成、数据治理、资产规划开发、资产运营等场景应用于一体
集元数据采集和规整、数据标准建立与评估、数据质量管控等场景应用于一体
面向业务和技术提供指标管理指标分析等服务的指标统一管理平台
涵盖数据存储、数据集成、数据交换、数据共享等方面，为企业用户提供云原生仓湖一体解决方案
提供数据全生命周期过程的数据服务手段，实现数据应用到数据运营
案例中心
学习中心
认证中心
培训活动
亿信社区
伙伴招募
供应商招募
了解亿信
亿信动态
亿信ABI
数据治理
产品解决方案
金融
租赁
医疗卫生
能源
制造
生态环境
政府
其他
IDC蝉联数据治理解决方案市场第一
网上关于应用架构的资料非常碎，因此我找了企业架构开发方法的权威TOGAF作为参考，把应用架构的交付物和端到端流程全部走了一遍，图文并茂，希望尽量用浅显易懂的方法把应用架构讲讲清楚。
TOGAF（TheOpenGroupArchitectureFramework）是一个工具集、术语集和流程集，提供了一个全面的方法来开发企业架构。TOGAF的中心是一个被称为"架构开发方法"（ArchitectureDevelopmentMethod，简称ADM）的流程，如下图所示：
描述业务功能、业务流程、事件、组织单位、角色、业务服务以及其他业务行为。
描述组织的物理和逻辑数据资产以及数据管理资源。
描述应用系统的总体结构和应用组件的相互关系。
描述硬件、软件、网络和其他技术资源的策略和标准。
定义支持应用架构运行所需的基础技术结构。
应用架构与其他三个架构有紧密联系：
1、业务架构定义了为什么要进行某项业务，并提供了业务需要什么样的信息支持（即数据架构）。
2、数据架构和应用架构合作，确保业务流程能够通过正确的信息系统得到所需的支持。应用架构定义了什么系统需要进行交互，以及这些系统如何与数据交互。
3、技术架构再进一步定义了如何实施应用架构，它描述了支持数据、应用和业务功能所需的基础技术。
这四个层次构成了企业架构的综合视图，它们共同工作，确保从高层的业务策略和要求到实际的技术实施都是对齐的。
应用架构在TOGAF中处于阶段C，专注于定义支持业务和数据处理所需的应用系统，它描述了应用系统之间、应用与用户之间的交互和行为。
那么，应用架构具体长啥样呢？
TOGAF提供了一个详细的架构工具模型，如下所示：
在阶段C，TOGAF定义了应用架构的主要交付物，共分目录、矩阵、图三类类型，总计14个制品：
1、目录：应用组合目录、接口目录
2、矩阵：系统/组织矩阵、角色/系统矩阵、系统/功能矩阵、应用互动矩阵
3、图：应用通信图、应用和用户位置图、系统用例图、企业可管理性图、流程/系统实现图、软件工程图、应用迁移图、软件分布图等
下面以案例的形式逐个说明这14个制品的具体内容，应用架构的最终交付物往往是这14个制品的编排组合：
假设我们有一个中型企业，该企业涉及以下几个核心业务领域：
（1）销售：负责产品的销售。
（2）人力资源：负责员工的招聘、培训和福利。
（3）财务：负责公司的财务管理，如支付、收款、预算和报表。
基于这三个业务领域，我们可以列出以下的应用组合目录：
在这个简化的应用组合目录中，我们可以清晰地看到每个应用支持哪个业务领域，它们的主要功能是什么，它们运行在哪些技术平台上，以及它们当前的生命周期状态。这有助于企业更好地管理其应用组合，理解各应用之间的关系和依赖性，并决定在哪里投资以支持未来的业务需求。请注意，实际的应用组合目录可能会包含更多的细节和其他信息，例如应用的拥有者、应用的使用频率、应用的维护成本等。
接口目录通常包括以下内容：
接口名称：一个简短、描述性的名称。
接口描述：接口的简短描述。
目标应用：接收或消费数据的应用名称。
接口协议：如HTTP、FTP、SOAP、REST等。
数据格式：如XML、JSON、CSV等。
数据内容：传输的数据的简短描述或摘要。
接口状态：如激活、待激活、已弃用等。
以下是一个简化的接口目录示例，假设我们之前提到的企业场景：
此接口目录提供了一个中心位置，用于管理和查看应用之间如何交互，使用哪些技术和协议，以及传输的数据内容是什么。这对于确保数据的一致性、减少接口冗余、理解和优化数据流程都是非常有用的。
系统/组织矩阵（System/OrganizationMatrix）是一个工具，用于显示各个组织部门或角色与系统之间的关系。该矩阵有助于理解哪些部门或角色使用或拥有哪些系统，从而可以更好地协调和规划业务和IT资源。
一个简单的系统/组织矩阵可能像这样：
在此示例中，我们可以看到：
销售部门使用销售管理系统和销售分析工具。
人力资源部门使用人力资源信息系统。
财务部门使用财务管理系统。
管理团队可以查看所有系统的信息，但可能没有完全的使用权限。
这种矩阵形式的表示方法为组织提供了一个清晰、简洁的视图，展示了各部门或角色与各系统之间的关系。这有助于确保系统的正确分配、减少重复投资、优化许可证成本，并确保适当的培训和支持。
角色/系统矩阵（Role/SystemMatrix）是一个工具，用于显示组织内各个角色与他们与系统的关系。这个矩阵有助于了解哪些角色需要访问哪些系统，以及他们对这些系统的具体使用模式（例如，查看、编辑、创建等）。
一个简单的角色/系统矩阵可能如下所示：
在此示例中，我们可以观察到：
销售代表需要在订单处理系统中创建和编辑数据，在人力资源管理系统中查看数据，并在客户关系管理系统中进行各种操作。
人力资源经理在人力资源管理系统中有广泛的权限，在财务系统中可以查看数据，并且可以在客户关系管理系统中查看数据。
财务分析师在订单处理系统中可以查看数据，在财务系统中有创建和编辑的权限，并且可以在客户关系管理系统中查看数据。
客户服务代表可以在订单处理系统和客户关系管理系统中查看和编辑数据。
这个矩阵为组织提供了一个简明扼要的方式，来展示不同角色如何与各种系统互动。这对于理解和管理权限、培训需求和审计跟踪都非常有帮助。
一个简单的系统/功能矩阵可能如下所示：
在此示例中：
电子商务系统提供了订单处理、库存管理和付款处理功能。
仓储管理系统专注于库存管理并提供报告生成功能。
财务系统处理付款并能够生成报告。
销售分析系统处理订单数据并提供报告功能。
通过这样的矩阵，组织可以清晰地看到各系统之间的功能交集或功能缺失，从而进行优化或整合。此外，当需要对某一功能进行更改或升级时，矩阵可以迅速提供哪些系统可能受到影响的信息。
应用互动矩阵（ApplicationInteractionMatrix）主要用于描述不同应用之间的交互和依赖关系。这种矩阵提供了一个结构化的方法来捕获和描述如何通过各种接口和服务在应用之间传递数据。
这种矩阵特别有助于：
（1）明确哪些应用需要与其他应用通信。
（2）确定数据流的方向和性质。
（3）提供有关应用如何协同工作以支持特定的业务流程的视图。
以下是一个简化的应用互动矩阵例子，假设一个制造企业有以下应用：
（1）销售系统
（2）生产计划系统
（3）仓储系统
（4）财务系统
矩阵可以如下：
解释：
（1）销售系统:
与生产计划系统交互：请求产品信息以确保产品可用性。
与仓储系统交互：查询库存确保产品库存量。
与财务系统交互：创建发票和管理付款。
（2）生产计划系统:
与销售系统交互：接受并处理销售订单。与仓储系统交互：基于需求和库存发出生产订单。与财务系统交互：查询产品的制造成本。
（3）仓储系统:
与销售系统交互：提供库存信息。与生产计划系统交互：接受并执行生产订单。与财务系统交互：提供库存产品的成本信息。
（4）财务系统:
应用通信图（ApplicationCommunicationDiagram）描述了应用组件之间的通信关系。这些关系可以是调用、数据流或其他形式的连接。这种图有助于展示系统和应用之间的交互模式，以及它们是如何支持业务功能和进程的。
应用通信图通常包含以下元素：
（1）应用组件：如系统、模块或其他应用单位。
（2）通信关系：如数据流、调用或消息传递。
（3）可选地，外部用户或系统和其他接口。
案例描述：
假设一个简化的电商平台包含以下应用组件：
（1）客户前端（CustomerFrontend）
（2）订单管理系统（OrderManagementSystem）
（3）仓库管理系统（WarehouseManagementSystem）
（4）付款网关（PaymentGateway）
在应用通信图上，它们的交互可以描述如下：
（1）客户前端
用户在这里浏览产品、添加到购物车并下单。当用户下单时，前端与订单管理系统通信，提交订单详情。前端还与付款网关通信，处理支付。
（2）订单管理系统
接收来自客户前端的订单数据。与仓库管理系统通信，通知出货。一旦支付确认，通知付款网关。
（3）仓库管理系统
接收来自订单管理系统的出货请求。更新库存信息。
（4）付款网关
接收和处理来自客户前端的支付请求。一旦支付成功，通知订单管理系统。
应用和用户位置图（ApplicationandUserLocationDiagram）是用来展示应用系统与用户的物理位置关系的。这种图的目的是确保应用的部署位置满足用户的性能需求，并可以实现应用之间的互动。它还有助于确定网络带宽需求。
例如，考虑一个大型企业，它的总部位于纽约，但在全球各地都有办公室。它使用一个集中的CRM系统、ERP系统和一个分布式的报告工具。一个简化的应用和用户位置图案例描述：
（1）物理位置
纽约(总部)
伦敦
北京
孟买
（2）应用系统
CRM系统(部署于纽约)
ERP系统(部署于纽约)
报告工具(分布式部署于各个办公室)
（3）用户
销售团队(在所有办公室)
财务团队(主要在纽约和伦敦)
人力资源(主要在纽约)
这个图展示：（1）CRM和ERP系统在纽约的数据中心有实体。
（2）报告工具在每个办公室都有实体或本地访问点。
（3）销售团队在各个地方都需要访问CRM。
（4）财务团队在纽约和伦敦需要访问ERP系统。
（5）人力资源在纽约访问ERP系统的HR模块。
这样的图有助于决策者理解网络带宽的需求，以及如果某个地方的系统出现问题，哪些用户将受到影响。这还有助于计划备份和灾难恢复策略。
企业可管理性图（EnterpriseManageabilityDiagram）主要描述了架构管理和控制要点，以确保系统的稳定性、性能、安全性和其他可管理性方面的要求得到满足。这些图表提供了对管理控制点（例如性能监控、安全性、日志记录、异常管理等）的高级视图，以及管理数据如何流动到企业中的各种支持系统（例如性能监控工具、安全工具、事件管理工具等）。
具体案例：
假设一个大型在线电商公司有以下几个主要的系统模块：
（1）用户服务
（2）商品浏览服务
（3）订单处理服务
（4）付款服务
（5）物流服务
以及以下管理工具：
A.安全监控工具B.性能监控工具C.错误日志系统D.用户行为分析工具
一个简化的企业可管理性图可能如下：
以上描述提供了一个概念性的视图，描述了这些服务与企业的管理工具之间的互动。在实际的企业可管理性图中，这些关系会被更加直观地表示出来，通常使用箭头来指示数据流的方向。
软件工程图（SoftwareEngineeringDiagram）是用来展示应用结构的。这些结构包括应用的软件组件、接口和与其他软件组件的连接。它为软件工程师和系统开发人员提供了一个视角，帮助他们理解和构建系统的软件部分。这种图的核心是展示软件组件之间的关系、依赖和流程。其目的是为了确保软件设计的完整性和一致性。
案例：在线图书商店
软件组件：
（1）用户界面组件：处理用户交互、显示图书目录、购物车管理等。
（2）订单处理组件：处理用户的订单，包括支付、库存检查和订单状态更新。
（3）支付网关接口组件：与外部支付服务提供商进行交互，处理支付事务。
（4）库存管理组件：负责图书的库存检查和更新。
（5）推荐系统组件：基于用户的浏览和购买历史为其提供图书推荐。
关系和依赖：
（1）用户界面组件依赖于推荐系统组件来为用户提供图书推荐。
（2）用户界面组件将订单数据发送到订单处理组件。
（3）订单处理组件与支付网关接口组件交互，以处理支付。
（4）订单处理组件查询库存管理组件来检查图书的可用性。
在实际的软件工程图中，这些组件、接口和关系将被更详细地展现，还可能包括具体的方法、属性或操作。
系统用例图通常是一个高层次的图，描述了系统与其外部实体（例如用户、其他系统或外部组织）之间的交互。用例图能够描述系统的主要功能，并表明谁可以执行或受益于这些功能。
用例图包括以下元素：
（1）参与者：与系统交互的外部实体，可能是用户、其他系统或硬件设备。
（2）用例：系统的功能或动作，用椭圆表示。
（3）关系：表示参与者与用例之间的交互关系。
案例：假设我们要为一个图书馆信息系统创建一个系统用例图。
（1）参与者
读者
图书管理员
（2）用例
借书还书查找图书登记新图书注销图书
（3）关系
读者可以“查找图书”，“借书”和“还书”。图书管理员可以执行所有的用例。
这个简单的用例图为我们提供了一个清晰的视图，描述了图书馆信息系统的主要功能及其与参与者的交互方式。
流程/系统实现图（Process/SystemRealizationDiagram）主要目的是确保某个业务流程或业务用例可以通过现有的系统和应用得到实现和支持。这种图的目标是描述系统的物理实现和系统如何支持某一流程或多个流程。
这种图通常显示：
业务流程或用例的一部分或全部支持该流程的系统或应用组件系统或应用组件之间的流动或交互
以HR招聘流程为例：
（1）发布职位
业务活动：HR部门确定了一个新的职位或空缺，需要在公开市场上进行招聘。IT系统支持：HR管理系统中，HR人员可以创建和发布新的职位描述、职位要求等。
（2）筛选简历
业务活动：收到应聘者的简历后，HR人员对简历进行筛选，将符合条件的简历筛选出来。IT系统支持：HR管理系统允许HR人员记录每个候选人的信息，简历筛选工具可以帮助快速筛选合适的简历。
（3）安排面试
（4）面试反馈
业务活动：面试官在面试后提供对候选人的反馈。IT系统支持：面试评价系统允许面试官输入和保存他们对候选人的评价。HR管理系统会更新应聘者的状态。
（5）发放Offer
业务活动：对于成功的候选人，公司会发放正式的工作邀请或Offer。IT系统支持：HR管理系统可以生成、记录和发送Offer。
（6）入职安排
业务活动：一旦候选人接受Offer，HR部门会为其入职做准备。IT系统支持：HR管理系统可以安排入职培训、生成员工编号等。
应用迁移图（ApplicationMigrationDiagram）主要描述了从当前架构状态到目标架构状态的迁移路径。这个图为架构师、项目管理、IT策略决策者等提供了一个明确、可视化的工具，用以显示如何在多个项目或阶段中进行迁移以达到最终的目标状态。
具体来说，应用迁移图主要包括：
（1）现有的应用、组件或系统。
（2）预期的未来或目标应用、组件或系统。
（3）迁移路径，这可能涉及到某个应用的升级、合并、退役或替换。
让我们考虑一个场景：
（1）迁移CRM到云并升级到最新版本。
（2）合并两个ERP系统，并在云中运行一个统一版本。
（3）废弃旧的财务系统，并在云中使用收购公司的BI系统。
（4）CRM集成新的BI系统
在此图中，我们可以看到各种迁移活动，以及由于整合和依赖关系带来的复杂性。这样的图形提供了关于项目计划和资源分配的见解，以确保迁移的成功。
软件分布图（SoftwareDistributionDiagram）在TOGAF中主要是描述软件的物理部署以及如何在多种环境中进行分布。这种图的目标是确保所有的软件组件都被适当地部署到其所需的硬件环境中。这包括显示软件组件、关系、以及它们如何映射到硬件上。这有助于明确哪些软件组件部署在哪些服务器、设备或平台上。
假设有一个电子商务应用，它包括前端服务器、后端应用服务器、数据库服务器、以及一个CDN（内容分发网络）来服务其静态内容。以下是此案例的软件分布图：
在这个例子中：
数据中心内有前端Web服务器、应用服务器和数据库服务器。CDN用于分发静态内容。移动用户设备上的移动应用通过API与前端Web服务器通信。前端Web服务器与应用服务器以及数据库服务器之间存在通信。前端Web服务器从CDN的静态内容分发节点请求静态内容。
那么，应用架构定义这么多输出物的目的是什么？
4、灵活性和模块化：分解成多个输出物意味着当组织的某个部分发生变化时，只需更新或修改特定的输出物，而不是整个架构。
总的来说，应用架构的多个输出物提供了一个全面、详细和模块化的方法来描述和管理组织的应用景观。这确保了有效的沟通、明确的决策路径、和更好的架构治理。
大家平时看到的很多应用架构图表现形式千变万化，但无论怎么变化，核心内容大都逃不掉TOGAF定义的14种制品的内容范围，下面举例说明：
1、某WeB中间件功能架构图，其实就是系统/功能矩阵的视图版本。
2、某支付系统架构图，看起来挺复杂的，其实就是系统/功能矩阵、应用通信图、应用互动矩阵、角色/系统矩阵的组合。
3、“4+1”视图模型是PhilippeKruchten提出的，它为软件架构定义了五种主要视图：逻辑、实现、过程、部署和用例视图，其与应用架构交付物其实也有很好的对应关系，如下所示：
（1）逻辑视图
（2）实现视图
（3）过程视图
（4）部署视图
TOGAF给出了ADM的架构开发方法，这种方法同样适用于独立的应用架构开发，企业可以基于自身实际对ADM进行裁剪后进行。这里以供应链管理系统升级为例，演示如何使用TOGAF的ADM来创建一个应用架构的交付物，即系统/功能矩阵：
输出物:
架构原则:“采购管理集中化、标准化、一体化”，“流程高效”。
通过与各部门沟通，绘制业务流程图识别和记录核心业务功能，如“采购寻源”、“需求预测”、“物流配送”等。输出：业务流程图、核心功能列表。
现有架构评估：发现现有的功能分散在“供应链管理系统“、”MIS系统”、“供应商门户系统”、“合同管理系统”等。
定义目标应用架构:
根据业务架构输出，未来的供应链管理系统需要支持的功能：“库存管理”、“订单生成”、“需求提报”等。
识别和定义系统组件：例如“供应链管理系统”、“MIS系统”、“决策支持系统”。
创建系统/功能矩阵。在其中，所有系统都被列出，并对每个功能进行标记，以指示该系统是否支持该功能。
发现“需求提报”和“订单生成”落在了MIS系统，“采购合同”和“供应商注册”分别落在了合同管理系统和供应商门户系统，“采购分析”落在了供应链管理系统，这些功能与原有系统的定位不符，供应链功能割裂，导致流转不畅，考虑重新归位。输出：一系列建议和机会，以优化系统功能。