- 没有整体规划，数据、系统的堆叠，上量后系统容易崩溃

 - 数据分析跟不上业务变化、不同场景不同角色的个性化需求

 - 如何让数据分析与其他产品、工具协同工作

业务方或者分析人员能够灵活的定义分析指标，并在分析探索过程中可以随需应变的临时新增、修改、删除指标模型，修改的结果会直接影响到最后的仪表盘或者数据 API，而整个过程对数据层面完全“无感”。这里的完全无感的意思是，没有任何中间实体表的生成，也没有任何中间计算需要发生。

1、Open API：需要严格的前后端分离设计，在功能层面能够表现为一组完整 API 集合；

2、身份：有完备的用户登陆认证适配机制，和与此配合的动态权限控制机制；

3、前端：有非常灵活的 iFrame 定制化能力、CSS 自定义能力、主题设计能力；

4、模块化：主要功能都有良好封装，松耦合设计，具备独立的能力，能够边界清晰的被识别和调用；

5、对外能力服务化：能够通过 API、iFrame 等各种方式明确对外形成服务机制，有完善的功能 API 创建、注册和流控等管理机制；

6、弹性可扩展：在通过 API 支撑的方式成为一些应用的基础设施后，能够根据服务压力进行弹性扩展，轻松无修改的通过增加部署节点或者容器实例来应对增加的服务压力；

通过建模语义层的抽象，真正随需而变的部分，就可以被灵活的配置和修改，封装为一个个分析模板，让接下来的应用场景能够轻松的嵌入整合，实现了计算的后置，也真正降低了分析的门槛，让业务人员能够自助式完成对数据的探索。

定义数据工作需要的各种专业角色，然后根据角色分工协同落地最佳实践。设计好不同团队在平台中的工作流和配合边界，能够在产品中带入实践方法论，帮助用户养成数据文化。

能够根据各数据平台的优势，创建适配的语言函数发挥差异化优势，比如 Elastic / Mongo 的原生语法深度支持。

分析的需求还是来自业务端的经营管理需求爆发，构建的路径从底层开始往往经过漫长的建设周期，难以预测业务变化。反之，先从业务端的一些典型场景需求开始构建，能够以最快的速度得到分析效果的闭环验证，呈现小步快跑的落地效果。

组织业务部门进行数据研讨，将数据的语言在组织内部做更多的发布传播，形成大家对数据口径的共识，通常也伴随几轮对指标更准确的优化或重新定义，最终形成一个效果不断提升的数据分析亮点场景。

在一个业务部门的试点初步跑通后，管理效率或者管理 KPI 的可见性会得到凸显，这势必会让更多的业务部门也提出自身需求，希望复制成功的数据化经验，这时候才是 IT 部门大显身手的时刻。