这方面的内容比较容易被大家忽略，但毫不夸张的说，它的重要性和复杂程度不会比技术复杂性低多少。
业务的复杂性来自以下多方面：
业务系统对业务概念进行抽象，是数智业务复杂性的根源
我们都知道，企业中存在很多业务对象，他们之间的行为及关系，使其共同构成了企业经营的数据基础（为了方便，我们称这类业务系统中的数据为原始数据），这也是企业进行数智化创新的源头。但是由于业务数据系统中的数据通常为非常细节的数据，并且每种数据的量级非常巨大、关系复杂，企业的决策人员或者模型挖掘并不能直接使用他们。
分析者如果淹没在海量的细节和关系中，则很难做出准确的分析和判断。这时候聪明的人类就会应用抽象思维来解决：
首先是调整角度，“弱水三千，只取一瓢”，仅关注我们认为重要的内容；其次是调整高度，通过应用统计、分析工具，把细节整合为粗粒度指标等；最后通过应用投影思维，把细节的、关系复杂的内容组织为偏平化的形式。
其实机器学习从海量数据中找规律的过程，和人类做法类似，最终我们也需要把复杂的、立体的现实，通过数据加工整合为能够识别特征宽表(目前几乎所有的算法要求数据用欧几里得体系进行表达)的各种算法，你会发现，人工智能这时候就是个甩手展柜，他才不管什么高度和角度，信息量抽象降维的事情，请人类帮我搞定。
业务系统引入更多的复杂性
信息量太大还不是问题的全部， 我们在和业务人员沟通的时候，经常有句话“我的业务概念是完整、清晰的，怎么落到系统，就拼不起来了；没有办法做整体的关联和分析”, 很多时候为了能够表达更多的业务场景，减少概念之间的关系数量，业务系统经常对业务概念进行抽象化。
通过抽象之后，系统的表达能力更强，但是这些抽象的概念对业务人员、分析人员却是不友好的。
企业级的模型标准和主数据规范也难以解决问题
首先，企业级模型标准的设计和业务系统模型设计有一点是相同的，肯定会通过概念抽象去表达更多的业务场景。也就是说在灵活性和业务直观度之间，很难找到一个非常好的平衡。企业级模型标准和主数据在一定程度上，能够统一多个业务系统在抽象层面概念和逻辑结构的一致性。
当一个业务概念需要通过多个技术概念组合表达，而且不同的系统仅关注组合中一部分的时候，各个系统在业务概念层面实现真正统一是非常困难的。例如在通信行业的政企协议，这是一个业务概念，在订单中心会体现为很多商品、接入产品、功能产品以及他们之间的复杂关系，在后端会体现为多个客户服务和资源服务，在计费侧会体现为多个定价实例。
政企协议这个帽子并不是总能很好的被戴在这些概念上，特别是当下面各个子概念独立发生业务和变更的时候，这种关联往往很容易丢失。类似的业务概念还有很多，例如合约计划、活动，一次校园营销，一次沙盘行动等等，但是业务人员关注的恰恰是这些容易被技术抽象忽略的内容。
技术数据的业务化，是一个千景千面的玩法
同样的事情，同样的人与物，在不同人的眼里，可以有不同的解释和理解，这是一个主观的过程，并没有标准答案和绝对的错与对。大家的目标不同，问题不同，角度，高度就会不同。一个事件对某一个结果很重要，对另外一个结果未必很重要。这种多样性又进一步增加了数智过程的业务复杂性。
大数据平台依然充满“物理集中，逻辑烟囱“现象
大数据技术仅仅是提供了一种解决该问题的可能，但是最差的效果有可能是“物理集中，逻辑烟囱”，这是一种更可怕的“烟囱”，是一种慢性中毒式的信息碎片化和分裂化。
数据物理上的集中，并不能保证信息能够被多个数智应用共享，如果不经过仔细的设计，必然会出现很多“逻辑烟囱”。
持续的业务发展和环境变化带来更多挑战
环境变化和业务发展必然会通过更多技术视角的原始数据体现出来；视角不同、高度不同的数智应用问题也会接踵而至；新老、变化的数据之间还存在各种关联，业务复杂度随着时间在增加。
为了解决企业在数智化转型过程中存在的业务复杂性问题，助力企业实现高效数智转型，我们在浩鲸数智平台提出面向未来的“普适性数智”理念，可帮助企业打造一个适用于大多数人和业务场景的“信息体系”。该信息体系门槛低、易理解，能满足大多数AI能力和数据赋能在个性化角度及高度上的需要。
并且在面向新的AI场景的时候，可灵活编排，是柔性的。
同时为了实现上述目标，我们提出了分六步走的数据中台建设方法论。 从客户价值场景出发，通过数据接入、数据加工、数据融合、数据编排、数智开放、数智赋能、数智运营等能力为企业提供数智化服务。
> 数据接入：支持不同环境数据的快速接入，支持流程化、可视化线上业务数据的敏捷搬迁；支持视频、图像、语音、设备等线下数据的感知。
> 数据加工：支持批、流一站式开发，支持统一配置项目的测试、生产环境，以及逻辑名称与物理名称的映射关系，通过映射关系支持一次开发多源部署，降低用户的学习成本。
> 数据融合：通过业务对象、业务过程，统一管理数据开发输出的碎片化信息；抽象产品、用户等，形成扁平化的业务视图。
> 数据编排：基于通用的业务视图，数据编排器以可视化的方式，解决定制需求的问题，打通数据赋能业务的最后一公里。
> 数智开放：提供数据超市和AI超市。使用者以熟悉的电商化界面来查找和订阅，实现数据和AI能力的可视化开放。
> 数智赋能：通过可视化、数据挖掘、智慧能力封装，能够快速满足企业“后视镜”、“仪表盘”、“自动驾驶”等过去、现在和将来的不同数智应用场景。
其中，数据加工、数据融合和数据编排与我们智能视图紧密相关，我们将进一步展开。
首先，基于统一的标准与约定，数据加工可实现技术视角数据到业务视角数据的转化，这个过程会因为业务系统抽象化程度和规范化程度的不同而不同，同时这些业务信息是小而美的。
我们发现，一个优秀的数据开发人员，一方面要有业务思维，能够理解业务人员的概念，又要理解业务系统的抽象设计思维。其实，在真实的生产中，这个过程的情况会比较多。如果我们需要对视频数据进行加工，那么就需要结合相应的视频结构化引擎，图像方面的AI能力来做；如果我们需要对语音类的数据进行加工，则需要结合相应的音频解析和自然语音处理引擎；如果我们需要针对历史数据进行预测，那么就需要结合相应的机器学习模型来做。但是我们发现，虽然加工的方法和工序不同，但是大家都能够按照一定的标准输出产品，这些产品是可以被统一打包和组装的，标准的力量在这里就体现出来了。
其次，数据融合是核心，通过小而美的业务信息，我们让数据加工实现模块化、专业化，满足单一设计原则，使得新业务出现时，能够以非常轻的模式被整合进来。但是不能解决角色化、融合化使用数据的问题，因此，我们通过智能数据融合，以横纵两个维度拉通这些小而美的业务信息，形成角色化（面向一类业务人员的）、大而全的信息视图。
最后，数据编排是关键，通过数据编排，当具体业务场景出现的时候，就能够非常便捷的从这些大而美的信息视图中挑选想要的信息内容，满足业务场景的需求，最终打通数据到应用的最后一公里。
通过这种方式，我们发现业务视图上的信息是统一的，而且是全业务化的，很多有业务知识和业务经验的同学是可以理解的，也能够通过简单的编排解决个性化（多样化的角度和高度问题）的诉求。
大家在谈中台思维的时候，其实我们更多的是在谈复用，以及对未来不确定性的应对能力。数据中台也一样，并不是把所有的数据和应用放在一起就是中台。在面向未来的业务和市场不确定性的时候，是否有更多的柔性和灵活度才是关键。
我们认为，以角色化、或者类主题式的业务视图为中心，向下能够动态的整合小巧的业务信息碎片，向上能够通过编排满足场景化的数智需求，这是数据中台区别于传统数仓的核心和关键。
为了满足数智业务视图的灵活、柔性、自然以及普适，背后需要有一个牛逼的技术引擎，这就是我们做的数据融合引擎。通过数据融合引擎。我们能够做到数据加工、融合、交付全链路的C2B，能够基于真实的应用场景、体量、流量、资源进行动态规划。真正做到既普适、又灵活、还高效。
也就是我们以数据应用为中心，结合当前的存储和计算能力，同时考虑各个数据加工的生产能力、出货时间以及数据应用的出数时间，动态的规划出一个代价最低，而且能够满足各种约束智能化调度策略，最终实现C2B模式的数据交付链路。
整个引擎最核心的是大脑，该大脑主要有几个部分沟通：智能规划，智能评估和智能调度。
智能规划：从大量的数据加工结果到大量的数据应用，如果以点对点的方式进行实现，资源消耗非常巨大，整体出数时间难以保证。我们在做数据融合引擎时，让其能动态规划存在的各种多层级中间宽表，然后以此为起点，结合下一步的智能评估算法，不断优化策略，最终从局部最优走向全局最优。
智能评估：系统进行充分的信息收集和理解，准确的会评估每个数据加工程序的出数时间。评估从各个数据加工程序送数到应用的成本，或者送数到各个中间宽表的成本（这里可能存在多级中间宽表，我们会仔细的评估每种情况的成本和可行性），通过逐步逼近的方式找出到一个总体成本最低，而且能够满足总体应用出数要求的规划路径。
智能调度：通过智能规划和智能评估，我们找到了一个成本最低，而且能够满足出数要求的规划图纸，但是在真正执行的时候，我们还需要充分考虑当前任务的完成情况，资源的负载等，系统在结合任务完成情况、资源负载的基础上，以最大化提升应用出数指标为目标，精细化的安排任务执行的向后顺序，让每次资源的投入都是用在刀刃上，也就是说把一批任务投入执行的前提是，能够带来最好的回报，也就是让尽量多的应用更早的实现出数。
浩鲸科技，过去用了十年把自己打造成通讯基础设施提供商，将来也会用下一个十年，把自己打造成数据智能基础设施提供商。在通往数据智能的道路上，既有技术复杂度的挑战，也有业务复杂度的挑战，我们愿意与社区和生态伙伴一起迎接技术复杂度的挑战，也更愿意在业务复杂性挑战上做深入的思考和尝试。
